С развитием IT-рынка даже небольшие софтверные организации постепенно ощущают необходимость перехода от стихийного написания кода к более-менее формализованному процессу разработки. В первую очередь это делается для получения предсказуемых сроков сдачи проектов, однако нередко на передний план выходит и качество конечного продукта как веский фактор в конкурентной борьбе. Но высокое качество невозможно обеспечить без должного тестирования.
Желание написать эту статью возникло достаточно давно как результат чтения начальником только что созданного отдела качества массы литературы по тестированию программных продуктов и общения в интернет-форумах инженеров качества. Главная проблема всех этих источников информации – чрезмерное наукообразие в изложении довольно элементарных вещей и полное нежелание переходить от общих рассуждений к конкретным примерам, из которых новичку можно что-либо понять. Что же касается платного обучения, программы большинства курсов (по крайней мере, в нашей стране) предполагают, что слушатель работает в уже подготовленной организации с налаженным процессом разработки, и ему нужно только дать необходимые знания и навыки, чтобы он мог в этот процесс как можно безболезненнее влиться.
А что делать тому, у кого есть только огромное желание повысить эффективность своей работы, сократить непродуктивные затраты времени и средств, правильно организовать труд подчиненных и свой, и при этом нет никакого понятия, с чего начать и за что взяться? Как раз об этом я хочу рассказать в данной статье на примере некой небольшой организации, который многим может быть очень близок. Я не считаю предлагаемые решения идеальными, но они были достаточно хороши для моих условий, так как сделали процесс тестирования более эффективным. Основная цель – подсказать тестировщику, с чего начать, подтолкнуть его в нужном, по моему мнению, направлении.
В свое время в CCCP существовали организации, профессионально занимающиеся разработкой программных продуктов. По понятным причинам эти продукты не предназначались для широкой публики. Заказчиками обычно выступали министерства или какая-нибудь отрасль индустрии, скажем, металлургическая, химическая, атомная или авиационно-космическая. Разработка программ регламентировалась целой группой ГОСТов, в которых детально расписывались последовательность этапов и стадий и результаты их завершения. Никто не выделил бы и копейки разработчикам, которые представили бы плохо проработанное ТЗ («политическое» – термин из статьи). ГОСТ предусматривал также документ под называнием «Программа и методика испытаний», в соответствии с которым продукт сдавался заказчику. И никому даже в голову не приходило, что программу можно не тестировать. Более того, создавались программные и внутрисхемные эмуляторы, строились испытательные аппаратно-программные полигоны, если реальный объект не был доступен по тем или иным причинам. Правда, многих из существующих инструментов поддержки тестирования тогда еще не было.
Однако с распадом Союза эта технология оказалась невостребованной и исчезла. В то же время начали создаваться небольшие фирмы, в которые набирали только молодых людей, владеющих современными методами и инструментами программирования, но не имеющих представления о том, как управлять крупным и серьезным проектом. Научить же их было некому. И вот повторяется путь, уже однажды пройденный. Этот путь у каждой небольшой компании свой, и данная статья рассказывает об одном из них. Он может быть принят или отвергнут, но это некий слепок с реального положения дел, что и явилось побудительной причиной публикации материала. Мы попытались максимально сохранить стиль изложения и видение проблемы тестирования автором, при этом лишь напомнив читателям, что «мнения, высказываемые автором, не всегда совпадают с точкой зрения редакции».
Итак, типичные условия, в которые сегодня попадает новичок: маленькая организация, берущая заказы по разработке какого-либо ПО и состоящая из директора и нескольких программистов, при этом каждый из них выполняет все возможные задачи – от общения с заказчиком до программирования, отладки, внедрения и технической поддержки. Из документации – только «политическое» ТЗ, чтобы формально удовлетворить требования заказчика, и договор.
Если проект более-менее длителен, то проблемы исправления ошибок, учета замечаний пользователей и инженеров технической поддержки постепенно приобретают такой размах, что программисты чаще всего сами, «снизу», инициируют увеличение штата на «девочку, нажимающую кнопки». Так в организации появляется тестер, который может пойти двумя путями.
Первый из них – действительно «нажимать кнопки». Естественно, при работе таким способом «ошибки» у тестировщика быстро заканчиваются, а у пользователей – остаются, что приводит к обвинению его в непрофессионализме. Поэтому второй путь – организовать работу более эффективно.
На этом этапе главное – понять основные цели тестирования. Их определений в литературе множество, но мне больше всего импонирует следующее: «основная цель тестирования – убедиться, что система делает то, что нужно, и не делает того, что не нужно». Первоочередная задача тестера – разработать как можно более полную систему тестов и при этом сделать все, чтобы на следующий раз не забыть, что же он делал, что нашел и как исправление этого найденного проверить.
Для начала важно осмыслить и формализовать уже существующий процесс разработки. Вы можете считать, что его нет, но объективно он есть, просто недостаточно хорош. Далее следует собрать и изучить все должностные инструкции (если их нет – разработать), стандарты предприятия и прочую документацию. В идеале наша цель – заставить общаться свой отдел с остальным миром только посредством документов.
Отсюда – первые выводы:
Из всего моря типов документов, предлагаемых, например, в RUP, можно для начала оставить только четыре |
Ну и, конечно, нужно ознакомиться с теорией. Не полениться выделить неделю на чтение книг и интернет-форумов, посвященных тестированию, хотя после них остается ощущение полной пустоты в голове и чувство собственной неполноценности, пока не придешь к мысли, что теорию следует применять, руководствуясь здравым смыслом. У вас никогда не получится внедрить полноценный RUP (Rational Unified Process – платформа IBM, представляющая обширный набор методов для обеспечения качества ПО на всех этапах его разработки – прим. ред.) в организации из пяти программистов и трех тестеров. Поэтому не стоит и пытаться полностью приспособить к себе теорию, которую использует гигант с многотысячным персоналом и миллиардным бюджетом. Нужно выбрать оттуда только полезное для вас, отбрасывая или упрощая то, что, по вашему мнению и здравому смыслу, будет только отнимать время. В принципе, из всего моря документов можно для начала оставить только четыре, и те упростить до уровня понимания в вашей организации:
На каждую сборку создаются все указанные документы (кроме, естественно, тест-плана). В таком виде их уже достаточно, чтобы по окончании этапа разработки знать, что вся основная функциональность системы была протестирована, и утверждать, что данная сборка работоспособна.
И здесь мы переходим к хранилищу данных и версионности. Собственно говоря, для начала подход достаточно простой. Где-то на файл-сервере формируется общий ресурс, в котором создаются папки на каждый проект. Каждая такая папка содержит следующие элементы:
На первое время (да и в дальнейшем) подобной структуры вполне достаточно для контроля процесса тестирования.
С требованиями, к сожалению, сложнее всего – программисты не любят заниматься рутиной, особенно если это связано со значительным интеллектуальным напряжением. Однако они нужны для того, чтобы знать, что тестировать. Поэтому если их нет, тестер должен составить список сам, хотя бы в виде Excel-таблички. Для этого приходится общаться и с руководством, и с программистами, и с заказчиком, и с собственным здравым смыслом (при этом, опять-таки, сверяясь с заказчиком), но, в конечном итоге, это очень полезная работа.
Собственно, о начальной структуре документов все, однако эти документы не самодостаточны, они только описывают, что необходимо проверять. В процессе работы обнаруживаются ошибки, которые нужно обрабатывать и отслеживать.
И вот на этом этапе наступает черед для внедрения BTS (Bug Tracking System – системы регистрации и отслеживания жизненного цикла дефектов). Для начала это может быть даже Excel-файл с настроенными автофильтрами, но в идеале желательно сразу определиться с ПО, которое будет применено для автоматизированного тестирования, отслеживания ошибок, управления требованиями, документирования и пр. Есть достаточное количество производителей, которые предлагают целые специализированные комплексы. Поэтому зная, в какой области IT работает организация, с какими СУБД и в каких средах разработки, можно подобрать соответствующий продукт. Например, если предполагается использовать Rational, то в качестве системы регистрации и отслеживания ошибок лучше установить Rational Clear Quest. Причем на первом этапе в качестве рабочей БД лучше выбирать Access в связи с легкостью преобразования данных из нее во что угодно при последующей смене управляющего ПО.
BTS сначала встречает неприятие у программистов, но уже практически через неделю они не могут без нее работать. Одним из достоинств подобных систем является формализация общения между отделами и исключение недоразумений в вопросах ответственности, а для менеджеров – возможность объективно оценивать уровень квалификации и вклад в общее дело своих сотрудников.
Таким образом, для первичной организации тестирования необходимо, образно выражаясь, выполнить условия трех «Ф», которые заключаются в следующем:
Собственно, хороший производственный процесс тем отличается от плохого, что он не пущен на самотек, а упорядочен и управляем.