Successfully reported this slideshow.

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

2

Share

Upcoming SlideShare
Tz template
Tz template
Loading in …3
×
1 of 32
1 of 32

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

2

Share

Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.

Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.

More Related Content

More from QAFest

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

QA Fest 2015. Aлександр Кузняк. Тестовая документация. How-To и типичные ошибки

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

×