Что такое тест-план? И почему было бы неплохо, чтобы он у вас был...

Прошлая часть: Что такое релиз? Что такое тестовый набор? Что такое тестовый запуск?

Добрейшего вам времени суток.

Сегодня пройдемся по теме «тест-плана» и начнем с определения.

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

Тест-план отвечает на вопросы:

• Что необходимо тестировать?
• Что будете тестировать?
• Как будете тестировать?
• Когда будете тестировать?
• Какие критерии начала тестирования?
• Какие критерии окончания тестирования.

Скажу честно – за шесть лет работы, в том числе в роли лида тестирования, я ни разу не видел тест-план как документ. Оно и понятно – каждые 2 недели штамповать новый документ на тему «Как нам работать ближайшие две недели» - звучит как минимум странно и чрезвычайно бюрократично. Более того – начинающие инженеры не имеют достаточного количества навыков, чтобы составить такой документ на весь тестируемый продукт. Если же вы захотите подробно разобраться что такое тест-план – советую вам прочитать статью на protesting.ru

Но вам всё же стоит знать «что такое тест-план» и вот почему. Может быть, вы и не можете спланировать тестирование всего продукта, но можете спланировать тестирование своих конкретных задач. И это вам сильно поможет в плане организации вашего личного рабочего процесса. Итак, пройдемся по вопросам, на которые должен отвечать тест-план.

Что необходимо тестировать?

Ответ, казалось бы, простой – тот продукт, который разрабатывает ваша команда разработки. Но есть пара нюансов:

1. Ваша команда разработки может разрабатывать несколько продуктов (если ваша компания занимается заказной разработкой).

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

То есть вы должны чётко понимать – «Мне необходимо протестировать вот этот продукт и как его тестировать я не имею ни малейшего понятия и иду читать требования и задавать вопросы» или «Мне необходимо протестировать вот эту подсистему нашего продукта. Я знаю ее как свои пять пальцев и это будет просто».

Что будете тестировать?

Вопрос похож на предыдущий, но он скорее носит более функциональный характер. Вам необходимо понимать какой функционал разрабатывается или дорабатывается. А также понимать на какие существующие функции системы новый разрабатываемый функционал может повлиять. Ну и самой идеальной ситуацией для вас будет, если вы дадите себе ответ на вопросы: «А что вообще этот функционал делает для системы в целом?» и «А зачем этот функционал нужен конечному пользователю». Резюмируем ответы, которые плюс-минус должны сложиться у вас в голове:

1. «Пользователи хотят получить функциональность, которая нужна им для <…> и я ее буду тестировать».

2. «Данная функциональность в рамках нашей системы отвечает за создание и изменение <…> и, соответственно, повлияет на уже существующие функции <…>».

3. «В рамках доработки новой функциональности мне надо проверить следующие моменты <…>».

4. «В рамках проверки этой доработки мне надо не забыть перепроверить уже существующие части системы <…>».

Как будете тестировать?

Знали бы вы, как часто я слышал вопрос «А как это протестировать?». Для начала примите тот факт, что тестировать можно всё – просто вам необходимо найти какое-то своё решение к проблеме тестирования конкретной функциональности, вы же инженер. Следующий факт, который стоит принять – существует огромное количество технологий и подходов к их использованию при разработке ПО. Вам может достаться тестирование пользовательских интерфейсов (UI), программных интерфейсов самого приложения (API), тестирование интеграционного взаимодействия через брокеров сообщений или менеджеров очередей, тестирование доработок баз данных, тестирование конфигурационных файлов, нагрузочное тестирование приложения, тестирование безопасности и так далее, и тому подобное. Мы обязательно рассмотрим большую часть из них, но в отдельных главах. Конкретно в этой главе я дам вам пару советов, которые будут относительно универсальны от задачи к задаче.

1. Задавайте вопросы более опытным коллегам тестировщикам если вам непонятно как тестировать задачу.
2. Не стесняйтесь спрашивать разработчиков о том, как тестировать задачу – «На безрыбье и рак рыба». Большая часть разработчиков тестируют свои задачи самостоятельно перед передачей задач на тестирование – вам просто необходимо выяснить каким подходом они пользовались и применить его для своих тестов.
3. Не забывайте про техники тест-дизайна (ссылка)
4. Помните, что скорее всего всё уже было придумано за вас. Не знаете «как тестировать взаимодействие через брокеров сообщений?» - так поищите в гугле, на ютюбе или спросите у искусственного интеллекта в чате

Когда будете тестировать?

Тут тоже не все так очевидно, как могло бы показаться из вопроса. В идеальной картине мира, если ваша задача не имеет никаких зависимостей ситуация обстоит следующим образом. Разработчик окончил работу над задачей и передал ее вам – вы начали тестировать. Таких задач будет большинство. Но будут и задачи, которые могут зависеть от других задач или даже от других команд разработки.

Например, у вас есть две задачи – задача №1 и задача №2, где задача №2 зависит от реализации задачи №1. При этом над задачами работают два разных разработчика и два разных тестировщика. Вам досталась задача №2 и ваш разработчик закончил над ней работу, но вы не можете начинать тестировать ее так как задача №1 не готова. В данном примере ответом на вопрос «Когда будете тестировать?» будет «Когда будет готова моя задача №2 и основная задача №1».

Другой пример. Вы проверяете взаимодействие с другой системой, которую разрабатывает другая команда разработки. Есть задача №3, которую реализовывала ваша команда, и задача №4, которую разрабатывает другая команда. Ваша команда закончила, но для начала тестирования вам нужна готовность задачи №4 и готовность другой команды выделить время на тестирование. В данном примере ответом на вопрос «Когда будете тестировать?» будет «Когда будет готова моя задача №3, а также когда команда из другой системы закончит разработку задачи №4 и будет готова провести с нами совместное тестирование». Данный пример немножечко «высосан из пальца» – существуют подходы к тестированию задачи №3 и без коллег от соседней команды, но тестирование полноценного взаимодействия между системой будет возможно только при готовности обеих задач и обеих команд к тестированию.

Также не стоит забывать по поводу готовности тестового стенда к тестированию. Так как задачи надо где-то тестировать – для целей тестирования выделяются специальные сервера, на которые устанавливаются промежуточные сборки, и в рамках этих промежуточных сборок тестируются задачи. Тестовый стенд – это сервера, на которые устанавливается ПО для целей тестирования, и к этим стендам не имеют доступ пользователи. Чтобы начать тестировать конкретную задачу вам необходимо получить сборку, которая будет содержать определенный код, который как раз таки и добавлялся или изменялся в рамках вашей задачи. Также не стоит забывать про настройки тестового стенда – часто задачи кроме изменения кода содержат дополнительные настройки, которые необходимо выполнить на серверах, прежде чем приступать к тестированию, иначе задача просто не заработает. Все эти нюансы необходимо держать в голове.

Критерии начала тестирования

Сформулируемте критерии начала тестирования, которых вам будет достаточно в большинстве случаев:

1. В требованиях и в задаче закрыты все открытые вопросы. Это будет означать, что задача должна быть реализована только так как указано в постановке задачи / требованиях и никак иначе.
2. По задаче окончена разработка. Обычно в таком случае у задачи меняется статус на «Готова к тестированию» и ее в явном виде назначают на вас. От проекта к проекту правила перевода задач на тестировщиков разнятся – эти правила лучше уточнить, когда устраиваетесь на новый проект
3. Тестовый стенд готов к тестированию (часть 1) – на стенд установлена сборка, которая содержит код по задаче, которую необходимо тестировать. И снова – сборки устанавливаются на тестовый стенд по-разному от проекта к проекту. Ответ на вопрос «Как установить нужную мне сборку на нужный мне стенд?» также необходимо уточнять у своей команды.
4. Тестовый стенд готов к тестированию (часть 2) – если по задаче необходимо выполнить специфические настройки самого сервера – они должны быть выполнены до начала тестирования, иначе код может попросту не заработать.
5. Ну и самое очевидное – у вас появилось время для тестирования конкретной задачи.

Критерии окончания тестирования

Тут сложно будет сказать что-либо кроме самого очевидного – заканчивать тестирование задачи надо, когда:

1. Тестирование выполнено в запланированном объеме – те проверки, которые вы считали нужным провести – проведены.

2. По задаче исправлены все блокирующие и критические дефекты.

3. У вас закончилось время на тестирование задачи. Этот момент необходимо дополнительно обсуждать внутри команды, ведь если задача протестирована не полностью – она несет в себе возможные риски (от неприятных всплывающих ошибок на формах до потери данных). Эти риски необходимо озвучить, а бизнесу необходимо их принять.

Краткий итог

Давайте подведем итог по написанному выше.

В привычном для всех понимании тест-план — это именно документ. С этим ничего не поделаешь – уж вот так придумали всё это за нас. Но никто вам не мешает взять из «бюрократической машины» всё хорошее и откинуть всё ненужное. Постарайтесь просто превратить это в своеобразный «чек-лист», который вам необходимо пройти с самим собой перед тем, как сломя голову бежать и тестировать задачу – это займет минут 5, но сэкономит вам немало времени. Разумеется, никто вас не заставит что-то планировать по своим задачам, и вы можете импровизировать от задачи к задаче, разбираясь на ходу. Но с таким подходом вы просто всегда будете в позиции отстающего относительно инженера, который хоть немного, но планирует своё рабочее время.

Следующая часть: Что такое баг? Что такое баг-репорт? И для кого на самом деле нужны баги?

Поддержать или поблагодарить можете:

Лайком;

Комментарием;

Подпиской на канал;

#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля #ТестПлан