QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки
- 1. 11 QA FEST Кузняк Александр Тестовая документация How-To и типичные ошибки
- 2. 22 Вот о чём мы поговорим И конечно же я отвечу на вопросы • Почему существует? • Тест План • Тест Кейсы и Тест Сценарии • Чеклист • Принципы подхода к созданию • Отчеты (Репорты) • Типичные ошибки
- 3. 33 Какой у меня опыт? И чем я занимаюсь последние 11 лет • 11 лет работаю в IT-сфере • 7+ лет в QA • 4+ года в Management-е: занимаюсь созданием, развитием и управлением: • Команд • Проектов • Департаментов • Консалтинг-сервисами и занимаю позиции Delivery-уровня. • Участвовал в 100+ проектах • Проинтервьюировал 350+ человек • Глава судейского комитета по направлению QA всеукраинского конкурса веб-разработки с 2012 по 2015 год • Развиваю IT-обучение и раскрываю возможности талантливых людей в Украине; помогаю им находить компании, а компаниям – находить их
- 4. 44 Тестовая документация? Что это?! Тестовая документация – артефакты, которые тестировщик использует в своей работы
- 5. 55 Тестовая документация А что без них никак?! Цель - …
- 6. 66 Тестовая документация А что без них никак?! Цель – сделать процесс работы и её результат максимально эффективным, прозрачным и измеряемым!
- 7. 77 Основные виды тест артефактов Мы рассмотрим несколько из них • Test Plan • Test Case / Test Scenario • QA Checklist • Bugs • QA Report
- 8. 88 TEST PLAN И с чем его едят Test Plan – …
- 9. 99 TEST PLAN И с чем его едят Test Plan – организационный документ, описывающий весь объем работ по тестированию, начиная с blah blah blah…
- 10. 1010 TEST PLAN v 2.0 Что внутри?! И ЧТО ВСЁ ЭТО РЕАЛЬНО НАДО?! оО • Test plan identifier • Introduction • Test items • Features to be tested • Features not to be tested • Approach • Item pass/fail criteria • Suspension criteria and resumption requirements • Test deliverables • Testing tasks • Environmental needs • Responsibilities • Staffing and training needs • Schedule • Risks and contingencies • Approvals
- 11. 1111 TEST PLAN v 2.0 Да ну ладно... В 95% случаев – НЕТ!!!
- 12. 1212 TEST PLAN v 2.0 Начинаем разбираться с задачами до их фактической реализации ДУМАТЬ ЗАРАНЕЕ – что, как зачем и почему мы будем делать, что использовать, как это будет работать...
- 13. 1313 TEST PLAN v 2.0 Знакомимся, обсуждаем, предупреждаем риски РАБОТА С КОМАНДОЙ – до фактического старта разработки, alignment в подходах и их необходимости!
- 14. 1414 TEST PLAN v 2.0 А что же надо?!
- 15. 1515 Test Case / Test Scenario А что есть разница?! оО РАЗНИЦА ЕСТЬ – но куда важнее понимать ДЛЯ ЧЕГО они использутся!
- 16. 1616 Test Case В двух словах буквально Test Case – выполнение последовательности действий при заданных условиях для получения ожидаемого результата Выглядит вот как-то так
- 17. 1717 Test Case Зачем он нужен?! Для понимания того какие именно позитивные и негативные тесты надо выполнить для определённой составляющей продукта
- 18. 1818 Test Scenario В двух словах буквально Test Scenario – высокоуровневая классификация и последовательность тестовых требований сформированная относительно функциональности или пользовательского сценария Выглядит вот как-то так
- 19. 1919 Test Scenario Зачем он нужен?! Минимизация количества тестов Группировка Тест Кейсов Упрощение ориентирования
- 20. 2020 QA Checklist Самый простой и популярный у нас артефакт QA Checklist – упрощенный вариант набора test case-ов, где проверки не расписываются подробно, а имеют, только summary и два варианта результата
- 21. 2121 QA Checklist Зачем он нужен? Когда чеклист – хорошо? • Простые проверки с ответом данет • Смоук или Рергешен тесты • Минимизация временных затрат • Наборы проверок для подтверждения или опровержения чего-либо • Когда вы вы единственный QA на проекте и точно будете до его конца • Когда проект очень короткий (до трёх месяцев) или очень простой • Простые Функциональные и GUI-тесты
- 22. 2222 QA Checklist Зачем он нужен? Когда чеклист – плохо? • Сложные тесты с большим количеством шагов • Не функциональные тесты: • Security • Load / Performance • Usability • Сложный для понимания продукт • Большая команда тестировшиков где возможны изменения • Длительный огромный с функциональной точки зрения проект
- 23. 2323 Что НЕЛЬЗЯ делать! И что многие часто делают... К сожалению Типичные ошибки: • Время, потраченное на работу с артефактами более 20% от общего времени работы тестировщика • Излишний перфекционизм и ненужные детали • Лишние или неполезные пункты или поля • Неправильный иструмент для работы • Неправильный подход к созданию • Отсутствие конкретики • Хаотическая структура • Понятны только создателю
- 24. 2424 Что есть QA Report? И какими они бывают в наших реалиях QA Report – любой отчёт по оценке качества составленный тестировщиком
- 25. 2525 Рассмотрим два вида отчётов Первый - Test Summary Report - большой, толстый и серьезный Test Summary Report – отчёт, который содержит сводку проведенных тестовых активностей и финальные результаты тестов. Создается после завершения тестирования
- 26. 2626 Привет стандарт IEEE 829 вновь Такого рода отчёты у нас пишут не часто... Существует с 1998 года – поэтому слабо применяется в современном мире тестирования ПО. Концентрироваться на этом нём стоит.
- 27. 2727 QA Report по завершенной итерации Назовём, допустим, QA Sprint Report QA Sprint Report – отчёт показывающий результаты оценки качества выполненной работы за последнюю итерацию.
- 28. 2828 Sprint QA Report Что внутри? Внутри имеем: • Дата/номер билда/спринта • Рекомендации QA-я о «готовности» к чему-либо: демо, user acceptance testing, production update и другое • Результаты тестирования того, что вошло в итерацию или было запланировано: • Результаты Мануальных и автоматизированных тестов • Визуализация статистики (по тест кейсам, чек листам и т.д.) • Покрытие тестами • Статистика по багам: • Описание открытых багов, например, уровня Blocker/Critical/Major • Визуализированная статистика по открытым и закрытым багам • Выводы/Решение Можно дополнить: • Расширенной информацией по видам и типам проведенных тестов и их результатами • Изменением ситуации по сравнению с прошлой, позапрошлой, ... итерациями с визуализацей • Наличием Improvement-ов или Suggestion-ов • Различной спецификой, которая касается продукта
- 30. 3030 Важно помнить Честно, очень важно! Будьте ТОЧНЫ в формулировках Храните в ОДНОМ месте Показывайте КОМАНДЕ Полезность через результативность!
- 31. 3131 Типичные ошибки или что нельзя делать? В реальности почему-то происходит наоборот Типичные ошибки в QA-репортах: • Неинформативность • Общие фразы без конкретики • Плохая визуализация или её отсутствие • Отсутствие выводов/решений • Нет статистики по выполненной работе Типичные ошибки, связанные с процессом: • Нарушена или отсуствует систематичность • Отсутствие формата или его хаотичность • Неверные инструменты составления и «внешний вид» • Используются неверные инструменты предоставления, как email или Skype, или в устной форме • Хранятся в разных местах или не хранятся вовсе • Сложность поиска и статистики • Нет анализа предыдущих итераций • Не берутся во внимание РМ-ом/PO-ом и разработчиками
- 32. 3232 Контакты Обращайтесь И чем я занимаюсь сейчас • Delivery Manager, Media dep. at Что мы делаем: • Media-проекты любой сложности для заказчиков по всему миру • Решаем любые технические задачи • Ищем и находим возможности там, где их не видят или не находят другие • Technical Coach & Business Partner at Что мы делаем: • Обучаем специалистов практически по всем IT-направлениям и специальностям • Помогаем людям найти компании, а компаниям – найти лучших специалистов • Развиваем IT-community в Украине alexander.kuznyak [email protected] [email protected] Александ р Кузняк