IT CAFE III. Testing Web in Agile.

1. Web Testing in Agile

2. Різниця між Agile і класичним підходами в тестуванні:
(тут могла бути ваша реклама :D) Традиційне тестування Agile тестування
Планування Детальний аналіз т.з, планування і
оформлення тестових артефактів
Аналіз (наскільки це можливо) до
розробки, який не рідко
проводжується в ході самої розробки і
тестування
Документація В обов’язковому порядку Коли доцільно і скільки потрібно
Реліз Відповідність всім основним вимогам
в Т.З. (тобто здобуття хоча б жовтого
статусу) тими елементами, з яких
реліз власне і складається
Прийняття рішення щодо релізу (або
не релізу) певної частини елементів
приймається шляхом переговорів за
ланцюгом тестувальник/дев-
лід/ПМ/замовник
Політика щодо змін і введення нових
фіч
Менеджмент і контроль: аналізуються
нові елементи ТЗ. Регрес-підтримка,
документація (тест-кейси і знову таки
регрес)
Як вийде
Автоматизація Далеко не завжди присутня. Якщо
впроваджується, то чітко згідно
раніше обумовлених специфікацій і
часових проміжків з допомогою
одного раніше затвердженого (чи в
рамках компанії чи обумовленого в
проекті) інструменту.
Рахується невід’ємною частиною.
Всеосяжна. Робиться за принципом
“Хто і скільки зможе”. В ідеалі має
здійснюватись за принципом White-box
автоматизація зі сторони девів
(юніт-тести за принципом TDD), у купі
з Black-box (GUI автоматизацією зі
сторони тестерів (т.з. “Рука руку миє”)

3. Схема розробки в Waterfall vs Схема розробки в Agile
Waterfall: Аналіз Дизайн Імплементація Підтримка
Реальність: Аналіз Дизайн Імплементація Підтримка
Agile: Аналіз Дизайн Імплементація Підтримка
Реальність: PURE RANDOM

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

5. 1. Тестова Документація
- не потрібно вести, якщо не просять;
- обговорювати з замовником час і елементи
проекту, які будуть піддаватись покриттю;
- попередити про негативні аспекти.

6. 2. Підготовка до тестування
- бути готовим до відсутності т.з.
- smoke та exploratory testing - ваші основні друзі;
- самим оптимальним документом на
підготовчому етапі тестування рахується чекліст.

7. 3. Автоматизація
1) Юніт тести = GUI тести.
2) Автоматизовує той, хто може.
3) Краще жодної автоматизації ніж “якась”.

8. 4. Team Coop
1) Всі в команді рівні (тобто суть скраму чи daily meeting/standup для звітності
один перед одним).
2) Аналіз спецификацій/оцінка виконання роботи при старті чи змінах в
проекті має відбуватись одночасно всіма членами команди. Таким чином
всі будуть відповідати за результат еквівалентно.
3) При можливості, проводити тестування на машині розробника.
4) Тісний контакт, більше вербальної комунікації як найшвидшого і
найефективнішого способу адресації дефектів, обговорення реалізації,
спільного аналізу т.з.

9. Додатково декілька слів про Agile
1) Взаємозаміна ролей в команді;
2) Введення поняття “tester programmer”.
3) Необхідність постійної вербальної комунікації,
взаємна відповідальність і справжній командний дух.
4) Необхідність і шанс постійного самовдосконалення.
5) Виникнення спричинене вимогами ринку та бізнесу
(менше затрат на більший по собівартості продукт).

11. Situational Awareness in Agile:

12. Ordo ab chaos
(хаос породжує порядок)

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

14. Download links:
PDF:
http://store.internetdevels.
com/f/c7089ab3e1/testing_web_in_agile_1.
pdf
PPTX:
http://store.internetdevels.
com/f/c7089ab3e1/testing_web_in_agile_1_