Тест план за п'ять хвилин, або техніка RCRCRC

#testing

Чи бувало у вас так, що забігає менеджер та каже - "Треба швидко релізитись, у вас є 5 (10, 30, 60) хвилин - тому швиденько перевірте цей білд та йдемо на прод!"

Що при цьому тестувати? Як обрати найважливіше з тієї великої кількості тест кейсів, яка у вас є?
Звичайно, можна подивитись на пріоритет тестів, на ризики.

А можна - застосувати техніку RCRCRC, яку придумала Karen N. Johnson. Та створити тест план за 5 хвилин.

Що таке RCRCRC?

Це техніка, що допоможе вирішити, які фічі включити в тестування в першу чергу - та сформувати швидкий тест план для конкретного білду (релізу).

- Recent. Нові фічі та частини продукту, що були змінені в останньому релізі. Можна подивитись також git diff
- Core. Головні та найбільш використовувані фічі. Можна визначити за допомогою статистики та моніторінгу юзерів на продакшені.
- Risk. Найбільш ризиковані частини продукту. Там, де більше багів, або ж там, де cyclomatic complexity коду - найбільша.
- Configuration-sensitive. Фічі, які найскладніше налаштовувати.
- Repaired. Частини функціональності, де були останні баг фікси.
- Chronic. Частини продукту, які найчастіше ламаються.

Техніку RCRCRC можна застосовувати як у невеличкому проєкті, так і у великому ентерпрайзі.
Але як завжди - все залежить від Вашого контексту.

Оракули в тестуванні

#testing

Кожного дня ми тестуємо. Деякі з нас також пишуть автотести.
Але як зрозуміти, що той результат, який ми отримали - саме очікуваний? Для цього ми всі користуємося оракулами. Навіть, якщо не знаємо, що таке ті оракули.

Що таке оракул?
Оракул в тестуванні - це будь-яке джерело, яке ми можемо використати, щоб зрозуміти що поточний результат є очікуваним.

Які бувають оракули?
- Вимоги. Перше та найважливіше джерело інформації для тестувальника. Вимоги можуть мати багато форм: від офіційної документації до негласного спільного розуміння системи між інженерами.
- Стандарти (міжнародні чи соціальні). Стандарти залежать від індустрії. Соціальні норми чи базові фізичні виміри - це те, що ми або знаємо або можемо відносно легко поміряти. Наприклад знання, що в одному метрі - саме сто сантиметрів.
- Інші схожі продукти. Це може бути загально прийняті норми для користувацького досвіду - де та в якому порядку розмістити базові елементи навігації.
- Логи та системи моніторингу з продакшену. Можна порівняти логи від реальних користувачів з логами, зібраними під час тестування.
- Історія та власний досвід. Чим більше ви працюєте в домені чи над конкретним продуктом - тим більше досвіду ви накопичуєте та можете помітити помилки, які звичайний користувач легко не віднайде.
- Дослідницькі роботи. Якщо ваш софт створюється на основі однієї чи декількох робіт - то вимогами стають саме ці документи.

Для тих, хто пише автотести, оракулами можуть слугувати офіційні туторіали, скрипти чи мануальні тести (якщо у вас є розділення праці між інженерами).

Головний принцип роботи з оракулами - це узгодити їх з усією командою. То ж у випадку різних спорів - “чи бага це чи ні” - ви мали б можливість посилатися на документ.
Але здоровий глузд авжеж ніхто не відміняв.

А якими оракулами користуєтеся ви?

⚡️ Епізод 30: Де тестувальник розбирається з тестуванням мікросервісів

Хайп мікросервісів вже пройшов. Наразі це лише один з багатьох підходів до проектування бекенду. Але є велика ймовірність, що ваш поточний чи майбутній проєкт буде мати під капотом десятки й сотні маленьких сервісів. Як правильно підходити до тестування та автоматизації таких систем ми (Артем та Олександр) й будемо розбиратись в цьому епізоді.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify Podcast
🔸 Apple Podcast
🔹 Google Podcast

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Про важливість репортів

#testing

Читаю зараз книжку “Software Testing Strategies” та натрапив на важливу інформацію про репорти. Хочу поділитися нею з вами.

Одна з ключових навичок (про яку часто забувають) - це вміння доносити до менеджмента результати тестування (test summary report).

Більшість менеджерів не мають часу щоб заглибитись в усі ваші метрики та тест кейси. Їм також не дуже потрібна інформація про покриття, кількість ваших тестів та як фантастично у вас працює автоматизація. Що дійсно потрібно менеджеру - так це високорівнева інформація для прийняття рішень.

Які рішення треба прийняти менеджеру?

- Чи можна вже релізитись?
- Якщо зараз не можна, то коли можна буде релізитись?
- Шо треба пофіксити, щоб вийти в продакшн в стані “good enough”?
- Чи готова ця фіча для демо? Чи можемо ми викатити конкретну фічу?

Тестувальник, особливо контекстно-орієнтований - це дослідник та інформатор, але ніяк не людина, що приймає рішення.
Тому хороший тестувальник не говорить “Тестування завершене". Він чи вона говорять - “Я протестував оці ризики, знайшов оці проблеми та не бачу користі в подальшому тестуванні цієї фічі зараз”.

Що включає в себе хороший репорт:

- Репорт представляє менеджменту варіанти. “Можна зробити це, можна - інше. А можна - взагалі щось третє”. Коли ви даєте тільки один варіант - ви позбавляєте людину вибору. З двома варіантами - менеджмент має дилему. З трьома - керівник відчуває, що має контроль.
- Репорт включає в себе невеличкий список найкритичніших багів та чому саме вони є критичними.
- Репорт розповідає що саме ви НЕ протестували. Менеджмент зможе прийняти рішення, базуючись на тому, які баги вже є - чи потрібно далі тестувати ту чи іншу фічу додатково. Бо якщо ми не будемо фіксити наявні баги - нащо поглиблюватись далі та витрачати час.

Дайте менеджменту інформацію. Дозвольте їм бути частиною рішення.
Потім той менеджер не зможе критикувати вашу роботу - бо ж сам приймав в цьому участь.

How to lead projects from start to finish as a software engineer

#management

Робота тест інженера - не тільки тестування. А ще й створення інструментів, фреймворків чи просто проєктів для покращення процесів.
Тому треба знати, як ці самі проєкти треба планувати, виконувати та запускати.
Особливо - про інформування та репортинг статусу проєкту.

P.S. В пості є чимало посилань на корисні шаблони документів.

Testing Machine Learning: Insight and Experience from Using Simulators to Test Trained Functionality

#testing #ml

Для тих, хто хотів би подивитись, як воно тестувати machine learning проєкти - знайшов невелику, але цікаву статтю. З прикладами дослідницьких робіт на цю тему.

А тим часом нас вже більше 3000 людей в цьому каналі! Дякую, що підписуєтесь та читаєте! Про що б ще цікаво було б почути на каналі?

У нас вийшов новий випуск QA подкасту « Питання якості»!

Обговорюємо самостійне навчання у тестуванні, оцінку процесів та важливість впізнаваності тестувальника. Дивіться разом з нами! 👉🏻 https://dou.ua/goto/7Xkx

Про навчання 1: Пам'ять комп'ютера vs пам'ять людини

#learning #tips

Минулого тижня відбулася конференція "QA - Magic Meetup 5.0". Одна з доповідей була від Аміни Олійник - про те, як краще вчитися.

Хотілося в цьому та декількох подальших постах трохи доповнити цю тему. Бо тема навчання - вельми обширна.
Але коли ми розуміємо базові речі - вчитися стає трохи легше.

Пам'ять комп'ютера

Як працює пам'ять в комп'ютері? Ми записали якусь інформацію (послідовність бітів). А потім, коли вона знадобилася - знайшли та зчитали її.

Пару важливих моментів про дані на комп'ютері:
- Читання інформації - не змінює її.
- Нема різниці скільки пройшло часу між записом та зчитуванням.

Пам'ять людини

Людьска пам'ять працює в режимі "read-and-update". Коли ми дістаємо шось з нашої пам'яті - ми покращуємо знання, але можемо їх також змінити. Це називається - реконсолідацією. Тож чим більше ми згадуємо інформацію - тим краще ми її пам'ятаємо.

Інший цікавий концепт - це spreading activation.

Коли ми згадуємо щось, ми активуємо ланцюжок нейронів, який приводить до потрібної інформації. Але таких ланцюжків є більше одного. Поки ми щось пригадуємо - активуються багато різних ланцюжків, які залишаються активними декілька годин - навіть після того, як ви вже згадали потрібну інформацію.

Spreading activation погано впливає саме на пам'ять, але позитивно - на вміння вирішувати задачі.

Через spreading activation інформація, яку ми згадуємо, може змішуватись з іншими ланцюжками - та ставати неточною або хибною.

Але з іншого боку - саме таке змішування і є джерелом креативності та натхнення. Тому ми можемо прийти до рішення через декілька годин після роботи - під час зовсім іншої активності.

"Software Testing Strategies: A testing guide for the 2020s"

#books #review

Написав невеличке рев'ю на книжку про тестові стратегії. Книга не стільки про саме стратегії. А про тестування взагалі: як краще тестувати, як обрати фічі для тестування. Та найголовніше - як говорити про тестування з різними людьми в компанії.

Книжка свіжа та варта Вашої уваги.

Про навчання 2: Види пам’яті та навчання

#learning #tips

Продовжуємо розмову про те, як ми навчаємося. Минулого разу ми почали говорити про те, як людина та комп'ютер зберігають інформацію.

Два види пам'яті

Пам’ять людини можна поділити на дві: довгострокова та робоча.
Довгострокова пам’ять - це та, в якій інформація зберігається постійно. Її об’єм умовно нескінченний. (Наче HDD чи SSD).
Робоча пам’ять - це та, яку ми використовуємо для того, щоб розв’язувати нагальні питання. Вона невелика за розміром (по аналогії з CPU регістрами).

Розмір робочої пам’яті визначається при народженні. З часом можливо лише трохи збільшити її. Чим вона більша - тим швидше ми можемо вчитися - принаймні на початку. Те, що відрізняє досвідчену людину від новачка - це саме вміст довгострокової пам’яті та вміння ефективно діставати з неї потрібну інформацію.

Шматки інформації та когнітивне навантаження

Люди навчаються подрібнюючі інформацію на невеликі шматочки. Розбиття на частинки допомагає накопичувати їх в пам’яті та розглядати як єдине ціле.

Коли навчаємося чогось нового, треба розуміти також концепцію когнітивного навантаження або ж наскільки багато пам’яті вам буде потрібно для вирішення цієї задачі. Когнітивне навантаження має два види - внутрішнє та зовнішнє.

Внутрішнє навантаження визначає скільки частинок інформації потрібно для виконання задачі. Ця кількість змінюється тільки, коли ми змінюємо саму задачу.

Зовнішнє навантаження - це вся та додаткова контекстна інформація, що потрібна для вирішення питання, але не є частиною самої задачі.

Формат подачі інформації дуже впливає на когнітивне зовнішнє навантаження. Наприклад - ви можете отримати опис задачі чи схему у вигляді тексту. А можете - у формі схеми чи малюнку з позначеннями. (Приклад - у першому коменті) Краще - коли ці форми - поєднуються.

Як це все пов’язано?

Зовнішнє навантаження вище у новачків, бо вони ще не можуть відрізнити ті частини, які потрібні саме для розв’язання задачі. Тож коли ми маємо справу з завданням поза межами можливостей - найкращий підхід - це зменшити когнітивне навантаження.

Як? Просто розбийте велику задачу на маленькі частини та працюйте з ними одна з одною. Цей підхід працює коли ви навчаєтесь самі та коли ви є ментором та навчаєте інших.

Shift-right тестування, стратегія автоматизації на проєкті, каталогування платівок за допомогою computer vision, як Meta працює з Precision Time Protocol та інші новини зі світу тестування зібрав Олександр Романов у цьому дайджесті 👉 https://dou.ua/goto/TNx4

PRO Stage для PRO квитків: Слухайте СЕО MacPaw, Genesis, Intellias та інших на DOU Day 18 травня в Києві!

Про навчання - 3: Семантичні хвилі

#learning #tips

Коли ви вчите новий концепт, то вам треба обидві форми пояснення - як абстрактна, так і конкретна. Більш того, вчити стає трохи легше, якщо ви дотримуєтесь "семантичної хвилі", яку придумав Карл Матон.

Згідно Матона, коли ви дотримуєтесь хвилі, то постійно переключаєтесь між абстрактним визначенням та конкретними прикладами. Чим більш різноманітні приклади - тим краще. В тому числі - невірні приклади (з поясненням чому вони неправильні). Цей процес називається "розпакуванням".

Вивчаючі приклади, ви потім зможете переглянути абстрактну концепцію та будувати більш глибоке її розуміння. Таке розуміння дозволить бачити приховані внутрішні зв'язки та називається "перепакуванням", за тим же Матоном.

Програмування позв'язане із вивченням абстрактних речей. Основна проблема полягає в тому, що з часом поняття стають ще абстрактнішими. Але чим краще ми вивчаємо та розбираємось з термінами на початку навчання - тим більше конкретними вони стають для нас.

Про навчання 4: Чи потрібно навчатись, коли все й так є в Інтернеті

#learning #tips

З появою Інтернету навчання змінилося. Здається -

"нащо знати той API чи читати книжки від початку до кінця, коли є Google Search, Stack Overflow, ChatGPT з отими копайлотами? Адже уся інформація доступна на відстані декількох кліків"

То що - не вчитись тепер взагалі? Давайте подивимось, що говорять про це вчені.

Чому треба запам'ятовувати?

Ми вчимося завдяки тому, що зберігаємо інформацію в довгостроковій пам'яті та формуючи зв'язки між різними на перший погляд речами.
Якщо цього знання у нас пам'яті немає - то зв'язки не утворяться. А значить - ми не сформуємо ніяких абстрактних концептів та не отримаємо розуміння на більш високому рівні.

Саме тому, кожного разу коли Вам буде потрібно зробити SQL запит із JOIN'нами - вам треба буде згадувати - що ж таке JOIN взагалі.

Як вчаться експерти?

Різниця також є в тому, як користуються Інтернетом новачки та експерти. Новачку потрібно знову й знову вивчати деталі та формувати зв'язки.
Експерт же, що має глибокі знання - йому чи їй досить погуглити лиш деякі окремі деталі, які забуваються.

Чому надмірно гуглити - це погано?

Існує ряд досліджень про шкоду надмірного гугління. Одне з них показує, що ми гірше запам'ятовуємо інформацію, коли швидко дістали її з Інтернету, ніж коли ми прочитали про це в книзі. Інше дослідження доводить, що інформація забувається, коли ми не намагаємося спочатку згадати її - а одразу летимо гуглити. Тож швидке гугління "краде" в нашого мозку можливість попрацювати та зміцнити зв'язки.

Гугління також впливає на когнітивне навантаження (про яке ми також говорили). Бо нам треба переключитись з одного виду діяльності (написання коду чи тестів) на інший - пошук в інтернеті. Коли інформація вже є в нашій пам'яті - такого переключення між контекстами не потрібно.

То що робити?

Це все не означає, що гуглити не треба та можна ігнорувати технології.
Просто треба також й самостійно вчитись, опрацьовувати інформацію, робити нотатки.
Щоб не залишитись в ситуації :

"мені відключили копайлот/chatgpt - я тепер не можу працювати"

Про навчання 5: Як зрозуміти, що вчити?

#learning #tips

Про те, що треба вчитись - говорять усі. Наче й ресурсів вдосталь: книжки, курси, вебінари, ментори. Але як зрозуміти, що треба вчити?

Універсальної відповіді немає. Бо в кожного свій контекст.

Але можна застосувати таку методику:

- Проаналізуйте те, що вам цікаво - те що вас дійсно захоплює в роботі (Подумайте, що ви можете робити так довго, що наче "забуваєте про час").
- Подивіться на те, що вам не вистачає в роботі зараз. Це може бути доменні знання, фреймворк, технологія чи інструмент.
- Запитайте в менеджера, що вам не вистачає для промоушену. Це також може стати джерелом тем для навчання.
- Подивіться вакансії - що зараз треба на ринку праці. Скорочення можуть бути в будь-який момент. Тому впевніться, що ваші навички актуальні.

P.S. Краще поглибитись в тему, здобути перші знання та закріпити їх на практиці. Ніж читати тисячі сторінок книжок теорії

P.P.S. Я трекаю навички у вигляді mind map та переглядаю їх раз у квартал чи півроку.

Про навчання - 6: Експерти та новачки

#learning #tips

Різниця між експертом та новачком.

Чим відрізняються новачки від експертів? Дослідження показують, що експерти (наприклад в грі в шахи) вміють запам'ятовувати та розпізнавати стан дошки в конкретний момент часу. Це допомагає швидко приймати рішення.

Розробники - експерти можуть розпізнавати типові паттерни в коді. Так, ті самі дизайн паттерни, які запитують на співбесідах. Ба більше - експерти можуть глянути на код та зрозуміти "що ота частина під капотом імплементує сортування". Новачку в тій же самій ситуації треба докласти більше зусиль та читати код рядок за рядком.

Як же новачку стати експертом? Відповідь проста - читати, писати та розбиратись у різному коді. Як хорошому так і поганому.

Бути експертом - навчатись по-іншому

Існує така річ, як expertise-reversal effect. Він означає, що для новачкам та експертам потрібні радикально різні підходи до навчання.

- Новачкам буде корисним отримати туторіали та різні cheat листи з використання інструментів. Експерти самі здатні продумати подібні туторіали.
- Новачкам потрібні легкі завдання для закріплення вивченого - поки нова інформація наче пазл не стане на потрібне місце.
- Новачкам потрібні приклади та точне пояснення результату. Експертам більше підійдуть “відкриті” питання та обговорення.
- Експертам потрібне мінімальне пояснення та більша свобода дії.

Бути експертом - не означає бути хорошим вчителем.

Дуже часто сіньйори чи техліди не можуть пояснити новачкам якісь аспекти просто тому, що вони роблять багато речей "автоматично". Експертам важко відокремити такі навички та розбити їх на окремі вправи чи пояснення.

В такому випадку може допомогти влаштувати сесію між експертом, новачком та більш обізнаним інженером (який трохи краще знається на системі, ніж новачок). Такий інженер зіграє роль "мосту" між фахівцями - допоможе експерту візуалізувати знання, а новачку - отримати зрозуміле пояснення.

Неявні знання

Те ж стосується накопичення великої кількості "неявних" знань в голові однієї "експертної" людини. Такі неявні знання ще називаються тацитовими. Це можуть бути як доменні знання з проекту, так і технічні знання з фреймворку чи конфігурації системи.

Щоб запобігти накопиченню таких знань - варто писати документацію. Наприклад - FAQ документи, гайди з конфігурації, корисні збірки команд на кожен день.
Для експерта користь буде в зменшенні кількості однакових питань - бо люди спочатку підуть й шукають відповідь на Конфлюенсі.

Тестування блокчейну - що почитати?

#testing #blockchain

Вчора я провів лекцію з тестування блокчейну для Суворого QA Community.
Крім покрокових пояснень що таке блокчейн "під капотом", я також поділився списком того, що можна почитати теми тестування.
Поділюся цим списком тут.

Від мене
- Blockchain for Test Engineers - цикл статей, де я розбираю складові частини блокчейну з точки зору тестувальника.
- Awesome Blockchain Testing - величезна підбірка статей, відео та дослідницьких робіт з тестування блокчейнів.

Книжки
- Блокчейн і децентралізовані системи - єдиний україномовний підручник для ВУЗу з теми блокчейну.
- Mastering Blockchain - одна книжка, щоб покрити практично все, що пов'язане з темою. Четверте видання - найповніше.
- Mastering Ethereum: Building Smart Contracts and DApps - книжка, якщо ви конкретно хочете розібратися в Ethereum.

Курси
- "Solidity Smart Contracts" - безкоштовний україномовний курс з розробки смарт-контрактів на Solidity (Ethereum). Він непростий, попереджаю.
- Спеціалізація Блокчейн на Coursera - непогана підбірка курсів для початків.
- Спеціалізація "Децентралізовані фінанси" - інтро курси з прикладного застосування блокчейну. А саме - для побудови фінансових застосунків.

Приємного читання!

How SMS Fraud Works and How to Guard Against It

#security

Twitter, він же X, в лютому відключив аутентифікацію за допомогою SMS для усіх користувачів, крім преміальних.

- Нащо це було зроблено?
- Як це пов'язано зі злочинними схемами?
- Як захиститись від SMS fraud?

Про все це - сьогодні у невеличкій статті.

Про читання професійної літератури

#reading

Як заставити себе читати?

Коротко - НІЯК. Не треба цього робити.
Крім книжок, можна читати статті або дослідницькі роботи. Крім читання - можна проходити курси чи дивитись доповіді.
Кожен обирає сам - який формат пізнання підходить краще.

Для того. щоб читати та дізнаватись нове - потрібна мотивація.

Мотивація може бути або внутрішня - "хочу дізнатись більше чи опанувати нові навички".
Або ж зовнішня - "якщо не опаную навички - звільнять, поріжуть ЗП, не отримаю підвишення".
Спробуйте дізнатись, що Вас мотивує саме зараз. Якщо нічого - не читайте. В житті є безліч не менш важливих справ.

Як читати великі за обсягом книжки?

Великі книжки - це, зазвичай, або довідники, або монументальні твори.
В будь-якому випадку краще мати відповіді на питання - нащо ви читаєте ту чи іншу книжки? Які бенефіти вона принесе Вам прямо зараз?
В залежності від відповіді - ви зможете обрати як Вам краще читати книжку. Чи повністю від початку до кінця. Чи - як довідник.

- Нема нічого поганого, якщо Ви прочитаєте окремі розділи книжки. Розділи, які Вас найбільше цікавлять в конкретний момент часу. Завжди можна повернутись до книжки трохи пізніше. Або змінити одну книжку на іншу.
- Виділяйте кожного дня трохи часу (іноді з таймером) та читайте. Краще - з короткими нотатками. Ще краще - записуйте конкретні action points з кожного розділу: що Ви можете застосувати в роботі прямо зараз. Та пробуйте застосувати одразу. Поки знання ще "свіжі".
- Немає нічого гіршого, коли спеціаліст читає книжку "бо так сказали люди" або "бо її всі читають, вона в усіх підбірках".
Можливо ця книжка Вам не підійде. Не засмучуйтесь. Завжди можна знайти іншу книжку іншого автора.

Github Copilot - з чого почати?

#ai #engineering

Минулого тижня я нарешті встановив собі Github Copilot та почав ним користуватись для робочих задач.

Якщо ви, як і я, тільки вивчаєте цей інструмент, то маю для вас декілька статей, що розповідають про його чарівні можливості.

- How to use GitHub Copilot: Prompts, tips, and use cases
- Using GitHub Copilot in your IDE: Tips, tricks, and best practices
- Using GitHub Copilot Effectively

Трохи згодом розповім про свій особистий досвід користування.