Web Testing in Agile

Різниця між Agile і класичним підходами в тестуванні:(тут могла бути ваша реклама :D) Традиційне тестування Agile тестування

Планування Детальний аналіз т.з, планування і оформлення тестових артефактів

Аналіз (наскільки це можливо) до розробки, який не рідко проводжується в ході самої розробки і тестування

Документація В обов’язковому порядку Коли доцільно і скільки потрібно

Реліз Відповідність всім основним вимогам в Т.З. (тобто здобуття хоча б жовтого статусу) тими елементами, з яких реліз власне і складається

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

Політика щодо змін і введення нових фіч

Менеджмент і контроль: аналізуються нові елементи ТЗ. Регрес-підтримка, документація (тест-кейси і знову таки регрес)

Як вийде

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

Рахується невід’ємною частиною. Всеосяжна. Робиться за принципом “Хто і скільки зможе”. В ідеалі має здійснюватись за принципом White-box автоматизація зі сторони девів (юніт-тести за принципом TDD), у купі з Black-box (GUI автоматизацією зі сторони тестерів (т.з. “Рука руку миє”)

Схема розробки в Waterfall vs Схема розробки в Agile

Waterfall: Аналіз Дизайн Імплементація Підтримка

Реальність: Аналіз Дизайн Імплементація Підтримка Agile: Аналіз Дизайн Імплементація Підтримка

Реальність: PURE RANDOM

Коротко про головне

1. Тестова Документація

- не потрібно вести, якщо не просять;

- обговорювати з замовником час і елементи проекту, які будуть піддаватись покриттю;

- попередити про негативні аспекти.

2. Підготовка до тестування

- бути готовим до відсутності т.з.

- smoke та exploratory testing - ваші основні друзі;

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

3. Автоматизація

1) Юніт тести = GUI тести.

2) Автоматизовує той, хто може.

3) Краще жодної автоматизації ніж “якась”.

4. Team Coop1) Всі в команді рівні (тобто суть скраму чи daily meeting/standup для звітності

один перед одним).

2) Аналіз спецификацій/оцінка виконання роботи при старті чи змінах в проекті має відбуватись одночасно всіма членами команди. Таким чином всі будуть відповідати за результат еквівалентно.

3) При можливості, проводити тестування на машині розробника.

4) Тісний контакт, більше вербальної комунікації як найшвидшого і найефективнішого способу адресації дефектів, обговорення реалізації, спільного аналізу т.з.

Додатково декілька слів про Agile

1) Взаємозаміна ролей в команді;2) Введення поняття “tester programmer”.3) Необхідність постійної вербальної комунікації,

взаємна відповідальність і справжній командний дух.4) Необхідність і шанс постійного самовдосконалення.5) Виникнення спричинене вимогами ринку та бізнесу

(менше затрат на більший по собівартості продукт).

Situational Awareness in Agile:

(хаос породжує порядок)

Ordo ab chaos

1) Agile Software Testing with James Bach;https://www.youtube.com/watch?v=SAhJf36_u5U2) Google Talks. Agile Testing. Elisabeth Hendrickson https://www.youtube.com/watch?v=bqrOnIECCSg3) Концепція побудови тестування в Agile проектах 3+1.https://www.youtube.com/watch?v=UW8sTq8SuFQ4) Agile тестування за версією API 2GIS.https://www.youtube.com/watch?v=X7Wpe6b-Clc5) Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin:http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

Sources of Inspiration