Вы - новая команда тестирования на старом проекте.

Заказчик меняет команду тестирования на Вашу. Процесс поставлен и разогнан. Что делать в первую очередь?

Перед новой командой тестирования стоят задачи:

- «меркантильные»: сделать как минимум не хуже, чем было, то есть показать, что заказчик не зря сменил аутсорсера;

- «общечеловеческие»: выпускать качественный продукт.

Для их выполнения команде нужно будет улучшить процесс (или, как минимум, не испортить :) и в дальнейшем по нему работать.

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

Тут 2 варианта:

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

2) В условиях недостатка времени – просто включаться в работу по налаженному процессу и тогда улучшения вносить «по ходу», если остается время.

Рассматриваем первый вариант – у команды есть время на «вход».

Первым делом - анализ требований: есть ли, в каком виде, тестируемы ли? Тут можно говорить долго и много  ( В моем последнем жизненном примере проекта нет требований, есть только юзер мануал, который пришлось переводить из вида «If you want to print the document that you have received from your agent, please select File>Print» в «To print document user should be able to select File>Print». А также пришлось уточнять моменты типа «There is no limit how many files user can add to the collection.» Беспредел – это, конечно, хорошо, но проверить какую-то разумную цифру все же надо :)
В ходе работы выработалось несколько формальных правил, напишу о них отдельно.)

Затем - анализ покрытия требований тестами. Преследуем 2 цели: получить картину «как это есть сейчас», и составить план действий « что сделать, чтоб было так, как должно быть».

В ходе анализа покрытия:

- составляем матрицы прослеживаемости;

- анализируем матрицы: почему некоторые единичные требования покрыты десятками тестов, в то время как целые блоки других вообще не имеют соотвествующих тестов? Э то следствие расстановки приоритетов или уверенности в себе предыдущей команды?

- попутно анализируем тесты на предмет избыточности.

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

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

Так что, продолжение следует...