Слайд 5Test Plan
Тест план (Test Plan) - это документ, описывающий весь
объем работ по тестированию, начиная с описания объекта, стратегии, расписания,
критериев начала и окончания тестирования.
Слайд 7Тест план нужен для того, чтобы зафиксировать на «бумаге» все
то, что и как вы планируете делать с продуктом, чтобы
на финише принять решение о его качестве и принять решение, достаточно этого или нет, чтобы выпускать его на рынок.
Слайд 8Цель тест плана — зафиксировать наши активности по тестированию. Количество
смысловых секций тест плана может быть разным, но их должно
быть достаточно для того, чтобы и заказчик, и менеджер, и тест лид, и тестировщики имели общую, одинаковую картину тестирования на проекте.
Слайд 9Что надо тестировать?
описание объекта тестирования: системы, приложения, оборудования
Что будете тестировать?
список
функций и описание тестируемой системы и её компонент в отдельности
Как
будете тестировать?
стратегия тестирования
Слайд 10Когда будете тестировать?
последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing),
анализ результатов (Test Result Analisys)
Критерии начала тестирования:
готовность тестовой платформы
(тестового стенда)
законченность разработки требуемого функционала
наличие всей необходимой документации
...
Слайд 11Критерии окончания тестирования:
результаты тестирования удовлетворяют критериям качества продукта:
требования к количеству
открытых багов выполнены
выдержка определенного периода без изменения исходного кода приложения
выдержка определенного периода без открытия новых багов
Слайд 12Вы можете изменить стратегию тестирования или добавить/убрать виды тестов, при
этом не поменяв тест план?
Слайд 13Мы будем проводить функциональное тестирование?
Да? Где это написано?
Насколько
глубоко мы будем тестировать?
Где это написано?
Мы будем делать
тесты производительности, надежности и т.п.?
Где это написано?
Слайд 14На все эти (и другие) вопросы мы должны уметь отвечать,
ссылаясь на тест план или другие документы, на которые уже
ссылается сам тест план.
Слайд 20Тестовый случай в разработке программного обеспечения ― это набор условий,
при которых тестировщик будет определять, удовлетворяется ли заранее определённое требование.
Слайд 22Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
Позитивный
тест кейс использует только корректные данные и проверяет, что приложение
правильно выполнило вызываемую функцию.
Негативный тест кейс оперирует как корректными так и некорректными данными.
Слайд 24Каждый тест кейс должен иметь 3 части:
PreConditions - список действий,
которые приводят систему к состоянию пригодному для проведения основной проверки.
Слайд 25Test Case Description
Список действий переводящий систему из одного состояния в
другое, для получения результата, на основании которого можно сделать вывод
о удовлетворении реализации, поставленным требованиям
Слайд 26PostConditions
Список действий, переводящий систему в первоначальное состояние (состояние до проведения
теста)
Post Conditions - не является обязательной частью.
Слайд 27Test case
Summary (краткое описание / название);
Окружение;
Шаги воспроизведения;
Ожидаемый результат;
Фактический результат;
Любая информация
которая облегчит исправление
Слайд 31Checklist
Кто незамутненно уверен в том, что чек-лист – стопроцентная панацея
в работе тестировщика, тот дурак. Зависит от проекта и уровня
образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем.
(c) Алексей Лупан
Слайд 33Баг репорт - это документ, описывающий ситуацию или последовательность действий
приведшую к некорректной работе объекта тестирования, с указанием причин и
ожидаемого результата.
Слайд 35Tools
Jira - не только таск менеджер, но и удобный тест-менеджмент
инструмент. Но, настраивать надо.
Test Link - неплохая, бесплатная, но, несколько
“деревянная” система управления тестами.
HP Quality Center - отличный платный инструмент.
Gemini - еще один годный инструмент. Проприетарен.
IBM Rational Quality Manager - еще один проприетарный годный инструмент.
Достаточно много Open Source решений.
Разнообразные Wiki движки.
Слайд 36Practice
1. Написать несколько (до 4-х) тест-кейсов для поиска товаров в
магазине http://rozetka.com.ua
2. Набросать чеклист для тестирования формы регистрации магазина http://rozetka.com.ua
(10 случаев).