Feeds:
Записи
Комментарии

Archive for the ‘Exploratory testing’ Category

Весьма рассудительная статья План тестирования на блоге «Про тестинг».

Для тех, кто только что присоединился

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

Резюме статьи краткое:

хороший тест план должен как минимум отвечать на следующие вопросы:

  1. что надо тестировать (объект тестирования: система, приложение, оборудование)
  2. что будете тестировать (список функций и компонент тестируемой системы)
  3. как будете тестировать (стратегия тестирования — виды тестирования и их применение по отношению к тестируемому объекту)
  4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
  5. критерии начала и окончания тестирования

Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.

Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…

На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…

Ну так, рецепт:

  1. Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
  2. В каждом модуле перечислить доступные функции.
  3. Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
  4. Проверять каждый пункт последовательно.

В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.

Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.

Простой тест-план, он же чек-лист, готов.

Еще раз — этот вариант подходит для ситуаций, когда времени на составление документов нет. Или когда нет необходимости в составлении околотестировочных документов.

Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.

Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».

Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0

 

Read Full Post »

В багтрекере появился баг №666 — за моей подписью.

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

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

И приписали мне: » ISSUE 666 — НЕ БАГ!»

Issue — CLOSED. 😦

Надо было написать в трекере, что «Воспроизведение этого бага гарантированно отформатирует вам винт…»

Read Full Post »

« Newer Posts

%d такие блоггеры, как: