Как написать тест

Начинаем писать тесты (правильно)

Как начать писать тесты? Сколько нужно писать? На что их нужно писать, а на что — не нужно? Стоит ли всегда применять TDD? Если вас интересуют ответы на эти вопросы, то вы читаете правильную статью. В своей жизни я написал не одну тысячу тестов всех мастей для разных платформ, использовал во все поля TDD и ставил процесс тестирования в командах, проектах и даже целых компаниях. И теперь я попробую обобщить этот опыт и поделиться им.

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

Основная цель этой статьи — дать вам целостное понимание смысла тестирования. Понимая суть, вы сможете лучше мыслить критически и понимать, к чему нужно идти. Ну и, конечно, будет немного практических советов.

Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика

Начнем, пожалуй, с самого главного вопроса: зачем нам вообще нужно тестировать?

Чтобы быть уверенными в работоспособности нашего продукта. Заметьте, что я не написал «функций», «модуля», «кода» или «проекта». В конечном итоге имеет значение только то, что конечный продукт, которым пользуются (не всегда пользователи), работает, и делает он это хорошо. Хотя прямо сейчас это может показаться капитанством, но, как вы увидите позже, ориентация на цель позволит нам принимать правильные решения.

Следующий ключевой тезис не является особенностью процесса тестирования. Задачи можно условно поделить на два типа: они либо завершены, либо нет, а завершенность задач второго типа — это шкала, где 0 — это «ничего не сделано», а 1 — это сделано на 100%. При решении таких задач 100%-решение часто оказывается недостижимым из-за сверхвысоких накладных расходов.

Приведу прекрасный пример. Для многих сервисов критично такое понятие как SLA или, проще говоря, доступность сервиса. Например, на хостинговых площадках пишут что-то в духе «мы обеспечиваем доступность 99.9% наших серверов». Давайте прикинем, сколько часов за год хостинг может оказаться недоступен в рамках его SLA: 0.001 * 365 * 24 = 8.7 . В принципе, неплохо.

Предположим, что обеспечение такого уровня доступности обходится компании в 1000$ . А во сколько обойдется компании добавление каждой новой девятки в конце? То есть обеспечение 99.99 , 99.999 и так далее. Насколько мне известно, на таком уровне обеспечения происходит экспоненциальный (взрывной) рост стоимости. Я уже не говорю про то, что 100%-доступность является фантастикой.

Этот пример ярко демонстрирует то, что в задачах с плавающим результатом главным принципом является «максимальный результат за минимальные ресурсы». Другими словами, ищется баланс, при котором мы получаем результат, удовлетворяющий стейкхолдеров (заинтересованные лица), за приемлемый бюджет/сроки.

Теперь возвращаемся к нашим тестам и обнаруживаем, что тесты относятся именно к этому типу задач. Добавление первых тестов в проект дает невероятный эффект. Покрытие в 50% (половина кода вызывается в тестах) получается почти сразу, и по сравнению с отсутствием тестов — мы на два корпуса впереди. Дальше ситуация начинает меняться, и где-то на уровне 70-90% начинается резкое замедление роста покрытия, тесты становятся все более точечными, дорогими. Возрастает сложность их поддержки, рефакторинга.

Этот процесс бесконечен. Добиться 100% покрытия очень дорого и, скорее всего, неоправданно (см. пример выше). Кроме того, никакие тесты не дают вам полную гарантию работоспособности.

Кроме количества тестов и их качества, на стоимость также влияет то, какой тип тестов мы используем. Существует множество классификаций видов тестов, таких как: «по знанию системы», «по степени автоматизации», «по времени проведения тестирования». На этом этапе нас интересует только одна классификация: «по степени изолированности компонентов»:

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование (приемочное)

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

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

Так вот, есть только шкала. Чем более простую и мелкую часть системы мы тестируем — тем дешевле тесты, чем более сложную (составную) — тем дороже. И ваша задача как специалиста — исходить не из того, чтобы соответствовать своим представлениям о видах тестирования, а писать тесты так, чтобы они в идеале покрывали большее число кейсов при небольших затратах. Я уверен, что на этой фразе некоторые разработчики напряглись, потому что в их картине мира нужно обязательно писать изолированные юнит-тесты, а приемочные должны писать только тестировщики. Не буду разводить полемику, просто скажу, что бывает по-разному. Есть проекты, в которых процент юнит-тестов (в самом жестком понимании) составляет доли процента от всех остальных тестов (как в Хекслете, хе-хе), а есть те, где пишут только приемочные тесты (отдельные тестировщики).

Теперь вы готовы, и я попробую ответить на вопросы, поставленные в начале статьи. Предположим, что вы пишете программу (утилиту командной строки), которая принимает на вход файл и слово, которое нужно найти в этом файле. В результате своей работы программа печатает на экран все строчки из файла, в которых встречается это слово. Такая утилита действительно существует и называется grep . С ней знакомо большинство разработчиков.

Обычно в таких программах не всегда сразу понятно, какой будет архитектура. Многое зависит от того, что будет добавлено в процессе, например, форматы вывода, поддерживаемые форматы входа, обход директорий (рекурсивный), нечеткий поиск и многое другое.

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

Мы уже говорили о том, что архитектура проекта еще неизвестна, и, как правило, внутреннее разделение на файлы/модули/классы/функции, меняется с космической скоростью. В течение часа все может быть переписано несколько раз. Но теперь вместе с кодом нужно постоянно править тесты, что начинает раздражать. Программист начинает сомневаться в том, что они вообще ему нужны, и нередко просто перестает их писать. Другие продолжают мучаться и переписывать их, хотя чаще происходит другое. Написанные тесты начинают вас сковывать и мозг шлет команды «ты потратил время, оставь все как есть». Постепенно рефакторить становится все сложнее и ленивее. Это очень похоже на ситуацию, когда предприниматель инвестировал деньги в новое направление и, даже если бизнес уже тонет, ему тяжело отказаться, ведь было потрачено столько сил и средств (в экономике это называют sunk cost fallacy , — прим. ред.).

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

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

Более низкий уровень — это функция, которая принимает на вход путь до файла и подстроку для поиска, а на выходе (не печатает на экран!) отдает готовый результат, так, чтобы осталось только напечатать его. Такой вид тестов обладает самым лучшим балансом «убедиться в том, что все работает/стоимость». Они косвенно затрагивают все используемые внутренности, не зависят от реализации, очень просты в написании и крайне дешевы в поддержке. По мере стабилизации архитектуры можно добавлять тесты более низкого уровня (если становится понятно, что сложность системы слишком высока).

TDD

Описанная методика особенно хорошо работает в связке с подходом, когда тесты пишутся до кода (вместе с кодом).

Существует миф о том, что тесты нужны только для регресса, то есть для уверенности, что новый код не сломал старый. Это далеко не так. Более того, это следствие написания тестов как таковых. В некоторых ситуациях первостепенная цель написания тестов — это ускорение разработки. Да-да, вы не ослышались, написание тестов до кода/одновременно с кодом, приводит к серьезному ускорению разработки. Чаще всего такие ситуации связаны с тем, что на вход подаются сложные данные, которые как-то трансформируются и прокидываются дальше. Тестировать руками (во время разработки) такой код очень сложно, нужно подготавливать данные, нужно проверять, что результат соответствует ожидаемому.

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

Второе серьезное преимущество TDD заключается в том, что при проектировании кода мы начинаем думать не о том, как сейчас клево насоздаем файлов и разнесем по ним функции, создав десятки абстракций, и начнем думать о важных вещах. О том, как будет использоваться моя библиотека. Удивительно, но начать смотреть с такого угла (а этому учат всех стартаперов, customer development во все поля) непросто, все время хочется окунуться в прекрасный мир архитектуры.

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

Дополнительные ссылки

• Видео версия статьи
• Бережливое тестирование

Как начать писать тесты за 10 шагов по 10 минут

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

1. Выбираем фреймворк для тестов

Не вздумайте начинать писать собственный фреймворк с нуля — оно вам надо? Тратить неделю на выбор оптимального фреймворка (да, я видел такую оценку времени на это в планах) — тоже глупо. Вот вам рецепт: набирайте в Гугле best test framework for %language% site:stackoverflow.com. Открываете первые 5 ссылок. Закрываете те из них, где рейтинг вопроса или первого ответа около нуля. Из оставшихся вкладок можно смело брать любой рекомендованный фреймворк из первой тройки с максимальным рейтингом. С вероятностью в 99.5% он вам подойдет. Поскольку на данный шаг вы пока потратили минуты 3, то оставшиеся 7 можно потратить на то, чтобы перейти на сайт фреймворка и посмотреть примеры его использования. Скорее всего, там всё будет просто и понятно (иначе он не был бы в топе рекомендаций). Но если вдруг нет — выберите другой по тому же алгоритму.

2. Пишем Hello world!

Написать Hello, world! нам раз плюнуть. Вот, например, на С++.
Hello world!

#include using namespace std; int main()

А теперь сделаем две вещи.
Во-первых, вынесем генерацию выводимого текста в отдельные функции. Да, в две. Это для того, чтобы потом их можно было тестировать.

Hello world! после рефакторинга

#include #include using namespace std; string GetHello() < return "Hello"; >string GetAdressat(string adressat) < return adressat; >int main()

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

HelloFunctions.h

#include using namespace std; string GetHello(); string GetAdressat(string adressat); 

HelloFunctions.cpp

#include "HelloFunctions.h" string GetHello() < return "Hello"; >string GetAdressat(string adressat)

HelloWorld.cpp

#include #include "HelloFunctions.h" using namespace std; int main()

3. Подключаем фреймворк к Hello world!

О подключении фреймворка к проекту наверняка очень хорошо написано на сайте фреймворка. Или на stackoverflow. Или на Хабре. Вот я, к примеру, когда-то описывал подключение Google Test. Обычно всё сводится к созданию нового проекта консольного исполняемого приложения (в скриптовых языках — отдельного скрипта), подключению к нему фрейворка парой include (import\using), подключению к проекту тестируемого кода (включением самих файлов с кодом или подключением библиотеки) — ну и всё. Если вы не верите, что этот шаг можно сделать за 10 минут — откройте Youtube, напишите в поиск название своего фреймворка и пронаблюдайте 20 видеороликов примерно одинакового содержимого, которые это доказывают.

4. Разбираемся с возможностями фреймворка

• Как написать один юнит-тест
• Как запустить юнит-тесты

Вот, к примеру, пару тестов для нашего Hello world! на упомянутом выше Google Test:

#include "HelloFunctions.h" #include "gtest/gtest.h" class CHelloTest : public ::testing::Test < >; TEST_F(CHelloTest, CheckGetHello) < ASSERT_TRUE(GetHello() == "Hello"); >TEST_F(CHelloTest, GetAdressat) < ASSERT_TRUE(GetAdressat("world") == "world"); ASSERT_FALSE(GetAdressat("not world") == "world"); >int main(int argc, char **argv)

5. Подключаем фреймворк к настоящему проекту

Мы уже умеем подключать фреймворк к проекту. Помните, делали на шаге №3? Всё получилось. Теперь давайте сделаем это для боевого проекта. Положите все необходимые файлы фреймворка себе под SVN\Git\TFS\чего-у-вас-там. Сделайте тестовый проект. Подключите к нему фреймворк. Включите сборку тестового проект в процесс сборки вашего продукта. Проверьте сборку в дебаг и релиз-конфигурациях. Комитните тестовый проект, запустите сборку на билд-сервере. Всё должно быть ок. Не нагружайте пока ваших коллег появлением тестового проекта — во-первых, вы ничего не сломали, во-вторых, хвастаться вам тоже пока нечем.

6. Тестируем что-нибудь простое

Вы помните, каким образом мы выше вынесли из Hello world! часть функционала во внешний код? Обратите внимание, какими получились эти функции: они не зависят ни от глобальных переменных, ни от состояния каких-то объектов, ни от внешних данных из файлов или баз данных. Резальтат зависит только от переданных аргументов. Найдите в своём проекте что-то аналогичное. Наверняка ведь у вас есть какие-нибудь функции конвертации чего-то куда-то, сериализации\десериализации, упаковки\распаковки, шифрования\дешифрования и т.д. Не думайте пока о том, насколько нужный и полезный функционал вы тестируете. Ваша задача — написать простой тест, но для боевого проекта. Запустить, увидеть «1 тест успешно пройден».

Кстати, именно на этом этапе очень часто к скептикам приходит озарения. Вдруг оказывается, что самый простой тест, на самую элементарную функциональность — вдруг провалился. Лезем в код — и вдруг находим что-то типа

return 12; // TODO: implement later 

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

7. Тестируем что-нибудь посложнее

Вы уже умеете тестировать простые вещи. Теперь разберитесь как тестировать что-то, имеющее внешние зависимости. Посмотрите, как ваш фреймворк предлагает делать подготовку к запуску теста и очистку после него. Разберитесь, что такое моки и стабы. Подумайте как протестировать какой-нибудь ваш код, читающий данные из файла или из базы. Легко ли подменить источник входных данных? Может быть стоит слегка изменить код, чтобы это стало легче? Сделайте это, если нужно. Напишите для этого кода тест.

8. Пишем тест на баг

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

9. Первый раз TDD

Как обычно выглядит ваша работа при разработке нового функционала? Наверное, вы сначала думаете. Потом проектируете то, что будете делать — набрасываете названия интерфейсов, классов, потом названия методов, наполняете их реализацией, запускаете, отлаживаете. Отлично, менять почти ничего не надо. Просто в тот момент, когда у вас уже есть интерфейсы, классы и названия методов, но еще нет их реализации — напишите для них тесты. Простенькие — вызвали метод — проверили результат. Обратите внимание, как уже на этом этапе вы заметите нелогичность некоторых имён, недостаток или излишество аргументов в методах, ненужные или отсутствующие зависимости и т.д.. При этом сейчас пока что это исправить — почти ничего не стоит (ведь реализация ещё не написана). Подправили архитектуру, дописали тесты, запустили — увидели кучу проваленных тестов. Отлично, так и должно быть. Написали реализацию, запустили тесты — увидели большинство из них пройденными, исправили ошибки, добились успешного прохождения всех тестов — отлично, дело сделано. Вы чувствуете, как хорошо стало, какое моральное удовлетворение вы получили? Оно слегка напоминает удовольствие от получения какой-то ачивки в игре. А почему? А потому, что его можно измерить! «Код проходит 18 тестов при тестовом покрытии в 90%» — это звучит круче, намного круче чем «ну, фича вроде бы реализована, я так потыкал немножко, кажется, не падает». Это даёт право гордится. Идешь домой — и чётко понимаешь, что-то за день сделал полезное, это «что-то» измеримо, ощутимо, реально.

10. Прикручиваем запуск тестов к CI-серверу

В тестах мало смысла, если их не запускать. Запускать их вручную — долго и бессмысленно. Наверняка у вас есть билд-сервер с каким-нибудь TeamCity или CruiseControl, где собирается ваш продукт. Так вот, большинство хороших билд-серверов сразу, из коробки, поддерживают запуск тестов и даже парсят их логи и рисуют красивые отчёты. Соответствие тут, конечно, не «все совместимы со всеми», но если вы взяли тестовый фреймворк по совету в начале статьи — шансы на то, что всё заработает очень высоки. К примеру, упомянутые мною TeamCity и Google Test прекрасно дружат между собой.

Послесловие

1. У вас уже есть проект, к которому прикручены тесты. Они запускаются, работают, их больше нуля и они уже приносят вам пользу.
2. Вы получили опыт во всём этом деле.
3. Во второй раз у вас получится серьёзно быстрее.

Где-то пункта после 8-го — хорошее время чтобы представить тестовый проект вашей команде. Объясните в 2-3 абзаца что и как, покажите простенький пример теста, заметьте, что, мол, «feel free to add your own tests», но особо не напирайте пока. Если у вас писать тесты было не принято, скорее всего первым впечатлением будет осторожный скепсис и непонимание. Это быстро лечится после второго-третьего упоминания на совещании о том, что, мол «а этот баг мы нашли благодаря тесту» или «а вот тут написан тест и мы сразу узнаем, если оно сломается снова». Программисты — народ рациональный, они поймут и подтянутся.

• Блог компании Инфопульс Украина
• Тестирование IT-систем
• TDD

Home

Многие организации планируют тестирование, не осознавая всей ценности такого планирования. Тестировщики зачастую создают тест-планы просто потому, что всегда это делали (или процессы гласят им, что так надо). Если тест-план грамотно составлен – это мощное оружие в вашем тест-арсенале.

Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:

• В какой форме тест-план должен быть?
• Какую информацию он должен включать?
• Для кого он предназначен?

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

Нужен ли вам тест-план?

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

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

Я не собираюсь указывать вам, писать вам тест-план или не писать. Только вы можете определить, требуется ли вам этот документ в вашем конкретном контексте. Я лишь хочу, чтобы вы честно спросили себя, нужен ли вам этот тест-план?

Если вам кажется, что план вам нужен, то ниже – ряд вопросов, которые стоит задать, и несколько неплохих возможных ответов на них:

Вопрос: Кто запрашивает этот документ?

Ответ: заказчик, мы обязаны предоставить его по контракту.

Вопрос: Кто будет читать этот документ?

Ответ: Менеджер проекта, которому нужно убедиться, что я собираюсь протестировать продукт как минимум на удовлетворительном уровне.

Вопрос: Что читатель получит от этого документа?

Ответ: Вместе с прочей информацией – достаточную уверенность для релиза.

Вопрос: Что может улучшиться, если я прекращу писать тест-план?

Ответ: У меня будет больше времени для действительно ценной для проекта работы, потому что я не трачу время на то, что никто не будет читать.

Вопрос: Что может ухудшиться, если я прекращу писать тест-план?

Ответ: В проекте никто не будет иметь ни малейшего понятия, что именно я тестирую.

Вопрос: Кто заметит, если я прекращу писать тест-план?

Ответ: Владелец процесса , так как создание тест-плана – это часть нашего контролируемого процесса.

Использование тест-плана как можно раньше в жизненном цикле проекта для поиска ответов на эти вопросы – это разновидность тестирования. Вы можете, например, спросить, есть ли критерии производительности, которые можно оценить и использовать для тестирования? Будет ли продукт выходить в интернет? Какие сценарии восстановления/избегания проблем должен поддерживать продукт? Задавая эти вопросы, вы подводите заинтересованных лиц к размышлениям о производительности, безопасности и устойчивости, и они займутся этим раньше, чем могли бы, не спроси вы их об этом.

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

Глаголы, а не существительные

«Планы бесполезны, но планирование бесценно» – Дуайт Эйзенхауэр.

Тест-планы статичны по своей природе, а планирование тестирования – динамический, дискурсный процесс обучения и переговоров. Документ, который никто не читает, бессмысленен. Создание того, что не принесет пользы проекту или его заинтересованным лицам, стоит денег и времени. План начнет приносить ценность только тогда, когда вы будете его использовать. Тест-план, который никто не читает, и который не информирует никого о тестировании – это трата вашего ценного времени, которое уместнее потратить на что-то более полезное.

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

Заинтересованные лица – кто они?

Документы создаются для коммуникаций между людьми. Вам нужно понимать, кто эти люди в контексте связанной с тестированием информации. Кто ваши заинтересованные лица?

Если вы не уверены в ответе, определитесь, на какие вопросы о тестировании вам нужно получить ответ, а затем выясните, кто может ответить на них наилучшим образом, и спросите их об этом. Они должны быть задействованы в тестировании продукта или приложения. Объясните, почему вы задаете эти вопросы, и расскажите им, как их ответы улучшат ваше тестирование.

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

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

Менеджеры проекта хотят знать, что вы собираетесь тестировать, дабы быть уверенными в решении о выходе в релиз.

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

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

Продажники сообщат, какие продукты наиболее популярны, и как именно они применяются.

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

Как написать хороший тест-план: форма, структура и содержание

Тест-планы могут принимать какую угодно форму, например:

• Word-документы – зачастую формат по умолчанию, так как Word доминирует на рынке, и люди хорошо с ним знакомы. Тест-планы варьируют от одностраничного документа, кратко описывающего основные области тестирования, до длинного, соответствующего IEEE829 / IEEE29119 стандартам мануала, подробно расписывающего каждую деталь.
• Ментальные карты – отличный способ изложить тест-информацию в структурированной графичной форме. Читателю легко отслеживать структуру плана и просмотреть его на необходимом уровне детализации. Погуглите «mindmap test plans», чтобы посмотреть на примеры.
• SharePoint /Wiki – отличные альтернативы Word, и обладают мощным инструментарием управления версиями и редактирования. Они позволяют гибко структурировать информацию, а также быстро обновлять и совместно редактировать ее.
• Web-инструменты планирования (например, Jira) можно использовать не только для планирования задач разработки. Интеграция с системами управления тестами (например, TestRail) даст команде полную картину запланированного и реального тестирования.
• Whiteboard / доскиKanban – еще один неплохой способ графически показать масштабы тестирования. Физические доски – очень прозрачный способ донести, что и как вы собираетесь тестировать.

Хороший способ начать тест-план – это одностраничный план. Он поможет вам создать краткий и информативный документ.

С точки зрения содержания тест-планы обычно создаются, чтобы зафиксировать базовые ответы на «пять почему и как» тестирования. Содержание ваших планов может меняться по ряду причин (к примеру, от релиза к релизу или от спринта к спринту). Обновляйте ваш тест-план на основании полученной от релиза к релизу (или от продукта к продукту) информации.

Используйте ваши планы эффективно, чтобы улучшить процесс тестирования. Пусть он станет репозиторием для знаний организации. Сделали ошибку в релизе? Определите, как выловить ее в следующий раз, и добавьте в шаблон плана. Обычно забываете про какой-то тип тестирования? Отметьте, что это необходимо покрыть. Добавьте заметки о бедах и горестях пользователя, а также о том, что может дать вам полезную для тестирования информацию. Тест-план может стать основой для непрерывного совершенствования планирования и стратегии тестирования.

Со временем обновляйте шаблон, чтобы поддерживать и улучшать свое планирование. Пусть тетс-план работает на вас и формой, и структурой, и содержанием. Если он не работает – меняйте его.

Как оценивать тест-план

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

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

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

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

«Ни один план не выдерживает встречи с противником» – Хельмут фон Мольтке Старший.

«Только изменчивость постоянна» – Гераклит.

Как обновлять тест-план

Все меняется, и ваш план должен быть открыт переменам. Подход к планированию тестирования должен позволять справляться с изменениями, разъяснять, что вы будете делать иначе, какая информация вам необходима, и какую новую информацию (и кому) вы должны предоставить.

Договоритесь о подходящей частоте пересмотра тест-плана, или же используйте для этого любой достаточно весомый повод. Пересмотры не должны быть глобальными – пусть они соответствуют масштабу перемен. Это необязательно личные встречи: попросите людей просмотреть изменения и отправить вам комментарии по почте. Пусть всем будет легко помогать вам в поддержании плана в актуальном и рабочем состоянии.

Тест-планы работают на вас

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

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

Эта информация также полезна во время ретроспектив и пост-мортемов, позволяя лучше принимать решения и обсуждать, как можно улучшить тестирование.

Полезный тест-план

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

Об авторе

Ричард Патерсон руководит тестированием и безопасностью приложений в SAS R&D (Шотландия). Он считает себя не только тестировщиком, но и дизайнером, лидером и создателем.

Что такое тест кейс: пример и чек-лист тест кейсов для начинающих тестировщиков, которые подойдут каждому

Вы хотите узнать, по какой форме писать тест кейсы и увидеть пример правильного тест кейса? Мы собрали чек-лист из примеров и формы, как написать грамотный тест кейс по шаблону.

В этом материале о тест кейсах вы узнаете:

1. Что такое тест кейс
2. Из чего состоит тест кейс и какая у тест кейсов форма
3. Правила написания хорошего тест кейса
4. Типичные ошибки в тест кейсах

Что такое тест кейс

Тест кейс — это проверка работоспособности программы или проекта.
Написать тест кейс — значит создать текстовое описание процесса тестирования какой-то части или функции проекта.

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

1. Порядковый номер тест кейса
2. Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
3. Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
   Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды
4. Порядок действий в тест кейсе и описания действий в тест кейсе
5. Ожидаемый результат тест кейса.

Вот пример тест кейса:

Тест кейс №1
Название тест кейса: Уведомление пользователя о снижении заряда аккумулятора вручную
Предусловия тест кейса: статус самоката: в аренде
Шаги тест кейса:

1. Шаг тест кейс №1: Зайти на сайт samokat.admin Логин — test, пароль — test
2. Шаг тест кейса №2: Перейти на вкладку «Самокаты в аренде»
3. Шаг тест кейса №3: Нажать…
4. Шаг тест кейса №4: Включить…
5. Шаг тест кейса №5: …
6. Ожидаемый результат тест кейса Появляется сообщение об успешном выполнении тест кейса «Пользователь уведомлен о снижении заряда»

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

1. Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
2. Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
3. Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.

Существуют 6 правил проведения тест кейсов:

1. Один тест кейс должен проверять только одну конкретную вещь.
2. Тест кейс не должен зависеть от других тест кейсов.
3. Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
4. В тест кейсе должна быть вся информация. необходимая для его проведения.
5. В тест кейсе не должно быть лишних деталей.
6. Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.

Типичные ошибки при написании тест кейсов

Абстрактное название тест кейса
Тест кейсы на одном проекте часто похожи друг на друга. Чтобы в них не было путаницы, названия должны быть конкретными и однозначными.

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

Плохо: yandex.ru
Хорошо: yandex.ru

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!