Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
Кстати, хорошая традиция — это устроить в конце подготовки к тести- рованию (или начале исполнения тестирования) совещание, на кото- ром каждый тестировщик, у которого есть новая фича, сделал бы ее короткую, например на две минуты, презентацию. Таким образом мы быстро и эффективно распространяем информацию о новых фича, так, чтобы все были в курсе. Вопрос: Как мы тестируем новые фича? Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем их. Попутно заносим баги. Спорим с программистами о приори- тетах этих багов. Закрываем эти баги. Одним словом, обычная суета сует. Это в общем-то все насчет стадии 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. Какие последствия для компании влечет неграмотная автомати- зация регрессивного тестирования? |