Десь приблизно так я навчаю своїх студентів 🤣

Куди розвиватись тестувальнику?

Привіт, давайте сьогодні трохи розберемо шляхи, куди може рухатися тестувальник у своїй кар'єрі і що для цього необхідно прокачувати:

Спеціаліст - для тих хто бажає розумітися на багатьох техніках тестування, та працювати у різних сферах

▪️Підходи тестування;
▪️Тест дизайн;
▪️Технічні скіли;
▪️Моделювання

Продукт/домен - для тих что хоче стати професійним експертом в певній ніші, наприклад GameDev, HealthCare чи E-Commerce

▪️Управління дефектами;
▪️Навчання;
▪️Логіка та раціональне мислення

Project Managment - для тих, хто хоче керувати проектами та командами у них.

▪️Управління часом;
▪️Управління ризиками;
▪️Планування

Leadership - для тих, хто хоче мотивувати команди тестувальників та проводити тренінги, менторити їх

▪️Комунікації
▪️Навчання/Менторство
▪️Соціальні навички

Якщо коротко, то ось навички, на яких вам треба зосередитися, щоб обрати у якому напрямку ви хотіли б рухатися.

Далі буду трохи більше розкривати для вас ці навички і як їх прокачувати 😎

І так давайте сьогодні розбиратись з Тест дизайном

Тест дизайн - це процес проектування вхідних значень, які будуть ефективно тестувати вашу систему.

На практиці ми використовуємо два загальних підходи до проектування тестів.

▫️Перший це criteria-based test design, ми проектуємо тестові значення, які будуть задовільняти інженерні цілі, такі як покриття критеріїв.
▫️Інший це human-based test design, ми проектуємо тестові значення ґрунтуючись на знаннях предметної області програми, а також на наших знаннях про тестування. Це два зовсім різних види активностей.

Давайте розглянемо приклад першого підходу

Вам приходять Acceptance Criteria по типу:

🔘 Користувач може створити об’єкт де обов’язково має бути ім‘я об'єкта;
🔘 Ім‘я об'єкта має бути унікальним;
🔘 Також у об'єкта ще є опис, але користувач може створити об’єкт без опису.

Ми приблизно розуміємо модель програми і маємо придумати тест кейси, щоб покрити критерії.

В другому підході, ми повинні знати предметну область програми, знати як тестувати та яким має бути користувацький інтерфейс.

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

Головне, що ці два підходи доповнюють один одного, і нам потрібні обидва для повного тестування програмного забезпечення.

Такий маємо зараз ворк/лайф баланс

Підходи дослідницького тестування😉

В цілому, є 6 основних підходів які я найчастіше використовую у своїй роботі:

Session based testing - тестування за допомогою сесій, використовується за допомогою тест чартерів з визначеним часом. Це більше інструмент менеджменту тестування, завдяки яким ви можете трекати кількість проведених сесій

Pair Based testing - тестування яке проводиться в парі з іншим тестувальником або девелопером, дозволяє пропрацювати більше кейсів та уникнути тунельного бачення.

Persona Based Testing - тестування на основі персон, визначає типажі юзерів та описує поведінку певних категорій користувачів нашої системи.

State & Transition Testing - тестування на основі станів та переходів, використовується у системах з кінечним числом станів, перевіряє всі можливі дії у різних станах системи та дозволяє проаналізувати, які переходи можна здійснювати між різними станами системи. Ця техніка являється технікою чорного ящика, але ви можете використовувати саме діаграми, для аналізу станів, і таким чином досліджувати продукт.

Tours Based Testing - тестування на основі турів, використовує різні метафори та ситуативні сценарії, на які накладається робота вашої системи.

Risk Based Testing - тестування на основі ризиків, допомагає приорітезувати тести в системі та зробити розподіл функціональності на основі вірогідності виникнення різних помилок. Сам по собі підхід на основі ризиків це окремий напрямок, але частково ви можете використовувати його при наприклад відборі тестових чартерів.

Пишіть у коментарі, який із підходів для вас розібрати першим

#exploratorytesting

Отже давайте розбирати Pair Testing

Тут все очевидно і назва говорить сама за себе. Дві людини сідають разом за один комп’ютер, телефон чи ще будь що, що вони хочуть протестувати.

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

Я використовую два підходи:
Оператор - Навігатор;
Оператор - Наглядач.

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

В другому варіанті оператор буде виконувати і проговорювати свої ідеї, а наглядач буде спостерігати за процесом та задавати уточнюючі запитання. Наприклад чому саме так зробив оператор, що він очікував в результаті такого сценарію і т. д.

Перед початком роботи потрібно підготуватися:

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

Під час роботи:

- Обговорюємо ідеї;
- Робимо нотатки;
- Записуємо баги;
- Робимо скріни чи записуємо відео.

По завершенню:

- Проводимо ретроспективу;
- Робимо висновки;
- Робимо короткий репорт.

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

Маленький спойлер, скоро проводитиму воркшоп по дослідницькому тестуванню, тому слідкуйте за анонсами

#exploratorytesting

Давайте розберемо 6 властивостей тестування на основі ризиків

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

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

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

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

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

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

Шоста властивість і остання випливаюча властивість дозволяє самостійно виправляти помилки в аналізі ризику. Ця властивість пов’язана зі слабкістю, притаманною всім аналітичним тестовим стратегіям. У будь-якій стратегії аналітичного тестування ми виконуємо аналіз на початку проекту та використовуємо цей аналіз для визначення роботи тестування, яку ми будемо виконувати. Однак будь-який ранній аналіз часто певною мірою базується на неправильних припущеннях та інформації, і ці недійсні концепції стають вбудованими в тестування. Поєднуючи реактивні стратегії тестування, такі як пошук помилок, атаки на програмне забезпечення та дослідницьке тестування, ми вводимо елемент самокоригування в процес виконання тестів, оскільки ці реактивні стратегії мають тенденцію виявляти дірки та помилки у нашому наборі тестів, який виник через проблеми з аналізом.

В наступному пості ми розберемо, які переваги ми, як тест менеджери отримуємо при використанні цих властивостей 😉

#exploratorytesting

Привіт гайс, в продовження попереднього посту давайте розберемо переваги використання Risk Based тестування

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

Друга перевага, завдяки тим самим пріоритетам, тестування на основі ризиків допомагає прийняти розумні рішення щодо покриття кейсами. Ми можемо придумати безліч тест кейсів, щоб перевірити нашу систему, але чи варте воно того. Краще продумувати кейси на основі ризиків і відбирати найкращі сценарії для покриття.

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

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

Тож не нехтуйте використанням правильних технік та методів😎

Завтра закину вам пост, які софт скіли треба прокачувати тестувальнику, щоб не топтатися на одному місці і швидше рухатися у кар'єрі

Софт скіли

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

Які саме софт скіли потрапляють у топ на мою думку:

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

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

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

Ставити правильні запитання
На початку роботи і будь якому проекті вас будуть оцінювати саме за тим, наскільки правильні запитання відносно продукту та задач ви ставите. Наприклад:

- Хто кінцевий користувач програми?
- Як вона буде використовуватися?
- Які найпоширеніші конфігурації браузера чи операційної системи?

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

А які софт скіли важливі на вашу думку?

Друзі привіт, дублюю текстом

У цю суботу збираємося на корисний мітап по метрикам (деталі того що розберемо у кругляшку)😉

Коли: у цю суботу 12.11
Вартість: донейшн на ЗСУ, будь яка довільна сума.
Початок: о 12:00

Приєднуйтесь та давайте вчитися разом 😉

Всім привіт😎
Сьогодні в Україні дуже гарні новини 🍉🇺🇦

Друзі, хочу нагадати вам, що завтра о 12:00 збираємося з вами на мітап по метрикам тестування!

Вартість, донейшн на ваш розсуд, усі отримані кошти підуть на волонтерський фонд https://instagram.com/trushnaperemoha

Гроші збираємо на банку: https://send.monobank.ua/jar/9JDnSjm97s

Посилання на зустріч закину завтра вранці

Давайте навчатися та допомагати Україні разом😉

QA Metrics

Вийшло доволі продуктивно. Тому не соромимось донатимо 🙏🏻❤️🇺🇦
https://send.monobank.ua/jar/9JDnSjm97s

Гайз👋

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

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

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

Сесія, це якась частина вашого тестування, яка виконується в рамках визначеної вами тривалості (30, 60 чи 90 хвилин), впродовж якої, будь які відволікання на смс, емейли, вхідні дзвінки чи відволікання вашими колегами не допустимі.

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

Тестування на основі сесій робить дослідницьке тестування структурованим та примінимим навіть на великих складних проектах де команди працюють в режимі Agile.

Хотіли б спробувати тестування на основі сесій на практиці?

#exploratorytesting

Давайте практикуватися🔥

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

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

У цю суботу запрошую вас спробувати техніки дослідницького тестування на практиці, це буде щось нове та круте для вас.

Ціна: 1500 грн.
Тривалість: 4 години
Починаємо об: 11:00

І ще, давайте одразу, запису воркшопу нажаль не буде ❌, оскільки він максимально націлений на практичну роботу тут і зараз!

Хто бажає доєднатися, або більш детально дізнатись про воркшоп, пишіть + у комент під постом 😉

#exploratorytesting

​​6 грудня команда Levi9 запрошує на QA Meetup!

Поговоримо про Playwright, Accessibility testing та техніки тест-дизайну ━
долучайся онлайн або приходь на офлайн нетворк у наш київський офіс😉

Що у програмі?

“Техніки тест-дизайну”, ━ Дмитро Топчій, Test Lead в Levi9
Розглянемо наглядно приклади технік тест-дизайну, що здатні допомогти тест інженерам в плануванні дослідницького тестування та автоматизації.

“Тестування доступності: теорія, інструменти та чому це важливо”, ━ Сергій Собур, Test Lead/ Principal QA Engineer в Levi9, спікер/модератор мітапу.
Чому і коли необхідно проводити тестування доступності, з чого почати та які інструменти стануть у пригоді.

“Автоматизація тестування доступності за допомогою Playwright” , ━ Віктор Кипоренко, Test Developer Junior в Levi9
Зосередимось на автоматизації: встановлення; різні варіанти конфігурації; створення і аналіз звітів та можливі проблеми.

Коли: 6 грудня о 19:00 (GMT+2)

Обирай формат участі:
Онлайн — безкоштовно за попередньою реєстрацією

Офлайн нетворк & пивко у Києві
Адреса: БЦ Техно Лофт, вулиця Володимирська, 101
Вхід з організаційним внеском ₴300
Всі кошти, отримані з продажу квитків направимо на благодійність💙💛

👉Деталі та реєстрація: http://bit.ly/3UVn8Q7

Побачимось!

6 думаючих капелюхів як підхід в Quality Assurance

Едвард де Боно розробив цікаву техніку на основі 6 різних капелюхів, приміряючи які ми під різним кутом дивимося на речі.

Давайте розглянемо як їх можна використати в тестуванні

1. Синій капелюх - управлінський
Одягаючи цей капелюх, команда думає з точки зору менеджмента і ми описуємо кінцеву ціль нашого продукта
Ми можемо задати собі такі питання:
- Чому ми розробляємо цей продукт?
- Які потреби юзера ми вирішуємо?
- Чи буде це корисно для наших користувачів?

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

3. Червоний капелюх - емоційний
Одягаючи цей капелюх команда має відповідати на такі питання:
- Які емоції у нас викликає використання тієї чи іншої фічі?
- Чи є якісь неприємні відчуття при взаємодії з продуктом?
Таким чином ми аналізуємо продукт з точки зору користувача, як кажуть що наш шлунок говорить по віднощенню до продукту. Чи класний UI, чи добре продуманий UX і т. д.

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

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

6. Зелений капелюх - креативний
- Досліджуємо і аналізуємо подібні продукти та використовуємо інформацію для покращення
- Використовуємо нові інструменти та методології для покращення тестування
- Повторюємо цикл примірки капелюхів та генеруємо нові ідеї

Це один із підходів дослідницького тестування.

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

Залишилось ще кілька місць, хто бажає вскочити в останній вагон пишіть @yakymchuk_roma

#exploratorytesting