tестирование dot com

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

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

а. О пользе приоритезации мы уже говорили. Странно, но во мно

гих компаниях предпочитают изматывать людей, вместо того

чтобы приоритезировать тест-комплекты и тест-кейсы и испол

нять лишь те из них, которые реально важны.

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

могут быть оптимизированы в смысле

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

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

Часто имеет смысл пересмотреть, КАК происходит тестирование

в старых тест-комплектах: может быть, некоторые из тест-кейсов

уже устарели и/или были написаны тулы для упрощения работы

некоторых из них и пр.

278

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

в. Когда денег много, а ума мало, прибегают к массированному

найму новых тестировщиков, что, конечно, лишь отодвинет реше

ние проблемы, но не решит ее, так как нельзя бесконечно нани

мать людей. Я против массированного найма (иногда нанимаются

десятки!!! тестировщиков в год) и считаю, что интернет-компании

нужен департамент качества, состоящий из немногочисленной

группы профессиональных высокооплачиваемых специалистов,

которые будут решать проблему регрессивного тестирования

подходами а, б и г.

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

жество монографий. Я же просто введу вас в курс дела.

Итак, в проекте www.testshop.rs скопилось, например, 78 тест-

комплектов, которые нужно как-то исполнять при регрессивном

тестировании, причем это количество постоянно увеличивает-

ся. Так как у нас нет спеца по автоматизации тестирования, то

мы такого спеца нанимаем. Например, это будет г-н Говорков.

Созывается совещание тестировщиков, и менеджер представ-

ляет г-на Говоркова в роли, примерно, мессии, который решит

все наши проблемы с регрессивным тестированием. Когда слово

предоставляется самому г-ну Говоркову, то его речь сводится к

следующему: "Ща я вам тут все заавтоматизирую!" Тратится

несколько тысяч (нередко десятки тысяч) долларов на покупку

программы для автоматизации тестирования Silk Test (произво-

дитель — компания Segue), и автоматизация начинается.

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

автоматический скрипт и начинается магия:

подпрограмма силк-теста — агент открывает окно браузера,

вводит имя пользователя и пароль, нажимает на кнопку "Вход ",

совершает покупку и оплату и сравнивает фактический резуль-

тат с ожидаемым. Все в полном восторге, ведь очевидно, что

через пару месяцев все тест-комплекты будут автоматизиро-

ваны и, вместо того чтобы работать в поте лица в выходные,

мы просто запускаем в пятницу автоматический скрипт силк-

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

автоматизированного тест-кейса. Одним словом — лепота!

Однако когда во время регрессивного тестирования следующего ре-

лиза мы просим г-на Говоркова запустить автоматические скрип-

ты для тест-комплектов, которые он уже "заавтоматизироват",

выясняется, что его автоскрипты не работают из-за того, что ин-

терфейс веб-сайта был в нескольких местах незначительно изменен.

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

279

Например, в автоскрипте может быть инструкция о нажатии

кнопки "Вход " на такой-то странице, и если агент, исполняющий

автоскрипт, не "видит" кнопки с именно таким названием, то

генерируется ошибка и исполнение тест-кейса прерывается.

Г-н Говорков, говорит "фигня вопрос ", тратит на починку скрип-

тов пару недель и в последний день регрессивного тестирования

его автоскрипты все-таки исполняют пару из 10 автоматизи-

рованных им тест-комплектов. В следующий релиз все повторя-

ется заново, и в итоге менеджер решает уволить г-на Говоркова

и взять на его место обыкновенного черноящичного тестиров-

щика — будет дешевле и эффективнее.

Я ничуть не утрирую. Подобные ситуации происходят в боль-

шинстве случаев после принятия компанией решения об автома-

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

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

Автоматизация регрессивного тестирования заключается в соз-

дании целой тестировочной инфраструктуры с библиотеками

кода, базами данных, системами отчетности и прочими вещами.

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

Иногда менеджмент, желая получить результат быстро и любой це-