Давным-давно…
Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.
Аргументом для прекращения написания тестовой документации и каких-либо спецификаций стало то, что на выходе убытков было больше, чем прибыли. Спецификация и различная документация себя не оправдывали, потому что требовать высокие цены за небольшие мобильные приложения компания не могла. Да и какие могут быть чек-листы на новую функциональность, когда:
— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.
В итоге приходилось без документации думать о том, что именно и на какие части могло повлиять. В срочном порядке нужно было проводить полноценное исследовательское тестирование за полчаса! При этом, нужно было найти критические для пользователей баги. Полчаса — это максимум времени, потому что выявленные проблемы еще нужно исправлять и перепроверять. Со временем при такой организации работы начинали возникать проблемы:
— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе?.. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.
И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…
Как, что и по каким законам там происходило – не было понятно никому. Особенно новым разработчикам, которым передавали дальнейшую разработку:
Коллеги, я потратил три дня на изучение кода, потому что разработчиков этой программы уже нет, и ничего не понятно. Комментариев в коде мало. Непонятно, для чего какой костыль. Если я начну писать, то сломаю то, что работает. Мне легче это всё переписать заново. Давайте напишем нормально.
Так работают множество компаний. И далеко не все получают хорошие результаты.
Хоть выше описан и неточный рассказ, так как прошло уже много лет и что-то перефразировано, но смысл тот же. Есть компании, которые всё-таки пишут тестовую документацию и активно ею пользуются. Обычно это крупные компании, разрабатывающие многофункциональные масштабные системы. А есть компании, от качества и наличия документации которых могут зависеть жизни людей (например, компания разрабатывает автопилот для самолета). Автопилот можно разрабатывать годами, в итоге один раз выпустив его в свет. Это очень дорогой процесс. Если автопилот будет с багами, то потери будут колоссальными.
Как же сделать так, чтобы продукт получился качественным и хорошо продаваемым? Необходимо начать с документации.
В каком виде и для чего нужна тестовая документация?
Существуют различные виды документации, используемой при тестировании. Каждая из них играет роль в достижении общей цели — создании успешного продукта. Ниже рассмотрим самые распространенные виды документации и причины их использования.
Рабочая проектная документация, используемая тестировщиками
ТЗ (техническое задание) – позволяет донести суть предмета разработки до сотрудников компании. Помогает понять, какой именно функциональностью должен обладать разрабатываемый продукт (иногда с указанием используемых технологий и методов).
Почему необходимо?
- Если ТЗ будет в общем доступе, то сотрудники, плохо пересекающиеся с командой разработки, смогут его посмотреть. Возможно, что при тестировании будет обнаружена какая-то проблема, о которой сообщит тестировщик (например, программа не выполняет то, для чего была создана).
- Новым сотрудникам не нужно будет рассказывать о смысле программы и методах ее реализации. Можно будет быстро ввести в курс дела любого человека.
- ТЗ помогает сотрудникам понять программу лучше. Непонимание разрабатываемого продукта приводит к ошибкам.
- При тестировании не будет возникать попыток проверять лишнее. В первую очередь, проверке подвергнется то, что обязательно должно работать по ТЗ.
- ТЗ дает возможность понять суть разрабатываемого продукта сотрудникам, которые будут представлять готовый вариант реализации публичной аудитории.
ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).
Почему необходимо?
- Помогает разработчикам реализовать разрабатываемый продукт точно так, как задумывалось. Помогает понять логику и правила оформления.
- Помогает новым сотрудникам разобраться в крупных и масштабных проектах, так как на некоторые системы нужны недели изучения. Имея под рукой ЧТЗ, сотрудник с легкостью сможет найти в нем необходимую информацию, сразу приступив к тестированию. Не нужно будет привлекать других сотрудников, знающих продукт, тем самым отвлекая их от работы. Очевидная экономия времени!
- Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.
- Помогает тестировщикам создать ЧЛ и тест-кейсы до начала работ и тестирования.
ЧТЗ и ТЗ можно отобразить:
- в текстовом виде с картинками
- в виде графического шаблона-таблицы
- в виде интеллект-карт, UML или подобного алгоритма
Проектная документация, подготавливаемая тестировщиками
ЧЛ (чек-лист) – список того, что нужно проверить.
Почему необходимо?
- Помогает планировать сроки окончания работ в будущем и настоящем, т.к. в ЧЛ можно указать, сколько времени необходимо для проверки и сколько было затрачено.
- Хранит историю пройденных тестов. Можно будет легко вспомнить, какие именно тесты проходили с ошибками, и перепроверить именно их.
- ЧЛ с результатами наглядно показывает любому сотруднику компании текущее состояние разрабатываемого продукта. Помогает определить его степень готовности.
- Помогает помнить, что уже было проверено, а что нет.
- Помогает не забыть, какие тесты необходимо выполнить в первую очередь, какие во вторую, какие в третью и т. д. Это рождает уверенность, что за определенное запланированное время самые важные тесты будут проведены, а результаты по ним — получены.
Чек-листы можно записать:
- в виде таблиц (удобно в Google Sheets)
- в виде интеллект-карт (удобно в XMind)
- в виде списка проверок в специально предназначенной системе (удобно в Sitechco)
- в виде списка в текстовом документе, который привычен.
ТК (тест-кейс) – создается на основе ЧТЗ (если оно есть) тест-аналитиками и тестировщиками.
Почему необходимо?
- Совместно с ЧЛ может хранить историю тестирования и отображать, что именно и как тестировалось. Можно убедиться, что та или иная функциональность обязательно была или будет проверена и затронута при тестировании.
- Помогает быстро включить в работу новых сотрудников. Сотруднику не обязательно неделями изучать предмет разработки, ему будет достаточно открыть сохраненный ТК и пройти его по шагам так же, как проходил другой опытный специалист, ранее работавший в компании.
- Помогает увидеть как предмет разработки (программа, сайт и т. п.) должен выглядеть. С имеющимися скриншотами экранов, если они есть, можно будет не забыть о том, что “вон та” кнопка должна быть серой, а не красной.
Тест-кейсы можно отобразить:
- в виде таблицы с текстовыми данными
- в специальном сервисе для ведения тест-кейсов (например, в TestLink).
Отчет о тестировании – письменный или медийный отчёт о проделанной работе и ее результате.
Почему необходимо?
- Наглядно отображает, какой именно результат выполненных работ получен.
- Исторически фиксирует информацию. К ней всегда можно будет вернуться и увидеть, что именно было выполнено и что именно получили в итоге.
- Уведомляет о результатах всех, кому важно о них знать. Например, для сотрудников отдела поддержки сообщается о выходе новой версии разрабатываемой программы, а также о самых критических проблемах. Можно будет заранее подготовиться к возникающим жалобам.
- Помогает принимать решение о дальнейших действиях (например, стоит ли выпускать версию программы в текущем состоянии).
Пример отчета в письменном виде:
Как определить, какую именно документацию необходимо внедрить в проект?
Ниже приведем примеры того, когда и какую документацию и средства можно использовать как необходимый минимум.
На проекте до 15 человек (проекты низкой сложности):
- техническое задание (предотвращает неверное понимание задачи разработчиками, т. к. документации нет);
- чек-листы (легко поддерживать, не отнимают много времени);
- отчеты в виде краткого письма или отписки в специальном сервисе ведения проектов, с указанием критических багов для выпуска.
На проекте от 15 до 50 человек (проекты средней сложности):
- техническое задание;
- чек-листы;
- тест-кейсы;
- база знаний (например, в Wiki);
- отчеты в виде письма с приложенным пройденным ЧЛ с указанием критических багов.
Большой проект – от 50 человек и больше (проекты высокой сложности):
- техническое задание;
- частное техническое задание;
- чек-листы;
- тест-кейсы;
- база знаний (например, в Wiki);
- медиа-материалы;
- отчеты в принятом в компании виде (обычно, в виде письма с подробными графиками и приложенными файлами);
- прочее (зависит от типа, целей и нужд компании).
Что из этого выбрать — решать самим сотрудникам, т. к. именно они будут заниматься разработкой и смогут понять, что им нужнее. Все вышеперечисленное — лишь примерное представление и рекомендации.
Что делать, если написание документации занимает много времени?
Опыт показывает, что при работе над небольшим проектом нужно уметь приспосабливаться. Можно видоизменить документацию так, чтобы ее ведение было удобным и не занимало много времени. Например, ТЗ можно сделать в виде презентации или вебинара и получить от разработчиков уточняющие вопросы. Каждый из видов документации обладает своими плюсами и минусами, поэтому нужно экспериментировать и не бояться создавать что-то новое. Все научные открытия совершаются методом проб и ошибок, при этом случаются и неудачи!
Но отрицательный результат – это тоже результат! Нужно уметь им воспользоваться и учесть его в своих дальнейших экспериментах, пока не будет достигнут приемлемый итог. Великолепных вам решений и успехов в написании документаций!
