Тестирование ПО: с чего начать

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

Желание написать эту статью возникло достаточно давно как результат чтения начальником только что созданного отдела качества массы литературы по тестированию программных продуктов и общения в интернет-форумах инженеров качества. Главная проблема всех этих источников информации – чрезмерное наукообразие в изложении довольно элементарных вещей и полное нежелание переходить от общих рассуждений к конкретным примерам, из которых новичку можно что-либо понять. Что же касается платного обучения, программы большинства курсов (по крайней мере, в нашей стране) предполагают, что слушатель работает в уже подготовленной организации с налаженным процессом разработки, и ему нужно только дать необходимые знания и навыки, чтобы он мог в этот процесс как можно безболезненнее влиться.

А что делать тому, у кого есть только огромное желание повысить эффективность своей работы, сократить непродуктивные затраты времени и средств, правильно организовать труд подчиненных и свой, и при этом нет никакого понятия, с чего начать и за что взяться? Как раз об этом я хочу рассказать в данной статье на примере некой небольшой организации, который многим может быть очень близок. Я не считаю предлагаемые решения идеальными, но они были достаточно хороши для моих условий, так как сделали процесс тестирования более эффективным. Основная цель – подсказать тестировщику, с чего начать, подтолкнуть его в нужном, по моему мнению, направлении.

От редакции

В свое время в CCCP существовали организации, профессионально занимающиеся разработкой программных продуктов. По понятным причинам эти продукты не предназначались для широкой публики. Заказчиками обычно выступали министерства или какая-нибудь отрасль индустрии, скажем, металлургическая, химическая, атомная или авиационно-космическая. Разработка программ регламентировалась целой группой ГОСТов, в которых детально расписывались последовательность этапов и стадий и результаты их завершения. Никто не выделил бы и копейки разработчикам, которые представили бы плохо проработанное ТЗ («политическое» – термин из статьи). ГОСТ предусматривал также документ под называнием «Программа и методика испытаний», в соответствии с которым продукт сдавался заказчику. И никому даже в голову не приходило, что программу можно не тестировать. Более того, создавались программные и внутрисхемные эмуляторы, строились испытательные аппаратно-программные полигоны, если реальный объект не был доступен по тем или иным причинам. Правда, многих из существующих инструментов поддержки тестирования тогда еще не было.

Однако с распадом Союза эта технология оказалась невостребованной и исчезла. В то же время начали создаваться небольшие фирмы, в которые набирали только молодых людей, владеющих современными методами и инструментами программирования, но не имеющих представления о том, как управлять крупным и серьезным проектом. Научить же их было некому. И вот повторяется путь, уже однажды пройденный. Этот путь у каждой небольшой компании свой, и данная статья рассказывает об одном из них. Он может быть принят или отвергнут, но это некий слепок с реального положения дел, что и явилось побудительной причиной публикации материала. Мы попытались максимально сохранить стиль изложения и видение проблемы тестирования автором, при этом лишь напомнив читателям, что «мнения, высказываемые автором, не всегда совпадают с точкой зрения редакции».

Мотивы появления тестера

Итак, типичные условия, в которые сегодня попадает новичок: маленькая организация, берущая заказы по разработке какого-либо ПО и состоящая из директора и нескольких программистов, при этом каждый из них выполняет все возможные задачи – от общения с заказчиком до программирования, отладки, внедрения и технической поддержки. Из документации – только «политическое» ТЗ, чтобы формально удовлетворить требования заказчика, и договор.

Если проект более-менее длителен, то проблемы исправления ошибок, учета замечаний пользователей и инженеров технической поддержки постепенно приобретают такой размах, что программисты чаще всего сами, «снизу», инициируют увеличение штата на «девочку, нажимающую кнопки». Так в организации появляется тестер, который может пойти двумя путями.

Первый из них – действительно «нажимать кнопки». Естественно, при работе таким способом «ошибки» у тестировщика быстро заканчиваются, а у пользователей – остаются, что приводит к обвинению его в непрофессионализме. Поэтому второй путь – организовать работу более эффективно.

На этом этапе главное – понять основные цели тестирования. Их определений в литературе множество, но мне больше всего импонирует следующее: «основная цель тестирования – убедиться, что система делает то, что нужно, и не делает того, что не нужно». Первоочередная задача тестера – разработать как можно более полную систему тестов и при этом сделать все, чтобы на следующий раз не забыть, что же он делал, что нашел и как исправление этого найденного проверить.

Когда ничего еще нет...

Для начала важно осмыслить и формализовать уже существующий процесс разработки. Вы можете считать, что его нет, но объективно он есть, просто недостаточно хорош. Далее следует собрать и изучить все должностные инструкции (если их нет – разработать), стандарты предприятия и прочую документацию. В идеале наша цель – заставить общаться свой отдел с остальным миром только посредством документов.

Отсюда – первые выводы:

круг своих обязанностей в организации необходимо конкретизировать (чаще всего, кстати, это означает «сузить») и закрепить;
нужны документированные требования к системе, ведь чем детальнее проработан их список, тем легче производить тестирование;
найденные дефекты обязательно как-то регистрировать, причем так, чтобы потом можно было отследить их жизненный цикл;
результаты тестирования должны храниться в форме, удобной для поиска и анализа;
ни в коем случае нельзя начинать сразу с автоматизации тестирования: она подходит при уже существующем и налаженном процессе, а на первом этапе не даст ничего, кроме материальных и временных потерь.

Как у них и что делать нам ...

Из всего моря типов документов, предлагаемых, например, в RUP, можно для начала оставить только четыре

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

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

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

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

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

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

Списки требований и регистрация ошибок

С требованиями, к сожалению, сложнее всего – программисты не любят заниматься рутиной, особенно если это связано со значительным интеллектуальным напряжением. Однако они нужны для того, чтобы знать, что тестировать. Поэтому если их нет, тестер должен составить список сам, хотя бы в виде Excel-таблички. Для этого приходится общаться и с руководством, и с программистами, и с заказчиком, и с собственным здравым смыслом (при этом, опять-таки, сверяясь с заказчиком), но, в конечном итоге, это очень полезная работа.

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

И вот на этом этапе наступает черед для внедрения BTS (Bug Tracking System – системы регистрации и отслеживания жизненного цикла дефектов). Для начала это может быть даже Excel-файл с настроенными автофильтрами, но в идеале желательно сразу определиться с ПО, которое будет применено для автоматизированного тестирования, отслеживания ошибок, управления требованиями, документирования и пр. Есть достаточное количество производителей, которые предлагают целые специализированные комплексы. Поэтому зная, в какой области IT работает организация, с какими СУБД и в каких средах разработки, можно подобрать соответствующий продукт. Например, если предполагается использовать Rational, то в качестве системы регистрации и отслеживания ошибок лучше установить Rational Clear Quest. Причем на первом этапе в качестве рабочей БД лучше выбирать Access в связи с легкостью преобразования данных из нее во что угодно при последующей смене управляющего ПО.

BTS сначала встречает неприятие у программистов, но уже практически через неделю они не могут без нее работать. Одним из достоинств подобных систем является формализация общения между отделами и исключение недоразумений в вопросах ответственности, а для менеджеров – возможность объективно оценивать уровень квалификации и вклад в общее дело своих сотрудников.

Три условия успешного старта

Таким образом, для первичной организации тестирования необходимо, образно выражаясь, выполнить условия трех «Ф», которые заключаются в следующем:

формализации обязанностей – написании должностных инструкций и положения про отдел;
формализации общения с программистами – внедрении BTS;
формализации работы тестеров – создании контрольных примеров, планировании и получении отчета о тестировании.

Собственно, хороший производственный процесс тем отличается от плохого, что он не пущен на самотек, а упорядочен и управляем.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365