3. Краткая теория, методы и документация.

Ну и, конечно, нужно ознакомиться с теорией. Не полениться выделить неделю на чтение книг и интернет-форумов, посвященных тестированию, хотя после них остается ощущение полной пустоты в голове и чувство собственной неполноценности, пока не придешь к мысли, что теорию следует применять, руководствуясь здравым смыслом. У вас никогда не получится внедрить полноценный RUP (Rational Unified Process – платформа IBM, представляющая обширный набор методов для обеспечения качества ПО на всех этапах его разработки – прим. ред.) в организации из пяти программистов и трех тестеров. Поэтому не стоит и пытаться полностью приспособить к себе теорию, которую использует гигант с многотысячным персоналом и миллиардным бюджетом. Нужно выбрать оттуда только полезное для вас, отбрасывая или упрощая то, что, по вашему мнению и здравому смыслу, будет только отнимать время. В принципе, из всего моря документов можно для начала оставить только четыре, и те упростить до уровня понимания в вашей организации:

• план тестирования (test plan) – документ, содержащий краткую информацию о самой системе, силах и средствах, которыми предполагается ее тестировать, о том, что именно вы собираетесь подвергнуть проверке (вплоть до списков или даже описаний тестов), примерные планы по срокам, критерии окончания работы и признания релиза успешным, риски и прочие сведения, могущие оказать влияние на процесс тестирования. В литературе и в Интернете есть масса заготовок тест-планов, из которых можно составить для себя нужный шаблон. Существует два подхода к написанию тест-плана – статический и динамический: статический – когда он пишется один раз при разработке стратегии тестирования и содержит только неизменяемые сведения, и динамический – когда в нем имеются еще и описания тестов, корректируемых и дополняемых по ходу разработки ПО. (Я пользуюсь первым подходом);

• контрольный пример (test case) – документ с описанием конкретного теста. Его детализация не должна быть чрезмерной – в конце концов, в предполагаемых в статье условиях работы у вас не будет на это ни сил, ни времени. Основное требование к контрольному примеру – описание проверки четко определенной самостоятельной части функциональности (или свойств) программного обеспечения и ожидаемых результатов;

• таблицу контроля (check-list, он же suite, или набор) – собственно, в предыдущем пункте я о ней написал. Это документ, объединяющий в себе (через гиперссылки) набор контрольных примеров с отметками о результате их исполнения и примечаниями;

• отчет о тестировании (test results) – результирующий документ, содержащий ссылки на таблицы контроля и выводы о работоспособности релиза с подписями тестера и руководителя проекта.

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

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

• файл с тест-планом;

• файл с шаблоном отчета о тестировании;

• каталог TestCase с набором контрольных примеров по конкретному проекту;

• каталог Builds, в котором в отдельных папках хранятся отработанные контрольные примеры по данной сборке (практически, копия папки TestCase, документы из которой используются в качестве шаблонов) и отчет о тестировании.

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