Часть 3.3

ИСПОЛНЕНИЕТЕСТИРОВАНИЯ.

СТАДИЯ 1: ТЕСТИРОВАНИЕ НОВЫХ ФИЧА

Хотя при разговоре о процессе разработки ПО мы перевели "New Feature Testing" как "Тестирование новых компонентов", я предлагаю немедленно заменить "компонентов" на "фича", так как это более точный перевод и мы уже знаем, что такое фича. Исполнение тестирования состоит из двух стадий, идущих в следующей очередности:

1. Тестирование новых фича (new feature testing);

После того как код проинтегрирован, тест приемки пройден и код заморожен, мы начинаем тестирование новых фича.

Вопрос: Как мы тестируем новые фича?

Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем их. Попутно заносим баги. Спорим с программистами о приоритетах этих багов. Закрываем эти баги. Одним словом, обычная суета сует.

2. Регрессивное тестирование (regression testing).

Test Estimation (тест-смета)

Как правило, в интернет-компаниях существует расписание релизов. К этому расписанию привязано расписание тестирования (QA Schedule), которое определяет сроки каждой стадии процесса тестирования.

Тестировщик готовит тест-смету (Test Estimation), которая включает:

• предварительную оценку времени, необходимого на подготовку к тестированию;

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

Вот факторы, которые я рекомендую принять во внимание при составлении сметы:

• предполагаемая сложность новых фича. Чем они сложнее, тем больше нюансов всплывет при подготовке и исполнении и тем больше времени понадобится на тестирование;

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

• опыт работы на прошлых проектах с теми же продюсе ром и программистом. Например, одни программисты пишут удивительно чистый код, всегда проводят юнит-тестирование и с охотой кооперируются с тестировщиками. Другие же бросают куски кода в проект, как грязь на стену, считают юнит-тестирование вещью, не подобающей для компьютерного гения, и не склонны кооперироваться ни с кем, кроме виртуальных солдат игры Halo. Следовательно, во втором случае мы должны заложить больше времени на наше тестирование;

• будет ли интеграция нашего ПО с ПО наших бизнес-партнеров — вендоров (vendor), например интеграция с ПО платежной системы. Тест-конфигурация выглядит так: наша тест-машина "разговаривает" с их тест-машиной. Соответственно если что-то не в порядке с их тест-машиной, то проблема решается сложнее, чем при локальном тестировании, когда вы заносите баг и наш программист его ремонтирует. В случае с их тест-машиной

• тестировщик связывается с менеджером проекта (с нашей стороны);

• последний должен позвонить вендору;

• человек со стороны вендора должен найти ответственного программиста;

• ответственный программист может быть занят

• и т.д. и т.п.

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

• нужны ли тулы для автоматизации тест-кейсов? Тест-тулы, как правило, создаются во время написания тест- кейсов как средство для облегчения исполнения тест-кейса, например:

• генерация данных (например, генерация номера тестировочной кредитной карты),

• автоматизация всех либо части шагов,

• помощь в сравнении фактического и ожидаемого результатов. В одних случаях тестировщик может сам написать такой тул, например, на языках Java или Python. В других случаях написание тула в помощь тестировщикам — это дело программиста.

Entry/Exit Criteria (критерий начала/завершения)

Все очень просто.

Entry Criteria (условие старта) — это условие для начала чего-либо.

Exit Criteria (условие завершения) — это условие для завершения чего-либо.

TestPlan (тест-план)

• тест-кейс нужен для сравнения фактического результата с ожидаемым результатом;

• тест-комплект — это логическая оболочка для хранения тест-кейсов;

• тест-план — это документ, обобщающий и координирующий тестирование.

ЭЛЕМЕНТЫ ТЕСТ-ПЛАНА

1. Название тест-плана, имя автора и номер версии. Например «Тест-план проекта "Новые алгоритмы для поиска"». Автор Т. Черемушкин. Версия 2.

2. Оглавление с разделами тест-плана: Например Введение стр. 2 Документация с требованиями к ПО стр. 3 и т. д. 3. Введение, в котором мы приводим информацию о сути и истории тестируемого проекта.

4. Документация с требованиями к ПО — здесь мы перечисляем имена, номера и приоритеты спеков и/или другой документации, определяющей тестируемые фича.

5. Фича, которые будут тестироваться, перечисляем и, если нужно, комментируем. Каждой фича назначается приоритет.

6. Фича, которые НЕ будут тестироваться, перечисляем и объясняем, почему НЕ будут тестироваться. Например, частью спека #9172 "Улучшение безопасности платежных транзакций" являются требования к скорости работы веб-сайта (performance). До- пустим, у нас нет ни специалиста, ни ПО для тестирования скорости работы, и если мы не собираемся их нанять и приобрести, то указываем, что перформанс тестироваться не будет, так как нет ресурсов.

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

8. Тест-документация — перечисление тест-документации, которая должна быть создана для данного проекта Например "Тест-комплект по тестированию cпека #1288. Тест-комплект по тестированию спека #3411".

9. Тест-тулы — функциональности тест-тулов, которые должны быть созданы для тестирования проекта.

10. Критерий начала/завершения — те самые критерии, о кото рых мы говорили минуту назад:

• критерий начала подготовки к тестированию;

• критерий завершения подготовки к тестированию;

• критерий начала исполнения тестирования;

• критерий завершения исполнения тестирования.

11. Допущения — список допущений, которые мы сделали при составлении данного тест-плана и которые сделаем при тестировании. Например, мы допускаем (предполагаем), что код будет заморожен в срок, без задержки.

12. Зависимости — список вещей (с пояснениями), от которых зависит та или иная часть тестирования. Например, покупка новых тест-машин, лицензия на осуществление платежных операций на территории Великобритании.

13. "Железо" и ПО — список и конфигурации "железа" и ПО, которые будут использоваться при тестировании.

14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/ продолжено. Например, к условию приостановки можно отнести количество П1 багов, при котором (и/или после которого), по мнению автора (-ров) тест-плана, дальнейшее продолжение тестирования не имеет смысла (например, 7 П1). Соответственно условием возобновления должно быть количество оставшихся П1 багов (после ремонта и регрессивного тестирования), которое позволяет возобновить тестирование (например, 2 П1).

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

16. Тренинг — тренинг, необходимый для данного проекта. Например, при соответствующей ситуации нужно указать, что для создания тест-кейсов тестировщику необходимо прослушать семинар "Банковская система США".

17. Расписание — сроки, имеющие отношение к тестированию данного проекта:

• дата замораживания спеков;

• дата начала подготовки к тестированию;

• дата завершения подготовки к тестированию;

• дата интеграции и замораживания кода;

• дата начала тестирования новых фича;

• дата завершения тестирования новых фича;

• дата начала регрессивного тестирования;

• дата завершения регрессивного тестирования.

18. Оценка риска — предположение о том, как и что может пойти по неправильному пути и что мы в этом случае предпримем. Например, если мы не успеваем закончить тестирование (не выполняем требовfние "Условия завершения", например, "все тест-кейсы исполнены") в срок, то придется задерживаться на работе и приходить в офис в выходные и праздники. Кстати, если народ приходит в выходные и праздники, то компания должна, по крайней мере, кормить его обедом.

19. Прочие положения — вещи, не вошедшие в тест-план, о которых неплохо было бы упомянуть.

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

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.

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

Регрессивное тестирование как второй этап исполнения тестирования — это проверка того, что изменения, сделанные в ПО (для того, чтобы мир увидел новые фича), не поломали старые фича.

Итак, две темы:

1. Выбор тест-комплектов для регрессивного тестирования.

• к какой части ПО принадлежат новые фича (например, фича из спека #5419 "Новые функциональности для Корзины" принадлежат к "Корзине") и

• какие старые фича напрямую зависят от части ПО с новыми фича (например, компонент "Оплата" использует данные (по ценам книг), которые передаются ей компонентом "Корзины").

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

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

Теперь о третьей группе. Как правило, большая часть тест-комплектов не входит ни в первую, ни во вторую группы. Но они тоже нуждаются в регрессивном тестировании, так как изменение ПО может каким-то образом повлиять и на каждую из них, здесь, как говорится, никто не застрахован. Для того чтобы затронуть все тест-комплекты, для регрессивного тестирования каждого релиза в порядке очереди выделяется по несколько тест-комплектов с расчетом, чтобы все существующие тест-комплекты были исполнены хотя бы один раз в определенный период, например в полгода. При недостатке времени для исполнения тест-комплектов из группы 3 рекомендую исполнять лишь самые приоритетные тест-кейсы каждого тест-комплекта, выбранного для исполнения при регрессивном тестировании данного релиза. Например, если у нас есть 45 тест-комплектов и один релиз в месяц, то, если исполнять по 15 тест-комплектов каждый релиз, за 3 месяца можно исполнить их все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#тестирование