Решение проблемы противоречия

Проблема противоречия между ограниченными ресурсами (напри­мер, время на регрессивное тестирование) и постоянно растущим количеством тест-комплектов решается следующими способами:

а. Приоритезация тест-комплектов и тест-кейсов.

б. Оптимизация тест-комплектов.

в. Наем новых тестировщиков.

г. Автоматизация регрессивного тестирования.

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

б. Оптимизация тест-комплектов. Многие старые тест-комплекты
могут быть оптимизированы в смысле

• уменьшения количества тест-кейсов и/или

• упрощения исполнения тест-кейсов.

Часто имеет смысл пересмотреть, КАК происходит тестирование в старых тест-комплектах: может быть, некоторые из тест-кейсов уже устарели и/или были написаны тулы для упрощения работы некоторых из них и пр.

Тестирование Дот Ком. Часть 3

в. Когда денег много, а ума мало, прибегают к массированному
найму новых тестировщиков, что, конечно, лишь отодвинет реше­
ние проблемы, но не решит ее, так как нельзя бесконечно нани­
мать людей. Я против массированного найма (иногда нанимаются
десятки!!! тестировщиков в год) и считаю, что интернет-компании
нужен департамент качества, состоящий из немногочисленной
группы профессиональных высокооплачиваемых специалистов,
которые будут решать проблему регрессивного тестирования
подходами а, б и г.

г. Автоматизации регрессивного тестирования посвящено мно­
жество монографий. Я же просто введу вас в курс дела.

Итак, в проекте www.testshop.rs скопилось, например, 78 тест-комплектов, которые нужно как-то исполнять при регрессивном тестировании, причем это количество постоянно увеличивает­ся. Так как у нас нет спеца по автоматизации тестирования, то мы такого спеца нанимаем. Например, это будет г-н Говорков. Созывается совещание тестировщиков, и менеджер представ­ляет г-на Говоркова в роли, примерно, мессии, который решит все наши проблемы с регрессивным тестированием. Когда слово предоставляется самому г-ну Говоркову, то его речь сводится к следующему: "Ща я вам тут все заавтоматизирую!" Тратится несколько тысяч (нередко десятки тысяч) долларов на покупку программы для автоматизации тестирования Silk Test (произво­дитель — компания Segue), и автоматизация начинается.

Через неделю происходит первая демонстрация: запускается автоматический скрипт и начинается магия:

подпрограмма силк-теста — агент открывает окно браузера, вводит имя пользователя и пароль, нажимает на кнопку "Вход ", совершает покупку и оплату и сравнивает фактический резуль­тат с ожидаемым. Все в полном восторге, ведь очевидно, что через пару месяцев все тест-комплекты будут автоматизиро­ваны и, вместо того чтобы работать в поте лица в выходные, мы просто запускаем в пятницу автоматический скрипт силк-теста, а в понедельник видим результат исполнения каждого автоматизированного тест-кейса. Одним словом — лепота!

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

Исполнение тестирования. Стадия 2: регрессивное тестирование 279

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

Г-н Говорков, говорит "фигня вопрос ", тратит на починку скрип­тов пару недель и в последний день регрессивного тестирования его автоскрипты все-таки исполняют пару из 10 автоматизи­рованных им тест-комплектов. В следующий релиз все повторя­ется заново, и в итоге менеджер решает уволить г-на Говоркова и взять на его место обыкновенного черноящичного тестиров-щика — будет дешевле и эффективнее.

Я ничуть не утрирую. Подобные ситуации происходят в боль­шинстве случаев после принятия компанией решения об автома­тизации регрессивного тестирования.

Почему так происходит?

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

Создание такой инфраструктуры — дело очень и очень непростое.

Иногда менеджмент, желая получить результат быстро и любой це­ной, давит на спеца по автоматизации, и даже если последний добро­совестно создает инфраструктуру для автоматизации, то он это дело бросает и абы как автоматизирует максимальное количество тест-комплектов, для того чтобы менеджмент мог отчитаться перед выше­стоящим менеджментом: "За первый квартачл 2005 года было авто­матизировано 12 тест-комплектов, содержащих 174 тест-кейса".

Конечно, все эти автоскрипты не будут вскоре функционировать без трудоемкой поддержки, но кого это волнует? Начальство до­вольно, и, значит, все "Хоккей".

Но допустим, что менеджмент все понимает и дает карт-бланш на создание Инфраструктуры с большой буквы "Ай".

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

Тестирование Дот Ком. Часть 3

Я предлагаю очень простой подход к определению эффективно­сти автоматизированного регрессивного тестирования. Посмот­рите, сколько багов было найдено при автоматизированном тес­тировании за все время использования автоскриптов, разделите общие затраты на автоматизацию на количество багов — резуль­татом будет стоимость нахождения одного бага. Сделайте то же вычисление для того же отрезка времени, но для ручного тести­рования и сравните. В 90% случаев стоимость бага, найденного автоскриптом, будет в несколько раз превышать стоимость бага, найденного вручную. И очень большой шанс, что вы подумаете: а зачем вообще нужна ТАКАЯ автоматизация?..

Кстати,

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

Советую также сравнить время, потраченное на автоматизацию (и ее поддержку) для некого тест-комплекта, с временем на исполне­ние этого же тест-комплекта вручную. Гарантирую, что результаты удивят, в смысле неприятно удивят, и не в пользу автоматизации.

Таким образом, наиважнейшее значение приобретает профессио­нализм специалиста по автоматизации.

Профессионализм такого спеца заключается не только в его про­граммистских навыках, но и в том, как четко он представляет:

• ЧТО автоматизировать и

• КАК автоматизировать.

ЧТО:

Лучший кандидат для автоматизации — это тест-кейс для тести­рования старой, устоявшейся фича. Автоматизируя его, мы, по крайней мере, можем быть уверены, что автоскрипт не нужно будет переписывать из-за изменения фича и соответственно из­менения тест-кейса к ней.

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

Один мой друг сравнивает фича с человеком: если это ребенок, то он постоянно меняется; если же он взрослый, то изменений в нем намного меньше и сами изменения менее радикальны — сравните

Исполнение тестирования. Стадия 2: регрессивное тестирование 281

того же ребенка, когда ему 6 и 12 лет; и теперь взрослого, когда ему 42 и 48 лет. Идея, я думаю, понятна.

Чем меньше будет изменений в фича, тестирование которой ав­томатизировано, тем меньше времени будет затрачено на под­держку. Поддержка же порой превращается в кошмар

• с чередой красноглазых бессонных ночей перед монитором,

• с горьким пониманием того, что все было сделано непра­вильно, и

• со сладостным искушением все бросить и поехать с Лелей в Ялту.

КАК:

Это создание инфраструктуры, позволяющей с легкостью и про­стотой

• поддерживать существующие автоскрипты;

• создавать новые автоскрипты.

Инфраструктура автоматизации регрессивного тестирования должна

• с одной стороны, быть образцом программистского мас­терства;

• с другой — воплощать наиболее эффективные подходы

к автоматизации, возможные при данном ПО для автома­тизации (например, силк-тесте);

• с третьей — учитывать нюансы технологий именно этой
интернет-компании.

В заключение нашего краткого разговора об автоматизации рег­рессивного тестирования я хочу открыть вам одну истину:

Суровая правда жизни заключается в том, что 100%-я авто­матизация регрессивного тестирования сколько-нибудь серь­езного веб-проекта — это миф.

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

Если ваша компания решила заняться автоматизацией рег­рессивного тестирования, нужно потратить столько времени, сколько нужно, чтобы найти настоящего профессионала, а найдя его, дать ему дышать и не ожидать, что 100% тест-ком­плектов когда-либо будут автоматизированы.

Это все о решении основной проблемы регрессивного тестирования.

Тестирование Дот Ком. Часть 3

Хорошая идея — это предусмотреть окончание регрессивного тестирования за 2—3 дня до релиза:

• с одной стороны, у нас будет в запасе 2—3 дня, которые мы можем использовать для завершения регрессивного тести­рования, если наша оценка того, сколько дней оно займет, была неверна.

• с другой — эти 2—3 дня можно потратить на тест-сдачи, распределив между тестировщиками части ПО.

А дальше идет релиз...

Дата добавления: 2015-12-07