Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
2. 22
Вот о чём мы поговорим
И конечно же я отвечу на вопросы
• Почему существует?
• Тест План
• Тест Кейсы и Тест Сценарии
• Чеклист
• Принципы подхода к созданию
• Отчеты (Репорты)
• Типичные ошибки
3. 33
Какой у меня опыт?
И чем я занимаюсь последние 11 лет
• 11 лет работаю в IT-сфере
• 7+ лет в QA
• 4+ года в Management-е: занимаюсь созданием, развитием и
управлением:
• Команд
• Проектов
• Департаментов
• Консалтинг-сервисами
и занимаю позиции Delivery-уровня.
• Участвовал в 100+ проектах
• Проинтервьюировал 350+ человек
• Глава судейского комитета по направлению QA всеукраинского
конкурса веб-разработки с 2012 по 2015 год
• Развиваю IT-обучение и раскрываю возможности талантливых
людей в Украине; помогаю им находить компании, а компаниям –
находить их
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
12. 1212
TEST PLAN v 2.0
Начинаем разбираться с задачами до их фактической реализации
ДУМАТЬ ЗАРАНЕЕ – что, как зачем и
почему мы будем делать, что использовать,
как это будет работать...
13. 1313
TEST PLAN v 2.0
Знакомимся, обсуждаем, предупреждаем риски
РАБОТА С КОМАНДОЙ – до
фактического старта разработки, alignment
в подходах и их необходимости!
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
alex.kuznyak@gmail.com
alexk@goit.com.ua
Александ
р
Кузняк
