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