11
QA FEST
Кузняк Александр
Тестовая документация
How-To
и типичные ошибки
22
Вот о чём мы поговорим
И конечно же я отвечу на вопросы 
• Почему существует?
• Тест План
• Тест Кейсы и Тест Сценарии
• Чеклист
• Принципы подхода к созданию
• Отчеты (Репорты)
• Типичные ошибки
33
Какой у меня опыт?
И чем я занимаюсь последние 11 лет
• 11 лет работаю в IT-сфере
• 7+ лет в QA
• 4+ года в Management-е: занимаюсь созданием, развитием и
управлением:
• Команд
• Проектов
• Департаментов
• Консалтинг-сервисами
и занимаю позиции Delivery-уровня.
• Участвовал в 100+ проектах
• Проинтервьюировал 350+ человек
• Глава судейского комитета по направлению QA всеукраинского
конкурса веб-разработки с 2012 по 2015 год
• Развиваю IT-обучение и раскрываю возможности талантливых
людей в Украине; помогаю им находить компании, а компаниям –
находить их 
44
Тестовая документация?
Что это?!
Тестовая документация –
артефакты, которые тестировщик
использует в своей работы
55
Тестовая документация
А что без них никак?!
Цель - …
66
Тестовая документация
А что без них никак?!
Цель – сделать процесс работы и её
результат максимально эффективным,
прозрачным и измеряемым!
77
Основные виды тест артефактов
Мы рассмотрим несколько из них
• Test Plan
• Test Case / Test Scenario
• QA Checklist
• Bugs
• QA Report
88
TEST PLAN
И с чем его едят 
Test Plan –
…
99
TEST PLAN
И с чем его едят 
Test Plan –
организационный документ, описывающий
весь объем работ по тестированию, начиная
с blah blah blah…
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
1111
TEST PLAN v 2.0
Да ну ладно...
В 95% случаев – НЕТ!!!
1212
TEST PLAN v 2.0
Начинаем разбираться с задачами до их фактической реализации
ДУМАТЬ ЗАРАНЕЕ – что, как зачем и
почему мы будем делать, что использовать,
как это будет работать...
1313
TEST PLAN v 2.0
Знакомимся, обсуждаем, предупреждаем риски
РАБОТА С КОМАНДОЙ – до
фактического старта разработки, alignment
в подходах и их необходимости!
1414
TEST PLAN v 2.0
А что же надо?!
1515
Test Case / Test Scenario
А что есть разница?! оО
РАЗНИЦА ЕСТЬ – но куда важнее
понимать ДЛЯ ЧЕГО они использутся!
1616
Test Case
В двух словах буквально
Test Case – выполнение последовательности
действий при заданных условиях для
получения ожидаемого результата
Выглядит вот
как-то так
1717
Test Case
Зачем он нужен?!
Для понимания того какие именно
позитивные и негативные тесты надо
выполнить для определённой
составляющей продукта
1818
Test Scenario
В двух словах буквально
Test Scenario – высокоуровневая
классификация и последовательность
тестовых требований
сформированная относительно
функциональности или
пользовательского сценария
Выглядит
вот как-то
так
1919
Test Scenario
Зачем он нужен?!
Минимизация количества тестов
Группировка Тест Кейсов
Упрощение ориентирования
2020
QA Checklist
Самый простой и популярный у нас артефакт
QA Checklist – упрощенный вариант
набора test case-ов, где проверки не
расписываются подробно, а имеют, только
summary и два варианта результата
2121
QA Checklist
Зачем он нужен?
Когда чеклист – хорошо?
• Простые проверки с ответом данет
• Смоук или Рергешен тесты
• Минимизация временных затрат
• Наборы проверок для подтверждения или опровержения чего-либо
• Когда вы вы единственный QA на проекте и точно будете до его конца
• Когда проект очень короткий (до трёх месяцев) или очень простой
• Простые Функциональные и GUI-тесты
2222
QA Checklist
Зачем он нужен?
Когда чеклист – плохо?
• Сложные тесты с большим количеством шагов
• Не функциональные тесты:
• Security
• Load / Performance
• Usability
• Сложный для понимания продукт
• Большая команда тестировшиков где возможны изменения
• Длительный огромный с функциональной точки зрения проект
2323
Что НЕЛЬЗЯ делать!
И что многие часто делают... К сожалению
Типичные ошибки:
• Время, потраченное на работу с артефактами более 20% от общего
времени работы тестировщика
• Излишний перфекционизм и ненужные детали
• Лишние или неполезные пункты или поля
• Неправильный иструмент для работы
• Неправильный подход к созданию
• Отсутствие конкретики
• Хаотическая структура
• Понятны только создателю
2424
Что есть QA Report?
И какими они бывают в наших реалиях
QA Report – любой отчёт по оценке
качества составленный тестировщиком
2525
Рассмотрим два вида отчётов
Первый - Test Summary Report - большой, толстый и серьезный
Test Summary Report – отчёт, который
содержит сводку проведенных тестовых
активностей и финальные результаты тестов.
Создается после завершения тестирования
2626
Привет стандарт IEEE 829 вновь 
Такого рода отчёты у нас пишут не часто...
Существует с 1998 года – поэтому
слабо применяется в современном мире
тестирования ПО.
Концентрироваться на этом нём стоит.
2727
QA Report по завершенной итерации
Назовём, допустим, QA Sprint Report
QA Sprint Report – отчёт показывающий
результаты оценки качества выполненной
работы за последнюю итерацию.
2828
Sprint QA Report
Что внутри?
Внутри имеем:
• Дата/номер билда/спринта
• Рекомендации QA-я о «готовности» к чему-либо: демо, user acceptance testing,
production update и другое
• Результаты тестирования того, что вошло в итерацию или было запланировано:
• Результаты Мануальных и автоматизированных тестов
• Визуализация статистики (по тест кейсам, чек листам и т.д.)
• Покрытие тестами
• Статистика по багам:
• Описание открытых багов, например, уровня Blocker/Critical/Major
• Визуализированная статистика по открытым и закрытым багам
• Выводы/Решение
Можно дополнить:
• Расширенной информацией по видам и типам проведенных тестов и их результатами
• Изменением ситуации по сравнению с прошлой, позапрошлой, ... итерациями с
визуализацей
• Наличием Improvement-ов или Suggestion-ов
• Различной спецификой, которая касается продукта
2929
В чём делаем?
Инструменты
3030
Важно помнить
Честно, очень важно!
Будьте ТОЧНЫ в формулировках
Храните в ОДНОМ месте
Показывайте КОМАНДЕ
Полезность через результативность!
3131
Типичные ошибки или что нельзя делать?
В реальности почему-то происходит наоборот 
Типичные ошибки в QA-репортах:
• Неинформативность
• Общие фразы без конкретики
• Плохая визуализация или её отсутствие
• Отсутствие выводов/решений
• Нет статистики по выполненной работе
Типичные ошибки, связанные с процессом:
• Нарушена или отсуствует систематичность
• Отсутствие формата или его хаотичность
• Неверные инструменты составления и «внешний вид»
• Используются неверные инструменты предоставления, как email или
Skype, или в устной форме
• Хранятся в разных местах или не хранятся вовсе
• Сложность поиска и статистики
• Нет анализа предыдущих итераций
• Не берутся во внимание РМ-ом/PO-ом и разработчиками
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
Александ
р
Кузняк

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 v2.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 v2.0 Да ну ладно... В 95% случаев – НЕТ!!!
  • 12.
    1212 TEST PLAN v2.0 Начинаем разбираться с задачами до их фактической реализации ДУМАТЬ ЗАРАНЕЕ – что, как зачем и почему мы будем делать, что использовать, как это будет работать...
  • 13.
    1313 TEST PLAN v2.0 Знакомимся, обсуждаем, предупреждаем риски РАБОТА С КОМАНДОЙ – до фактического старта разработки, alignment в подходах и их необходимости!
  • 14.
    1414 TEST PLAN v2.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 Что есть QAReport? И какими они бывают в наших реалиях QA Report – любой отчёт по оценке качества составленный тестировщиком
  • 25.
    2525 Рассмотрим два видаотчётов Первый - Test Summary Report - большой, толстый и серьезный Test Summary Report – отчёт, который содержит сводку проведенных тестовых активностей и финальные результаты тестов. Создается после завершения тестирования
  • 26.
    2626 Привет стандарт IEEE829 вновь  Такого рода отчёты у нас пишут не часто... Существует с 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-ов • Различной спецификой, которая касается продукта
  • 29.
  • 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 Александ р Кузняк