Test Plan Test Plan Тест план Test

Test Plan

Test Plan Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования.

Тест план нужен для того, чтобы зафиксировать на «бумаге» все то, что и как вы планируете делать с продуктом, чтобы на финише принять решение о его качестве и принять решение, достаточно этого или нет, чтобы выпускать его на рынок.

Цель тест плана — зафиксировать наши активности по тестированию. Количество смысловых секций тест плана может быть разным, но их должно быть достаточно для того, чтобы и заказчик, и менеджер, и тест лид, и тестировщики имели общую, одинаковую картину тестирования на проекте.

Что надо тестировать? o описание объекта тестирования: системы, приложения, оборудования Что будете тестировать? o список функций и описание тестируемой системы и её компонент в отдельности Как будете тестировать? o стратегия тестирования

Когда будете тестировать? o последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) Критерии начала тестирования: o готовность тестовой платформы (тестового стенда) o законченность разработки требуемого функционала o наличие всей необходимой документации o. . .

Критерии окончания тестирования: o результаты тестирования удовлетворяют критериям качества продукта: § требования к количеству открытых багов выполнены § выдержка определенного периода без изменения исходного кода приложения § выдержка определенного периода без открытия новых багов

Вы можете изменить стратегию тестирования или добавить/убрать виды тестов, при этом не поменяв тест план?

Мы будем проводить функциональное тестирование? Да? Где это написано? Насколько глубоко мы будем тестировать? Где это написано? Мы будем делать тесты производительности, надежности и т. п. ? Где это написано?

На все эти (и другие) вопросы мы должны уметь отвечать, ссылаясь на тест план или другие документы, на которые уже ссылается сам тест план.

http: //www. runtestrun. com/

Test case

Тестовый случай в разработке программного обеспечения ― это набор условий, при которых тестировщик будет определять, удовлетворяется ли заранее определённое требование.

Виды Тестовых Случаев

Тест кейсы разделяются по ожидаемому результату на позитивные и негативные: Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию. Негативный тест кейс оперирует как корректными так и некорректными данными.

Структура Тестовых Случаев

Каждый тест кейс должен иметь 3 части: Pre. Conditions - список действий, которые приводят систему к состоянию пригодному для проведения основной проверки.

Test Case Description Список действий переводящий систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям

Post. Conditions Список действий, переводящий систему в первоначальное состояние (состояние до проведения теста) Post Conditions - не является обязательной частью.

Test case 1. Summary (краткое описание / название); 2. Окружение; 3. Шаги воспроизведения; 4. Ожидаемый результат; 5. Фактический результат; 6. Любая информация которая облегчит исправление

Checklist Кто незамутненно уверен в том, что чек-лист – стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. (c) Алексей Лупан

Баг Репорт

Баг репорт - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Bugreport

Tools 1. Jira - не только таск менеджер, но и удобный тестменеджмент инструмент. Но, настраивать надо. 2. Test Link - неплохая, бесплатная, но, несколько “деревянная” система управления тестами. 3. HP Quality Center - отличный платный инструмент. 4. Gemini - еще один годный инструмент. Проприетарен. 5. IBM Rational Quality Manager - еще один проприетарный годный инструмент. 6. Достаточно много Open Source решений. 7. Разнообразные Wiki движки.

Practice 1. Написать несколько (до 4 -х) тест-кейсов для поиска товаров в магазине http: //rozetka. com. ua 2. Набросать чеклист для тестирования формы регистрации магазина http: //rozetka. com. ua (10 случаев).