Home

Автор: Алексей Курских

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вот на этом этапе наступает время для внедрения BTS.

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

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

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

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

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

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

Источник: Компьютерное обозрение. №43 от 8 ноября 2005г. (публикуется с согласия автора)