Проект одного тестировщика часть 3

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

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

2. Написание тест кейсов по первым пунктам тест плана. Вернее сначала был написан сам тест план. Это было сделано следующим образом. Документация на тот момент уже имелась, работоспособное приложение- тоже. Поэтому решено было для начала выделить области приложения, которые будут содержать тесты одной функциональной группы. То есть сгруппировал юз кейсы (именно юз кейсы) по функциональным признакам. Юз кейсы писал используя спек и приложение. Таким образом получилось дерево юз кейсов. Примерный вид:
1. Общие тесты приложения
1.1 Логин:
1.1.1 Корректный;
1.1.2 Некорректный;
Далее производилось необходимое уточнение, более мелкая разбивка. А потом на каждый юз кейс осталось написать необходимое количество тест кейсов. Что и было сделано. Тут же следует отметить, что когда было готово дерево юз кесов (ну почти готово, так как изменения все равно впоследствии вносились), решено было задать номера юз кейсов, как на примере. Таким образом выстроилась система нумерации тест кейсов, что позволило избежать путаницы в будущем и оптимально разбить группы по номерам. Причем это было сделано так, что просто по номеру сразу можно было определить принадлежность конкретного тест кейса к той или иной группе, и при невыполнении его сразу прикинуть какой функционал неработоспособен. Во время написания тест кейсов возник стандартный вопрос- где их лучше всего хранить. Причем сразу заинтересовала возможность хранить где-нибудь рядом и результаты их выполнения. Но так как ТестКомплит предоставляет
отличный лог выполнения, который можно и экспортировать и отсылать на мыло автоматически, решено было хранить результаты все же отдельно от тест кейсов. (Обращу внимание, что ручного тестирования в больших количествах не предполагалось). Также хотелось сделать хранение в свободном доступе, с возможностью редактирования, журналирования. В результате остановился на той же вики. Были проблемы при размещении там таблиц, но они быстро решились установкой необходимых плагинов. А тест кейс у меня представляет собой таблицу с набором необходимых полей и их значений:
Имя: Название тест кейса
ID: С1312000
Приоритет: 1
Цель: верификация меню.
Источник: спек, требования...
Категория: Functional
Предустановки: Приложение запущено.
Type: Manual
Version 0.01
Исполнительная часть:
Action Expected Result

3. В итоге на некоторый момент имелся набор тест кейсов. Не забываем, что чем раньше будет введено в эксплуатацию автоматическое тестирование, тем лучше (это в моем конкретном случае). Поэтому решил выделить некоторую группу тест кейсов и написать по ним скрипты автотестов. О порядке формирования такой группы напишу отдельно, скажу сразу, что нужно было определиться с функционалом, который необходимо тестировать именно в первую очередь. Какие-то вещи могут и подождать. По мере написания скриптов вырабатывались некие правила, стандарты, о которых тоже напишу отдельно. Это включало в себя "стандартизацию" скриптовых элементов и вынесение этих элементов в отдельное хранилище для облегчения и укорения последующей модификации и ускорения написания новых скриптов. Это хранилище потом планировалось оформить в библиотеку длл. Затем была отладка скриптов, тестирование, анализ результатов, подготовка к автоматическому запуску.
Так же при написании необходимо было учесть, что прогоняться автотесты планировалось на нескольких ОС, что накладывало свой отпечаток. Отмечу, что разные Windows имеют разные особенности в таких моментах, как пути до вроде бы стандартных папок и каталогов, и самое главное- различные пути до объектов на форме приложения. Поэтому приходится придумывать решения, которые позволяют обойти такие моменты.
Еще один немаловажный фактор- я заранее знал, что интерфейсы наших приложений будут переделаны. Не уточнялось только- когда это будет. Тем не менее тестировать существующую реализацию тоже необходимо. Соответственно решено было писать скрипты так, чтобы при переделках интерфейса минимизировать апдейт скриптов ибо время-деньги, лень и т.д. Какое-то время раздумывал над возможностью такой реализации. Потом
принял рещение использовать Model Based Testing - тестирования, основанного на описаниях состояний системы и их изменениях (абстрагируемся от GUI). Это позволило мне иметь в каждый конкретный момент времени большинство работающих скриптов и минимизировать время на отладку остальных из-за изменений приложения.
В общем итоге - такой набор позволил мониторить состояние основных функций софта в каждый конкретный момент времени, что позволило постепенно переключаться на другие пункты тест плана, и другие задачи.