Главная страница

фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин


Скачать 5.26 Mb.
НазваниеПособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
Анкорфабпждфуквп
Дата06.05.2022
Размер5.26 Mb.
Формат файлаpdf
Имя файлаСавин Тестирование dot-com.pdf
ТипПособие
#515165
страница21 из 24
1   ...   16   17   18   19   20   21   22   23   24
Кстати, хорошая традиция — это устроить в конце подготовки к тести-
рованию (или начале исполнения тестирования) совещание, на кото-
ром каждый тестировщик, у которого есть новая фича, сделал бы ее
короткую, например на две минуты, презентацию. Таким образом мы
быстро и эффективно распространяем информацию о новых фича, так,
чтобы все были в курсе.
Вопрос: Как мы тестируем новые фича?
Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем их. Попутно заносим баги. Спорим с программистами о приори- тетах этих багов. Закрываем эти баги. Одним словом, обычная суета сует.
Это в общем-то все насчет стадии 1 исполнения тестирования, но, поскольку нужно чем-то занять время, давайте поговорим о не- скольких нужных вещах:
Test Estimation (тест-смета).
Entry/Exit Criteria (критерий начала/завершения).
Test Plan (тест-план).
Test Estimation (тест-смета)
Как правило, в интернет-компаниях существует расписание рели- зов. К этому расписанию привязано расписание тестирования (QA
Schedule), которое определяет сроки каждой стадии процесса тес- тирования.
"Как правило" было употреблено из-за того, что в некоторых
компаниях такого понятия, как "Расписание", не существует в
принципе.
Итак, допустим, что
на подготовку к тестированию дается две недели (10 ра- бочих дней (80 часов) + 4 выходных дня (32 часа), которые элементарно могут стать рабочими);
на исполнение тестирования также дается две недели
(10 рабочих дней (80 часов) + 4 дня выходных дня (32 часа), которые также элементарно могут стать рабочими),
т.е. у нас есть две недели на написание тест-кейсов (и прочие подготови- тельные мероприятия) и

260
Тестирование Дот Ком. Часть 3
две недели, в которые нужно уместить:
• тестирование новых фича по созданным тест-кейсам;
• регрессивное тестирование.
Проблема в том, что, как бы ударно мы ни работали, мы можем выполнить лишь определенный объем работы и возникает кон- фликт между
• лавиной новых фича, которые могут понадобиться для биз- неса компании, и
• физическими возможностями продюсера, программиста и тестировщика.
Чтобы уравновесить желаемое и реальное, используют сметы
(estimation).
Тестировщик готовит тест-смету (Test Estimation), которая вклю- чает:
• предварительную оценку времени, необходимого на под- готовку к тестированию;
• предварительную оценку времени, необходимого на тести- рование новых фича.
Как тестировщик готовит тест-смету? Очень просто:
после того как написан спек, менеджер тестировщика просит по- следнего прочитать этот спек и оценить, сколько времени займут написание тест-кейсов по этому спеку и прочие подготовитель- ные мероприятия и исполнение этих тест-кейсов. Тестировщик читает спек, предметно общается с продюсером и программистом и на основе полученной информации и своего опыта предостав- ляет менеджеру два числа, являющиеся тест-сметой для данного спека.
Пример
Для создания тест-сметы тестировщику был дан спек #1299 "Новые
функциональности поиска".
Тестировщик предоставил своему менеджеру следующее:
потребуется 50 часов на написание тест-кейсов и 20 часов на
написание тест-тулов;
потребуется 60 часов на исполнение этих тест-кейсов.
Таким образом, тестировщик полностью укладывается в график по
подготовке к тестированию (80 - 50-20 >0). Оставшиеся 10 часов
можно будет использовать для помощи своим коллегам и/или как ре-

Исполнение тестирования. Стадия 1: тестирование новых фича
261
зерв на случай, если оценка тестировщика была неверной и на подго-
товку в реальности потребуется больше времени.
Сложнее обстоит дело с исполнением тестирования. На регрессивное
тестирование остается только 20 часов (80 - 60). Будет ли этих 20 ча-
сов достаточно, чтобы закончить регрессивное тестирование в срок?
Это зависит от нескольких факторов, основные из них:
значительность релиза, например: имело ли место серьезное
изменение архитектуры ПО? На сколько процентов изменилось
количество строк кода? Были ли добавлены новые критические
функциональности, интегрированные со старым кодом? и пр.;
трудоемкость тест-комплектов, которые нужно исполнить для
регрессивного тестирования (подробно поговорим о нюансах
регрессивного тестирования через полчаса).
Ответ на последний вопрос ("будет ли достаточно 20 часов?"), как и
сам процесс уравновешивания потребностей бизнеса и возможностей
работников, — это епархия менеджмента, а мы люди простые, и наше
дело — дать предварительные оценки, по возможности приближенные
к недалекой реальности.
Итак, как создать тест-смету?
Сложность заключается в том, что тест-смета создается после того, как прочитан спек, а между чтением спека и работой по не- му такая же дистанция, как между теоретиком и практиком кун- фу. Во время работы над спеком, т.е. создания по нему тест- кейсов, открываются такие грани и нюансы, о существовании ко- торых было трудно (если не невозможно) предположить во время простого прочтения. Кроме того, всегда есть непредвиденные обстоятельства, среди которых может быть, например, неприлич- но большое количество блокирующих багов.
Кстати,
после того как тест-смета готова, рекомендую увеличить ее на 10%,
чтобы учесть такие непредвиденные обстоятельства.
Вот факторы, которые я рекомендую принять во внимание при составлении сметы:
предполагаемая сложность новых фича.
Чем они сложнее, тем больше нюансов всплывет при под- готовке и исполнении и тем больше времени понадобится на тестирование;
есть ли у вас опыт тестирования похожих фича.
Например, если вы эксперт в тестировании оплаты, то для вас будет проще и быстрее протестировать добавление

262
Тестирование Дот Ком. Часть 3
еще одного вида кредитной карточки по сравнению с тестировщиком, который никогда кредитных карточек не касался;
опыт работы на прошлых проектах с теми же продюсе
ром и программистом.
Например, одни программисты пишут удивительно чистый код, всегда проводят юнит-тестирование и с охотой кооперируются с тестировщиками. Другие же бросают куски кода в проект, как грязь на стену, считают юнит- тестирование вещью, не подобающей для компьютерного гения, и не склонны кооперироваться ни с кем, кроме виртуальных солдат игры Halo. Следовательно, во втором случае мы должны заложить больше времени на наше тес- тирование;
• будет ли интеграция нашего ПО с ПО наших бизнес-парт
неров вендоров (vendor),
например интеграция с ПО платежной системы. Тест-кон- фигурация выглядит так: наша тест-машина "разговари- вает" с их тест-машиной. Соответственно если что-то не в порядке с их тест-машиной, то проблема решается слож- нее, чем при локальном тестировании, когда вы заносите баг и наш программист его ремонтирует. В случае с их тест-машиной
• тестировщик связывается с менеджером проекта (с на- шей стороны);
• последний должен позвонить вендору;
• человек со стороны вендора должен найти ответст- венного программиста;
• ответственный программист может быть занят
• и т.д. и т.п.
В общем целая петрушка из-за того, что это другая ком- пания и наши тестировщики не указ "их" программистам.
В случае с интеграцией нашего ПО с не нашим ПО оценка должна принимать в расчет подобные задержки в решении проблем, которые при такой интеграции бывают всегда;
• нужны ли тулы для автоматизации тест-кейсов?
Тест-тулы, как правило, создаются во время написания тест- кейсов как средство для облегчения исполнения тест-кейса, например:

Исполнение тестирования. Стадия 1: тестирование новых фича
263
• генерация данных (например, генерация номера тес- тировочной кредитной карты),
• автоматизация всех либо части шагов,
• помощь в сравнении фактического и ожидаемого ре- зультатов.
В одних случаях тестировщик может сам написать такой тул, например, на языках Java или Python. В других случаях написание тула в помощь тестировщи-кам — это дело программиста.
Кстати,
в некоторых компаниях внутри департамента качества существую!
специальные отделы по созданию тест-тулов.
Вы должны подкорректировать тест-смету в зависимости от ва- шей оценки того:
• сколько времени у вас займет создание (включая тестиро- вание) такого тула (если тул создается вами, а не програм- мистом);
• сколько времени этот тул сможет реально сэкономить во время тестирования новых фича.
Итак, при составлении тест-сметы используем вышеперечислен- ные факторы, слушаем свои опыт и интуицию и советуемся с коллегами.
Упоминание о тест-тулах напомнило мне об одном предмете, который особенно беспокоит сердца обучающихся тестированию, а именно объеме компьютерных знаний.
Вот мое мнение: естественно, что наивно думать об устройстве тес- тировщиком в интернет-компанию тому, кто не умеет пользоваться е-мейлом и веб-браузером и не знает разницы между принтером и модемом.
Хорошая новость: на первую работу тестировщиком можно устроить- ся, имея базовые компьютерные знания, которые есть у каждого, кто пользовался компьютером и Интернетом больше одного месяца.
Конечно, шансы трудоустройства существенно повышаются, если у вас есть дополнительные к базовым знания (приведу конкретные рекомендации через минуту).
Давайте скажем "Спасибо" океану информации под названием "Ин- тернет" за

264
Тестирование Дот Ком. Часть 3
• гигабайты бесплатного ПО, например компайлеры для C++ и интерпретаторы Python;
• тысячи бесплатных курсов по компьютерным дисциплинам, на- пример пособия по изучению языка SOL;
• интернет-форумы на любую тематику, где любой оболтус (вклю- чая меня) может задать самый идиотский вопрос и получить на него ответ;
• веб-сайты, бродя по которым мы попутно становимся квалифи- цированными пользователями Интернета;
• десятки других милых и полезных вещей.
Используйте ресурсы Интернета!!! В нем есть все, что вам нужно, что- бы стать тестировщиком экстра-класса.
Вот список вещей, к которым я предлагаю хотя бы прикоснуться перед поиском первой работы. Потратьте по крайней мере по 10 ча- сов на каждое "прикосновение", причем не просто читайте теорию,
а работайте с соответствующим ПО (или на соответствующем ПО),
например:
• в случае с UNIX исполняйте команды, например команду "mkdir",
для создания директории или
• пишите код на Python.
1. HTML. Основной язык веб-страниц. Веб-учебник (web tutorial)
на английском языке и программа для симуляции может быть найдена здесь: http://www.w3schools.com. Изучите базовые теги
(tag).
2. SQL. Язык баз данных. Веб-учебник на английском языке можно найти здесь: http://www.w3schools.com. Разберитесь с синтакси- сом следующих видов запросов (statements):
CREATE TABLE;
ALTER TABLE;
DROP TABLE;
INSERT INTO;
UPDATE;
DELETE;
SELECT.
Скачайте и установите на ваш компьютер базу данных MySQL
(http://www.mysql.com/).
3. Python. Веб-учебники на английском языке и установочную про- грамму для интерпретатора можно найти на http://www.python.org.
Возьмите самый простой учебник и ощутите всю прелесть просто- ты и доступности моего любимого языка программирования.
4. UNIX. Вот наипростейший веб-учебник:
http://www.math.utah.edu/lab/unix/unix-tutorial.html
. Симулятор UNIX
для Виндоуз-машин можно скачать здесь: http://www.cygwin.com.

Исполнение тестирования. Стадия I: тестирование новых фича
265 5. C++. Веб-учебник может быть найден здесь:
http://www.cplusplus.com/doc/tutorial. Напишите несколько про- грамм, скомпилируйте их, откройте в текстовом редакторе файлы- источники (source file), скомпилированные файлы (bytecode file)
и ощутите разницу. Компайлер дсс является частью симулятора
CygWin, которую вы установите при знакомстве с UNIX.
Естественно, что мои пояснения о том, ЧТО изучить для каждого из вышеуказанных 5 предметов, — это минимум для того, чтобы иметь элементарное представление, но даже такой минимум — это ваш ко- зырь. Очень рекомендую. То, что сейчас кажется вам сложным и запу- танным, будет доступным и понятным завтра. Нужно только иметь терпение и приложить немного усилий.
После того как вы найдете работу, специфика ваших технических зна- ний будет во многом определяться технологиями, используемыми в вашей интернет-компании (например, операционная система маши- ны для пользователей, языки программирования, вид базы данных).
Некоторые из тех, кто начал работать тестировщиком на черноящич- ном тестировании, распробовали знания из смежных специальностей
(например, администрация баз данных) и переместились туда;
некоторые выбрали себе узкую специализацию внутри департамента качества, например написание тест-тулов;
некоторые продолжают с удовольствием для себя и пользователей заниматься черноящичным тестированием или же перешли к серо- ящичным или белоящичным делам — к чему лежит душа.
Но чтобы найти в итоге свою нишу, нужно искать, а лучший по-
иск — это изучение новых вещей.
Одна из прелестей нашей профессии заключается в том, что
тестировщик соприкасается с множеством вещей как техниче-
ского (язык программирования), так и нетехнического свойства
(менеджмент проекта), так что вам и карты в руки — разбери-
тесь на месте, что вам больше нравится, и приложите усилия,
чтобы в итоге заниматься именно этим. Шансы велики, что это
будет именно тестирование.
Entry/Exit Criteria
(критерий начала/завершения)
Все очень просто.
Entry Criteria (условие старта) — это условие для начала чего- либо.
Exit Criteria (условие завершения) — это условие для завершения чего-либо.

266
Тестирование Дот Ком. Часть 3
Каждый из двух этапов тестирования имеет свои условия старта и условия завершения.
Например
Условие старта для подготовки к тестированию: все спеки должны быть
заморожены.
Условие завершения подготовки к тестированию: тест-кейсы и прочие
подготовительные мероприятия написаны и закончены.
Условие старта для исполнения тестирования: код заморожен.
Условие завершения исполнения тестирования: тестирование новых
функциональностей и регрессивное тестирование завершено, нет от-
крытых П1 и П2 багов.
Test Plan (тест-план)
Вопрос: Почему мы не поговорили о тест-планах при нашей бе- седе о тест-кейсах и тест-комплектах? Ответ: Я не хотел забивать вам головы.
Вопрос: Тогда почему вы их забиваете сейчас?
Ответ: Потому что с теми знаниями, которые у вас уже есть, вам будет проще понять этот материал.
Итак, приступим.
Что такое тест-план? Если вы спросите тестировщиков разных компаний о том, что идет под именем "тест-план" в их компа- ниях, то ответ часто будет варьироваться:
иногда тест-планом называют тест-комплект,
• в других случаях тест-планом называют пару мыслей о тес- тировании, набросанных на полях журнала "Playboy",
• в третьих случаях тест-планом называют текстовый доку- мент, содержащий выдержки из спека, глядя на которые и проводится тестирование (такое тоже бывает сплошь и рядом),
• есть еще и четвертые, и пятые случаи.
Вот концептуальная вещь:
тест-кейс нужен для сравнения фактического результа-
та с ожидаемым результатом;
тест-комплект — это логическая оболочка для хране-
ния тест-кейсов;
тест-план — это документ, обобщающий и координи-
рующий тестирование.

Исполнение тестирования. Стадия 1: тестирование новых фича
267
Я обычно ограничиваюсь тест-комплектами и создаю тест-план,
если возглавляю проект с участием других тестировщиков.
Давайте рассмотрим элементы, которые вы можете использовать в тест-планах.
Кстати, вовсе не обязательно использовать все элементы:
1. Вы можете взять элементы (и/или идеи из них) и интегрировать их
в свои тест-комплекты;
2. Вы можете использовать тест-план в усеченном виде.
Итак...
ЭЛЕМЕНТЫ ТЕСТ-ПЛАНА
1. Название тест-плана, имя автора и номер версии.
Например
«Тест-план проекта "Новые алгоритмы для поиска"». Автор Т. Чере-
мушкин. Версия 2.
2. Оглавление с разделами тест-плана:
Например
Введение
стр. 2
Документация с требованиями к ПО стр. 3 и
т. д.
3. Введение, в котором мы приводим информацию о сути и исто- рии тестируемого проекта.
4. Документация с требованиями к ПО — здесь мы перечис- ляем имена, номера и приоритеты спеков и/или другой докумен- тации, определяющей тестируемые фича.
5. Фича, которые будут тестироваться, перечисляем и, если нужно, комментируем. Каждой фича назначается приоритет.
6. Фича, которые НЕ будут тестироваться, перечисляем и объ- ясняем, почему НЕ будут тестироваться.
Например,
частью спека #9172 "Улучшение безопасности платежных транзакций"
являются требования к скорости работы веб-сайта (performance). До-
пустим, у нас нет ни специалиста, ни ПО для тестирования скорости
работы, и если мы не собираемся их нанять и приобрести, то указываем,
что перформанс тестироваться не будет, так как нет ресурсов.

268
Тестирование Дот Ком. Часть 3
7. Объем тестирования — виды тестирования, которые мы бу- дем проводить, и разъяснения к ним.
Например
"Системное тестирование будет исполняться для проверки всего флоу
оплаты, начиная от добавления книги в корзину и заканчивая про-
веркой значений базы данных и подтверждением от тест-машины
вендора".
8. Тест-документация — перечисление тест-документации, ко- торая должна быть создана для данного проекта
Например
"Тест-комплект по тестированию опека #1288.
Тест-комплект по тестированию спека #3411".
9. Тест-тулы — функциональности тест-тулов, которые должны быть созданы для тестирования проекта.
10. Критерий начала/завершения — те самые критерии, о кото рых мы говорили минуту назад:
• критерий начала подготовки к тестированию;
• критерий завершения подготовки к тестированию;
• критерий начала исполнения тестирования;
• критерий завершения исполнения тестирования.
11. Допущения — список допущений, которые мы сделали при составлении данного тест-плана и которые сделаем при тестиро вании.
Например,
мы допускаем (предполагаем), что код будет заморожен в срок, без
задержки.
12. Зависимости — список вещей (с пояснениями), от которых зависит та или иная часть тестирования.
Например,
покупка новых тест-машин,
лицензия на осуществление платежных операций на территории Вели-
кобритании.
13. "Железо" и ПО — список и конфигурации "железа" и ПО, которые будут использоваться при тестировании.

Исполнение тестирования. Стадия 1: тестирование новых фача
269
14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/ продолжено.
Например,
к условию приостановки можно отнести количество П1 багов, при ко-
тором (и/или после которого), по мнению автора (-ров) тест-плана,
дальнейшее продолжение тестирования не имеет смысла (например,
7 П1). Соответственно условием возобновления должно быть количе-
ство оставшихся П1 багов (после ремонта и регрессивного тестирова-
ния), которое позволяет возобновить тестирование (например, 2 П1).
15. Ответственные лица — подробный список товарищей (про- дюсеров, программистов, тестировщиков и пр.), контактная ин- формация и обязанности каждого из них. Такой список может включать лиц со стороны вендора.
16. Тренинг — тренинг, необходимый для данного проекта.
Например,
при соответствующей ситуации нужно указать, что для создания тест-
кейсов тестировщику необходимо прослушать семинар "Банковская
система США".
17. Расписание — сроки, имеющие отношение к тестированию данного проекта:
• дата замораживания спеков;
• дата начала подготовки к тестированию;
• дата завершения подготовки к тестированию;
• дата интеграции и замораживания кода;
• дата начала тестирования новых фича;
• дата завершения тестирования новых фича;
дата начала регрессивного тестирования;
• дата завершения регрессивного тестирования.
18. Оценка риска — предположение о том, как и что может пой ти по неправильному пути и что мы в этом случае предпримем.
Например,
если мы не успеваем закончить тестирование (не выполняем требова-
ние "Условия завершения", например, "все тест-кейсы исполнены") в
срок, то придется задерживаться на работе и приходить в офис в вы-
ходные и праздники.
Кстати, если народ приходит в выходные и праздники, то компания
должна, по крайней мере, кормить его обедом.

270
Тестирование Дот Ком. Часть 3
19. Прочие положения — вещи, не вошедшие в тест-план, о ко- торых неплохо было бы упомянуть.
20. Утверждения — это подписи лиц, которые утвердили тест- план. Чем больше будет таких подписей, тем лучше. По крайней мере, нужны подписи менеджера тестировщика, составившего план, самого тестировщика, продюсера и программиста.
21. Приложения — например, расшифровка терминов и аббре- виатур, используемых в тест-плане.
Это все о тест-планах и о первой стадии исполнения тестирова- ния.

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.
СТАДИЯ 2:
РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ

ВЫБОР ТЕСТ
-
КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО
ТЕСТИРОВАНИЯ

РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ
егрессивное тестирование как второй этап исполнения тес-
тирования — это проверка того, что изменения, сделан-
ные в ПО (для того, чтобы мир увидел новые фича), не поло-
мали старые фича.
Допустим, у нас есть 5 тест-комплектов с тест-кейсами для новых фича, а также 21 тест-комплект с тест-кейсами для старых фича.
Ситуация эта рождает как минимум два вопроса:
1. Какие из этих 21 тест-комплекта выбрать, чтобы:
• проверить именно те части ПО, которые могли быть по- ломаны?
• уложиться в срок, выделенный для регрессивного тести- рования (например, 5 рабочих дней + два выходных дня, которые вполне могут стать рабочими)?
2. Что делать с регрессивным тестированием дальше, ко гда после релиза к 21 тест-комплекту прибавятся еще 5
(тест-комплекты, которые проверяли новые фича, прим кнут к остальным тест-комплектам и станут кандидатами для регрессивного тестирования) и еще, скажем, 10 после следующего релиза и т.д. (постоянно нарастающий снеж ный ком)?
271
Р


Исполнение тестирования. Стадия 2: регрессивное тестирование
273
Итак, две темы:
1. Выбор тест-комплектов для регрессивного тестирования.
2. Решение проблемы противоречия между ограничен-
ными ресурсами (например, время на регрессивное тес-
тирование) и перманентно увеличивающимся количест-
вом тест-комплектов.
Кстати, как обычно, я излагаю личное видение предмета. В разных
компаниях поступают по-разному, но, после того как вы поймете, что я
вам расскажу, вы сможете немедленно адаптировать свои знания к ре-
альности компании, в которой будете работать.
Выбор тест-комплектов
для регрессивного тестирования
Первый вопрос: "Как узнать, какие части ПО могут быть поломаны?"
С одной стороны, как мы уже не раз говорили, в сложной системе, которой является более или менее серьезный веб-сайт, во многих случаях сверхсложно определить, где и как откликнется измене- ние кода, с другой — мы все-таки можем предполагать:
к какой части ПО принадлежат новые фича (например, фича из спека #5419 "Новые функциональности для Кор- зины" принадлежат к "Корзине") и
какие старые фича напрямую зависят от части ПО с
новыми фича (например, компонент "Оплата" использует данные (по ценам книг), которые передаются ей компонен- том "Корзины").
Решение следующее:
Первой группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие часть ПО, к которой принадлежат новые фича.
Например,
при новых фича для "Корзины" в первую группу идут все тест-комплек-
ты, непосредственно тестирующие "Корзину".
Рациональное объяснение:
если программист напортачил с кодом, то фича, тестируемые тест- комплектами первой группы, будут поломаны скорее всего, так как являются частью ПО с измененным кодом.

274
Тестирование Дот Ком. Часть 3
Второй группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие старые фича, которые зависят от части ПО с новыми фича.
Например,
при новых фича для "Корзины" во вторую группу мы можем отнести
тест-комплекты, проверяющие "Оплату".
Рациональное объяснение:
если даже программист НЕ сломал ничего, есть большая вероят- ность того, что код фича, напрямую зависящей от измененной части ПО, также нуждается в модификации (о необходимости ко- торой и продюсер, и программист могли просто... забыть).
Например, при изменениях в коде "Корзины" был легитимно (согласно
спеку) изменен формат куки (cookie — файл с информацией о вашем
заказе, хранящийся на вашем компьютере и используемый веб-сер-
вером). Часть же ПО, которая заведует "Оплатой", не была модифи-
цирована (или была модифицирована неверно), и она (эта часть ПО)
просто не понимает новый формат куки, а следовательно, купить книгу
не представляется возможным.
Есть и третья группа, к которой мы подберемся чуть позднее.
Пока же допустим, что группы только две.
Проиллюстрируем:
Группа
Номер тест-комплекта
1
#XS1111
#TS1222
#TS1333 2
#TS2444
#TS2555
#TS2777
#TS2888
#TS2999
Теперь вопрос второй: "Как уложиться в срок, выделенный для регрессивного тестирования?"
Допустим, что у нас есть два тестировщика и неделя времени, т.е.
80 человеко-часов (112 — с выходными, 336 — без сна и отдыха).
Вопрос: Сможем ли мы исполнить все 8 тест-комплектов за эти
80 часов?

Исполнение тестирования. Стадия 2: регрессивное тестирование
275
Ответ: Очевидно, что для этого нужно знать, сколько времени занимает исполнение каждого из этих тест-комплектов.
Вопрос: Как это узнать?
Ответ: Каждая компания делает по-своему. В одних компаниях есть специальные механизмы трэкинга времени, потраченного на исполнение каждого из тест-комплектов (иногда даже считается время на исполнение каждого тест-кейса), в других после каждо- го исполнения тестировщик указывает время исполнения в шапке тест-комплекта. В общем разные бывают варианты, но суть в том, что необходимо хотя бы примерно знать, сколько времени зани- мает исполнение каждого тест-комплекта.
"Примерно" потому что исполнение тест-комплекта может
варьироваться в зависимости, например, от того, кто его испол-
няет (хотя есть и другие факторы). На практике, особенно в слу-
чаях со сложными и трудоемкими тест-комплектами, быстрее
справляется с задачей тот, кто уже однажды исполняв данный
конкретный тест-комплект.
Допустим, что мы знаем, сколько времени занимает исполнение каждого тест-комплекта.
Оговорка: в реальной жизни исполнение тест-комплектов, как
правило, занимает гораздо меньше времени, чем в примере ниже,
но нам нужна наглядность.
Группа
Номер тест-комплекта
Время на исполнение
(в часах)
1
#TS1111
10
#TS1222
15
#TS1333
17
2
#TS2444
18
#TS2555
12
#TS2777
14
#TS2888
26
#TS2999
19
Итого, 131 час, что больше запланированных 80, и даже если мы будем работать в выходные, то не хватает 19 часов (131 - 112).
Эти 19 часов могут быть, например, распределены на работу в сверхурочное время: примерно 2 часа 40 минут плюс к нашим

276
Тестирование Дот Ком. Часть 3
восьми часам семь раз в неделю (19 : 7). Кстати, так и поступают во многих стартапах.
Но допустим, что наш www.testshop.rs не относится к этим мно- гим и славится человечным отношением к своим работникам.
Итак, нам, гуманистам, не хватает 51 часа (131- 80) для исполне- ния регрессивного тестирования. Что можно сделать? Среди прочих вещей, таких, как заимствование сотрудников из других отделов, можно сделать следующее: у нас есть приоритет каждого из тест- комплектов. Так давайте же исполним самые приоритетные из них!
Группа
Номер тест-комплекта
Время на исполнение
(в часах)
Приоритет
1
#TS1111 10 1
#TS1222 15 3
#TS1333 17 4
2
#TS2444 18 4
#TS2555 12 2
#TS2777 14 1
#TS2888 26 3
#TS2999 19 2
Если мы исполним тест-комплекты
• только 1-го приоритета, то регрессивное тестирование возь- мет 24 часа (10+ 14);
• только 1-го и 2-го, то — 55 часов (24 + 12 + 19);
• только 1, 2 и 3-го, то — 96 часов (55 + +5 + 26), это нам не подходит.
Итак, мы исполняем тест-комплекты 1-го и 2-го приоритетов.
Оставшиеся 25 часов (80 - 55) можно отдать на исполнение, на- пример:
• спека #1222 (15 часов), либо
• спека #2888 (26 часов), либо
• исполнить наиболее приоритетные тест-кейсы из обоих этих тест-комплектов (самая лучшая идея).
Концепция, думаю, понятна.
Кстати,
определение списка тест-комплектов для регрессивного тестирования —
это, как правило, прерогатива менеджмента.

Исполнение тестирования. Стадия 2: регрессивное тестирование
277
Теперь о третьей группе.
Как правило, большая часть тест-комплектов не входит ни в пер- вую, ни во вторую группы. Но они тоже нуждаются в регрессив- ном тестировании, так как изменение ПО может каким-то обра- зом повлиять и на каждую из них, здесь, как говорится, никто не застрахован. Для того чтобы затронуть все тест-комплекты, для регрессивного тестирования каждого релиза в порядке очереди выделяется по несколько тест-комплектов с расчетом, чтобы все существующие тест-комплекты были исполнены хотя бы один раз в определенный период, например в полгода. При недостат-
ке времени для исполнения тест-комплектов из группы 3 ре-
комендую исполнять лишь самые приоритетные тест-кейсы
каждого тест-комплекта, выбранного для исполнения при регрес- сивном тестировании данного релиза.
Например, если у нас есть 45 тест-комплектов и один релиз в месяц,
то, если исполнять по 15 тест-комплектов каждый релиз, за 3 месяца
можно исполнить их все.
Решение проблемы противоречия
Проблема противоречия между ограниченными ресурсами (напри- мер, время на регрессивное тестирование) и постоянно растущим количеством тест-комплектов решается следующими способами:
а. Приоритезация тест-комплектов и тест-кейсов.
б. Оптимизация тест-комплектов.
в. Наем новых тестировщиков.
г. Автоматизация регрессивного тестирования.
а. О пользе приоритезации мы уже говорили. Странно, но во мно гих компаниях предпочитают изматывать людей, вместо того чтобы приоритезировать тест-комплекты и тест-кейсы и испол нять лишь те из них, которые реально важны.
б. Оптимизация тест-комплектов. Многие старые тест-комплекты могут быть оптимизированы в смысле
• уменьшения количества тест-кейсов и/или
• упрощения исполнения тест-кейсов.
Часто имеет смысл пересмотреть, КАК происходит тестирование в старых тест-комплектах: может быть, некоторые из тест-кейсов уже устарели и/или были написаны тулы для упрощения работы некоторых из них и пр.

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

Исполнение тестирования. Стадия 2: регрессивное тестирование
279
Например, в автоскрипте может быть инструкция о нажатии
кнопки "Вход " на такой-то странице, и если агент, исполняющий
автоскрипт, не "видит" кнопки с именно таким названием, то
генерируется ошибка и исполнение тест-кейса прерывается.
Г-н Говорков, говорит "фигня вопрос ", тратит на починку скрип-
тов пару недель и в последний день регрессивного тестирования
его автоскрипты все-таки исполняют пару из 10 автоматизи-
рованных им тест-комплектов. В следующий релиз все повторя-
ется заново, и в итоге менеджер решает уволить г-на Говоркова
и взять на его место обыкновенного черноящичного тестиров-
щика будет дешевле и эффективнее.
Я ничуть не утрирую. Подобные ситуации происходят в боль-
шинстве случаев после принятия компанией решения об автома- тизации регрессивного тестирования.
Почему так происходит?
Автоматизация регрессивного тестирования заключается в соз-
дании целой тестировочной инфраструктуры с библиотеками
кода, базами данных, системами отчетности и прочими вещами.
Создание такой инфраструктуры — дело очень и очень непростое.
Иногда менеджмент, желая получить результат быстро и любой це- ной, давит на спеца по автоматизации, и даже если последний добро- совестно создает инфраструктуру для автоматизации, то он это дело бросает и абы как автоматизирует максимальное количество тест- комплектов, для того чтобы менеджмент мог отчитаться перед выше- стоящим менеджментом: "За первый квартач 2005 года было авто-
матизировано 12 тест-комплектов, содержащих 174 тест-кейса".
Конечно, все эти автоскрипты не будут вскоре функционировать без трудоемкой поддержки, но кого это волнует? Начальство до- вольно, и, значит, все "Хоккей".
Но допустим, что менеджмент все понимает и дает карт-бланш на создание Инфраструктуры с большой буквы "Ай".
ПО это живое существо. Оно постоянно меняется, и авто-
матизация, связанная с ПО, должна соответственно меняться
одновременно с ним. Таким образом, только поддержание (main-
tenance) существующих автоскриптов — задача, требующая боль- ших профессиональных усилий, не говоря уже о написании но- вых автоскриптов.

280
Тестирование Дот Ком. Часть 3
Я предлагаю очень простой подход к определению эффективно- сти автоматизированного регрессивного тестирования. Посмот- рите, сколько багов было найдено при автоматизированном тес- тировании за все время использования автоскриптов, разделите общие затраты на автоматизацию на количество багов — резуль- татом будет стоимость нахождения одного бага. Сделайте то же вычисление для того же отрезка времени, но для ручного тести- рования и сравните. В 90% случаев стоимость бага, найденного автоскриптом, будет в несколько раз превышать стоимость бага, найденного вручную. И очень большой шанс, что вы подумаете: а зачем вообще нужна ТАКАЯ автоматизация?..
Кстати,
так всегда получается, что в процессе автоматизирования находят
больше багов, чем при исполнении автоматизации.
Советую также сравнить время, потраченное на автоматизацию
(и ее поддержку) для некого тест-комплекта, с временем на исполне- ние этого же тест-комплекта вручную. Гарантирую, что результаты удивят, в смысле неприятно удивят, и не в пользу автоматизации.
Таким образом, наиважнейшее значение приобретает профессио- нализм специалиста по автоматизации.
Профессионализм такого спеца заключается не только в его про- граммистских навыках, но и в том, как четко он представляет:
• ЧТО автоматизировать и
• КАК автоматизировать.
ЧТО:
Лучший кандидат для автоматизации — это тест-кейс для тести- рования старой, устоявшейся фича. Автоматизируя его, мы, по крайней мере, можем быть уверены, что автоскрипт не нужно будет переписывать из-за изменения фича и соответственно из- менения тест-кейса к ней.
Нет более бессмысленной идеи, чем автоматизировать регрес- сивное тестирование для фича, которые только что были выпу- щены на машину для пользователей.
Один мой друг сравнивает фича с человеком: если это ребенок, то он постоянно меняется; если же он взрослый, то изменений в нем намного меньше и сами изменения менее радикальны — сравните

Исполнение тестирования. Стадия 2: регрессивное тестирование
281 того же ребенка, когда ему 6 и 12 лет; и теперь взрослого, когда ему 42 и 48 лет. Идея, я думаю, понятна.
Чем меньше будет изменений в фича, тестирование которой ав- томатизировано, тем меньше времени будет затрачено на под- держку. Поддержка же порой превращается в кошмар
• с чередой красноглазых бессонных ночей перед монитором,
• с горьким пониманием того, что все было сделано непра- вильно, и
• со сладостным искушением все бросить и поехать с Лелей в Ялту.
КАК:
Это создание инфраструктуры, позволяющей с легкостью и про-
стотой
• поддерживать существующие автоскрипты;
• создавать новые автоскрипты.
Инфраструктура автоматизации регрессивного тестирования должна
• с одной стороны, быть образцом программистского мас-
терства;
• с другой — воплощать наиболее эффективные подходы
к автоматизации, возможные при данном ПО для автома- тизации (например, силк-тесте);
• с третьей — учитывать нюансы технологий именно этой интернет-компании.
В заключение нашего краткого разговора об автоматизации рег- рессивного тестирования я хочу открыть вам одну истину:
Суровая правда жизни заключается в том, что 100%-я авто-
матизация регрессивного тестирования сколько-нибудь серь-
езного веб-проекта это миф.
Интернет-компании выбрасывают сотни тысяч долларов, чтобы убедиться, что это миф.
Если ваша компания решила заняться автоматизацией рег-
рессивного тестирования, нужно потратить столько времени,
сколько нужно, чтобы найти настоящего профессионала, а
найдя его, дать ему дышать и не ожидать, что 100% тест-ком-
плектов когда-либо будут автоматизированы.
Это все о решении основной проблемы регрессивного тестирования.

282
Тестирование Дот Ком. Часть 3
Хорошая идея — это предусмотреть окончание регрессивного тестирования за 2—3 дня до релиза:
с одной стороны, у нас будет в запасе 2—3 дня, которые мы можем использовать для завершения регрессивного тести- рования, если наша оценка того, сколько дней оно займет, была неверна.
с другой — эти 2—3 дня можно потратить на тест-сдачи, распределив между тестировщиками части ПО.
А дальше идет релиз...
Краткое подведение итогов
1. Тест-смета необходима для приведения к одному знаменателю потребностей компании и возможностей тестировщиков.
2. Каждый этап тестирования начинается/заканчивается при на- ступлении условия начала/завершения.
3. Тест-план — это документ, обобщающий и координирующий тестирование.
4. Приоритезация тест-комплектов и тест-кейсов имеет наиважней- шее значение, так как в условиях постоянного дефицита ресурсов у нас, как правило, есть время только на проверку главного.
5. Из всех способов решения проблемы асинхронизации ресурсов и объема регрессивного тестирования наем новых людей самый простой и недалекий.
6. Лучше хороший черноящичный тестировщик, чем один или боль- ше плохих инженеров по автоматизации регрессивного тести- рования.
Вопросы и задания для самопроверки
1. Какие факторы стоит принять в расчет при создании тест-сметы?
2. Приведите пример условия начала и условия завершения для исполнения тестирования.
3. Каково концептуальное отличие тест-плана от тест-кейса и тест- комплекта?
4. На основании чего мы выбираем тест-комплекты первой группы?
Почему?
5. На основании чего мы выбираем тест-комплекты второй группы?
Почему?
6. Что, на ваш взгляд, более приоритетно: тест-комплекты первой или второй группы?
7. Какие последствия для компании влечет неграмотная автомати- зация регрессивного тестирования?

1   ...   16   17   18   19   20   21   22   23   24


написать администратору сайта