Чи бувало у вас таке, пофіксили вам баг, а там два нових? 😂

Друзі, всім привіт 😉

Хочу нагадати вам, що ми збираємося вже завтра о 20:00⏰

Буде корисна інфа, яка допоможе вам швидше і простіше рухатися у своїх проектах😎

Для реєстрації, пишіть у приват @yakymchuk_roma

До зустрічі завтра 😉

Test Documentation

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

https://www.guru99.com/testing-documentation.html

Testing strategy denoscription

https://www.google.com/amp/s/www.softwaretestinghelp.com/writing-test-strategy-document-template/amp/

Test plan example

https://www.softwaretestinghelp.com/wp-content/qa/uploads/2014/02/Live_Project_Test_Plan_SoftwareTestingHelp.pdf

Cheat sheets

https://adventuresinqa.com/wp-content/uploads/2015/12/Mobile-Testing-Cheat-Sheet-Adventures-in-QA.pdf

https://goritskov.com/media/files/testheuristicscheatsheetv1.pdf

https://agiletester.ca/wp-content/uploads/sites/26/2017/07/TestPlanningCheatSheet.pdf

Завдяки вашим донатам, ми змогли відправити хлопцям невеличку допомогу. Думаю і надалі робити таку ж ініціативу, адже ситуація в нас win-win ви отримуєте нові знання та допомагаєте нашій армії наближаючи перемогу України ♥️

Всім привіт 👋

Давайте ще раз коротко пройдемося по процесу тестування, та закріпимо для себе основні стадії
🔹Аналіз вимог
🔸Планування тестування
🔹Дизайн тестів
🔸Виконання тестів та заведення баг репортів
🔹Ретестування та регресійне тестування
🔸Тест репорт
Закріплюйте собі в закладки, щоб не загубити
https://telegra.ph/Stad%D1%96i-QA-procesu-04-14

Як зекономити кількість тестів?

Друзі привіт, як і обіцяв вам, давайте сьогодні на реальному прикладі розберемо як за допомогою комбінаторного тестування, у рази зменшити кількість тестів та полегшити свою роботу😎

https://telegra.ph/Testova-komb%D1%96natorika-z-vikoristannyam-Pairwise-abo-All-pairs-tehn%D1%96ki-10-05

І також хочу, нагадати, що вже сьогодні стартує наш курс з Тест Аналізу

Перший урок починається о 19:00

До 18:00 ви ще встигаєте вскочити у останній вагон, якщо у вас залишились питання, пишіть у особисті @yakymchuk_roma

Частину грошей я передаю на ЗСУ

Всім привіт 👋

В тестуванні однією із важливих стадій є підготовка тест репорта.

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

https://geteasyqa.com/qa/write-test-report/

#testreport #qa

Доброго дня колеги!

Вітаю всіх з днем захисника України, дякуємо кожній людині що боронить нашу неньку 🇺🇦

Для того щоб захистити наші з вами web додатки, пропоную вашій увазі також чітліст корисних лінок по WEB Penetration Testing

Збережіть собі до закладок, та практикуйтесь

https://github.com/Ignitetechnologies/bugbounty

#security #penetration

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

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

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

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

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

Продукт/домен - для тих что хоче стати професійним експертом в певній ніші, наприклад 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 тестування

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

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

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

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

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

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