Роман Савин, книга, "Тестирование дот ком"

От себя

Моё мнение о книге не поменялось. Можете найти по тэгам. Это укороченное содержание книги. Плюс я изменил структуру, сделал, на мой взгляд, более последовательной.

Часть 1

Что такое баг

Цель тестирования

Тестирование и QA (Quality Assurance)

Цикл разработки ПО

Часть 2

Цикл тестирования ПО

Классификация видов тестирования

Часть 3. Тест-дизайн

Искусство создания тест-кейсов

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

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

Test Plan (тест-план)

Часть 4

Подготовка к тестированию

Исполнение тестирования

Часть 5

Навыки и знания тестировщика

Введение

Вопрос дня: Что самое главное в нашем деле?
Ответ дня: РЕЗУЛЬТАТ!
В вашей работе тестировщика есть единственный смысл — РЕЗУЛЬТАТ.
Результатом работы тестировщика является счастье конечного пользователя. Причем "счастье" не в глобальном его значении, а та его часть, которая связана с качеством вашего продукта.

Часть 1

• Что такое баг
• Цель тестирования
• Тестирование и QA (Quality Assurance)
• Цикл разработки ПО

Что такое баг

Определение бага

Баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

Три условия жизни и процветания бага

Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:

1. Известен фактический результат;
2. Известен ожидаемый результат;
3. Известно, что результат из пункта 1 не равен результату из пункта 2.

Что такое тестирование

Любое тестирование — это поиск багов.

Источники ожидаемого результата

Основными источниками ожидаемого результата являются:

1. Спецификация.
2. Спецификация.
3. Спецификация.
4. Спецификация.
5. Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.

Спецификация (или spec — читается "спек") — это детальное описание того, как должно работать ПО.

В большинстве случаев баг — это отклонение от спецификации.

В самом спеке тоже могут быть баги.

Цель тестирования

Цель тестирования — это нахождение багов до того, как их найдут пользователи.

Концепции: 

1. 100%-е тестирование ПО невозможно.
2. Эффективность тестирования не оценивается количеством найденных багов.

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

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

Пример (и постановка мозгов)

Допустим, что у нас постоянно возникают проблемы с "Оплатой". После каждого из релизов в ней находят по несколько П1 и П2, т.е. появился устойчивый паттерн (pattern — шаблон, тенденция) проблемы. Все спеки по оплате составлены продюсером, весь проблемный код написан программистом и проверен тестировщиком. Первое, что приходит в голову, — во всем виноват тестировщик. Но если проявить человеколюбие и талант руководителя, то может всплыть:

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

Дальнейшее расследование показывает, что

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

А вы говорите "Элементарно, Ватсон"! Вот оно, истинное расследование! А то обидели бы бедного тестировщика, а в следующий раз все повторилось бы.

Заметьте, что ко всему этому мы пришли, начав с анализа статистики, а это уже не тестирование, a QA (Quality Assurance — буквально "обеспечение качества", произносится "кью-эй").

Тестирование и QA (Quality Assurance)

QA — это забота о качестве в виде превентирования появления багов. 

Тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи.

Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что:

• QA призвано улучшить ПО через улучшение процесса разработки ПО;
• тестирование — через обнаружение багов.

Тестировщики имеют дело с ПО, переданным им программистами уже в кривом и порочном состоянии.

Качество (как и его отсутствие) — это результат:

• деяний всех участников процесса разработки ПО,
• отлаженности и настроек самого процесса.

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

Цикл разработки ПО

Цикл (процесс) разработки ПО (software development life cycle) — это путь от идеи до поддержки готового продукта.

1. Идея.
2. Разработка дизайна продукта и создание документации.
3. Кодирование (в смысле создание кода).
4. Исполнение тестирования и ремонт багов.
5. Релиз.

Как правило, идеи компонуются в MRD ("эм-ар-ди" — Marketing Requirements Document — документ о требованиях маркетинга, суть которого: "хотелось бы это иметь").

Затем:

• менеджмент проворачивает MRDШКИ через жернова анализа, утверждения и приоритезации, а
• выжившие идеи передаются продюсерам, которые их полоскают, высушивают и гладят, чтобы получилась спецификация.

На основании идеи, утвержденной менеджментом, разрабатывается и документируется ее воплощение, которое называется дизайном продукта (product design) или, простыми словами, то, как та или иная часть нашего веб-сайта должна выглядеть и/или работать.

Концептуальная разница между идеей (продукта) и дизайном (продукта) заключается в том, что

• идея — это описание ЦЕЛИ
• дизайн — это описание ПУТИ к достижению этой цели.

Профессионально весь этот джаз осуществляется менеджерами продукта (PMs — Product Managers), которые также могут называться продюсерами (Producers) или дизайнерами продукта (Product Designer).

Результатом продюсерских усилий являются спеки, называемые также PRD (Product Requirements Document — документ о требованиях для продукта) или просто requirements (требования).

Спеки должны иметь уникальное название и уникальный ID и внутри разбиваются на логические составляющие (части, пункты), имеющие индексацию для удобства ссылок.

Каждый спек имеет также обозначение своей важности (приоритета). 

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

Хороший спек, как и хороший закон, отличают следующие вещи:

1. Акцент на деталях и их четкое определение.
2. Забота о недопущении неверного толкования.
3. Непротиворечивость внутри спека и с другими спеками.
4. Логическая взаимосвязь компонентов.
5. Полнота охвата предмета.
6. Соответствие нормативным актам.
7. Соответствие деловой практике.

Спеки имеют следующую очередность статусов:

1. Во время написания они имеют статус Черновик (Draft). Продюсер пишет спек.
2. После написания и до утверждения — Ожидание утверждения (Approval Pending). Спек написан, и назначается совещание (meeting) с программистами и тестировщиками по его обсуждению или же просто им посылается е-мейл с приложением.Цикл разработки ПО 77
3. После утверждения — Утверждено (Approved или Final). Если на митинге все закричали "Ура!" или получены положительные отзывы от всех реципиентов, утвержденный спек немедленно выкладывается на один из серверов в локальной сети, чтобы быть доступным любому лицу внутри компании, которому положено его видеть. Если же спек не принят, то все начинается с пункта 1.

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

Процессуально все можно сделать так:

1. К определенной дате все спеки должны быть утверждены. Неутвержденный спек не кодируется, и точка.
2. Директория со всеми утвержденными спеками закрывается, и никто ничего не может изменить в этой директории......если только не будет следовать процедуре изменения спека.

Кстати, техническую сторону, связанную с заморозкой спеков (spec freeze), обеспечивают инженеры по релизу.

Причина неверного толкования спека может быть связана

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

Тезис

Тестировщики должны настаивать, чтобы спеки по максимуму иллюстрировались:

• макетами (mock-up),
• блок-схемами (flow chart),
• примерами (example).

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

Интерфейс — это то, ЧТО видит пользователь, а алгоритм — это то, ПОЧЕМУ пользователь видит то, что он видит.

Для графической презентации алгоритмов используются блок-схемы.

Кстати, блок-схемы могут создаваться как продюсером, так и тестировщиком, но независимо от составителя, как правило, прекрасной идеей является включение блок-схемы в секцию тест-комплекта GLOBAL SETUP and ADDITIONAL INFO.

Блок-схемы, макеты и примеры (вместе именуемые БМП) помогают превентировать появление багов или найти баги на уровне спека следующими путями:

• БМП — это описание предмета с разных сторон, что ведет к его адекватному толкованию разными людьми;
• создание БМП — это процесс переосмысления написанного, что ведет к нахождению багов в написанном, т.е. в спеке;
• макеты и блок-схемы наглядны и во многих случаях позволяют в буквальном смысле увидеть баги в отличие от ситуации, когда есть только текст.

Еще раз: тестировщики должны настаивать, чтобы спеки по максимуму иллюстрировались макетами (mock-up), блок-схемами (flow chart) и примерами (example).

Постановка мозгов

При обнаружении противоречий внутри спека (а БМП — это части спека!) нужно сделать рапорт о баге против продюсера, чтобы тот настроил в унисон несогласующиеся части.

Постановка мозгов

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

Следующий этап цикла разработки ПО — это кодирование, осуществляемое программистами (в то время как тестировщики планируют проверку пишущегося кода).

Кодирование

Работа программиста заключается в том, чтобы перевести вещи, отраженные в спецификации (или словах босса), на язык программирования.

Перевод осуществляется

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

К документам о внутреннем дизайне кода относятся, например,

• документ о дизайне /архитектуре системы (System /Architecture Design Document);
• документ о дизайне кода (Code Design Document).

Причинами возникновения багов в коде являются как возможность программиста полдня бродить по Интернету, так и другие объективные вещи:

1. Некачественные и/или изменяющиеся спецификации
2. Личностные качества программиста
3. Отсутствие опыта
4. Пренебрежение стандартами кодирования
5. Сложность системы
6. Баги в ПО третьих лиц (в операционных системах; в компайлерах (compiler — ПО для переведения (например, C++) кода в машинный язык и создания исполняемых файлов); в веб-серверах; в базах данных и др.)
7. Отсутствие юнит-тестирования, т.е. тестирования кода самим программистом.
8. Нереально короткие сроки для разработки

Исполнение тестирования и ремонт багов

После того как проинтегрирован код, тестировщики проводят тест приемки (smoke test, sanity test или confidence test), в процессе которого проверяются основные функциональности.

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

Если же тест приемки пройден, то код замораживается и тестировщики начинают тестирование новых компонентов (new feature testing), т.е. исполнение своих тест-кейсов, написанных по спекам данного релиза

После того как новые функциональности протестированы, наступает очередь исполнения "старых" тест-кейсов. Этот процесс называется регрессивным тестированием (regression testing), которое проводится для того, чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают.

Баги заносятся в систему трэкинга багов (Bug Tracking System, далее — СТБ), программисты их ремонтируют, и затем тестировщики проверяют, насколько качественным был ремонт.

Допустим, мы все, что хотели и как смогли, протестировали. Программисты залатали дыры в коде, что мы тоже протестировали, и у нас есть версия нашего проекта, готовая для релиза. Эту версию мы мурыжим еще пару деньков, проводя тест сдачи (Acceptance or Certification Test), и включаем зеленый свет релиз-инженерам, чтобы они передали плод наших терзаний кликам (от англ. click) пользователей.

Релиз

Release (англ.) — "выпуск, освобождение".

классификация "релизообразных":

1. Релиз (он же основной релиз) (major release) — стадия в цикле разработки ПО, идущая за стадией тестирование и ремонт багов, т.е. передача пользователям кода новой версии нашего ПО. Как правило, обозначается целыми числами, например 7.0.
2. Дополнительный релиз (minor release) — ситуация, когда после основного релиза планово выпускается новая функциональность или изменяется/удаляется старая. Дополнительный релиз не связан с багами. Как правило, обозначается десятыми, например 7.1.
3. Заплаточный релиз (patch release), когда после обнаружения и ремонта бага выпускается исправленный код. Как правило, обозначается сотыми, например 7.11.

Система управления версиями (СУВ)

Без неё:

1. При каждом сохранении файла в той же директории нужно давать ему новое имя, чтобы не удалить старый вариант редакции.
2. При сохранении файла после редактирования нельзя прокомментировать, что было изменено.
3. Самое главное: постоянно присутствует риск, что один из программистов удалит свою работу или работу коллеги.

Система управления версиями устанавливается на тест-машину и это дает следующее:

Файлы хранятся в репозитории (repository),

        ОТКУДА

        их можно взять для редактирования (checkout) и

        КУДА

        их можно положить после редактирования (checkin).

При этом

• каждый раз, когда мы кладем файл в репозитории,
• не нужно менять имени файла;
• мы можем комментировать, что было изменено в этом файле;
• СУВ автоматически присваивает файлу номер редакции (версии), уникальный для этого файла;
• СУВ связывает номер версии файла, комментарий к изменениям, имя изменившего и время изменения в одну запись (при желании можно увидеть всю историческую последовательность записей);
• если кто-то взял из репозитория файл, то другой не может его оттуда взять, пока первый не положит его обратно.

Поставив систему управления версиями:

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

Чтобы этот код стал доступным на веб-сайте для тестирования, нужно, чтобы файлы из СУВ были интегрированы и отправлены по назначению в соответствующие директории тест-машины и чтобы у нас было отражение содержимого СУВ:

• по состоянию на данный момент 
• и
• для данного релиза

Каждое такое отражение кода веб-сайта называется билдом (build). Иными словами, билд — это версия версии ПО. Билды делаются или вручную, или путем запуска билд-скриптов (build script), т.е. программ, написанных релиз-инженерами для автоматизации процесса. 

Цель создания новых билдов заключается в том, чтобы измененный код (сохраненный в системе управления версиями) стал доступным для тестировщиков:

1. После того как программист починил баг, найденный при тестировании, он тестирует починку на своем плэйграунде, после чего делает checkin отремонтированного кода в СУВ.
2. Отремонтированный код становится частью нового билда.
3. Новый билд замещает (replace) на тест-машине код предыдущего билда.

Итак, перед проверкой починки бага убедитесь не только в том, что вы тестируете нужную версию, но и в том, что тестируете нужный билд. Номер билда, содержащего отремонтированный код, включается программистом в запись о баге в СТБ.

Первый релиз происходит так:

1. Подготовка машины у хостинг-провайдера (production server, просто production или live machine — машина для пользователей).
2. Подготовка релиз-скрипта (release script) — программы, которая автоматизирует процесс релиза на машину для пользователей.
3. Исполнение релиз-скрипта:
1. релиз-скрипт запускает билд-скрипт, чтобы на тест-маши не создался новый билд;
2. релиз-скрипт берет файлы этого нового билда и по протоколу FTP ("эф-ти-пи" — File Transfer Protocol) пересылает их в машину для пользователей;
3. релиз-скрипт:
1. копирует из СУВ на машину для пользователя скрипты для базы данных (DB-scripts) и
2. запускает эти скрипты.

Скрипты для базы данных создают или модифицируют схему базы данных.

О создании бранчей (branch — ветвь) в СУВ.

Представьте себе дерево, т.е. ствол, и ветви, растущие из ствола.

Вот как мы должны были поступить с самого начала:

• файлы, созданные вплоть до момента релиза версии 1.0, были основой, т.е. виртуальным стволом (trunk), нашего ПО;
• из этого ствола мы могли создать виртуальную ветвь (или бранч, от англ. branch) под названием "версия 1.0", которая включала бы все файлы версии 1.0 в редакциях (версиях) на момент, когда мы сказали "Стоп " для версии 1.0. Мы говорим "Стоп" после того, как код написан иготов для интеграции и тестирования;
• таким образом, у нас появились бы ствол и одна ветвь;
• программисты, пишущие код для версии 2.0, должны были модифицировать код ствола (на рисунке — пунктиром);

• и когда код версии 2.0 был бы дописан, мы создали бы еще одну ветвь и назвали ее "версия 2.0";
• таким образом, у нас был бы ствол, из которого сначала рос бы бранч версии 1.0 и затем бранч версии 2.0;
• начиная работать над кодом релиза версии 3.0, мы снова работаем со стволом (на рисунке — пунктиром);

• И т.д.

Разберемся, что даст реализация бранчей:

Во-первых, мы всегда сможем вернуться к предыдущей версии, если новая версия окажется некачественной.

Во-вторых, программисты

• смогут работать одновременно над различными версиями, например ремонтировать баги для 2.0 (бранч 2.0) и писать код для 3.0 (ствол) 
• и
• результаты их работы над каждой из версий будут в СУВ отделены друг от друга.

В-третьих, мы сможем руководить состоянием бранчей.

У бранча есть три состояния:

1. Открытый, т.е. в нем можно сохранять файлы;
2. Условно открытый, в нем можно сохранять файлы, НО при определенном условии, например, программист должен написать номер реального бага в комментарии при сохранении файла; 
3. Закрытый. В этом случае файл может быть сохранен в соответствии с процедурой о неотложном ремонте багов (о процедуре через минуту).

Кстати, когда мы говорили о замораживании спеков, используя СУВ, нужно понимать, что бранчи, в которых сохраняются спеки, не имеют никакой связи с бранчами, в которых сохраняется код. Как правило, это даже две СУВ, установленные на двух разных машинах.

Кстати, часто возникает ситуация, когда программист сохранил код в бранче для патч-релиза и забыл сохранить исправленный код в стволе, т.е. в коде, из которого будет сделан бранч для следующего релиза. Таким образом, может получиться ситуация, когда баг, патч для которого уже был выпущен на машину для пользователей в предыдущем релизе, вновь появляется в следующем релизе. Чтобы избежать таких казусов, тестировщики придерживаются железного правила: на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности.

Совместим наш цикл разработки ПО с открытостью бранчей.

1. Во время стадии кодирование, например, для версии 3.0 бранч с версией 3.0 является открытым.
2. Во время стадии тестирование и ремонт багов бранч является условно закрытым — никакой код не может сохраняться в таком бранче, за исключением кода с починкой для конкретного бага, при сохранении кода в СУВ программист обязан указать номер открытого бага в СТБ, иначе СУВ не разрешит checkin. Именно такой статус у бранча после заморозки кода и передачи кода тестировщикам.
3. После того как произошел релиз на машину для пользователей и в этом релизе найден баг, у нас есть два варианта:
• если баг некритический (например, отсутствует проверка е-мейла пользователя на два "@"), то его можно отремонтировать в следующем релизе, т.е. мы фиксируем код только в стволе;
• если баг критический (например, невозможно совершить покупку), то нужно отремонтировать его и выпустить патч релиз как можно быстрее. Для такого срочного ремонта нужен формальный документ: процедура о неотложном ремонте багов (Emergency Bug Fix Procedure)

Кстати, не хочу вас путать, но есть одна важная для понимания вещь: иногда нужно незамедлительно изменить код приложения на машине для пользователей, и это изменение не связано с багами. В таком случае тоже заносится запись в СТБ, но с типом "Feature Request" — запрос о новой функциональности (подробнее об этом в разговоре о СТБ), и релиз такого кода регулируется этой же процедурой.

Процедура о неотложном ремонте багов должна содержать:

• приоритет багов, которые подлежат НРБ.
• список лиц, имеющих право инициировать процесс НРБ;
• последовательность действий между лицами, участвующими в НРБ, например:
1. программист, извещенный о проблеме, фиксирует баг;
2. исправление кода заверяется одним из его коллег через рассмотрение кода (code review);
3. релиз-инженер делает билд для регрессивного тестирования;
4. тестировщик производит тестирование;
5. релиз-инженер делает патч-релиз на машину для пользователей;

Бета и альфа

Иногда интернет-компании производят бета-релиз (читается как "бэта") (beta release). Идея бета-релиза заключается в следующем: перед тем как мы сделаем основной "официальный" релиз, т.е. откроем новый код всем пользователям, мы откроем новый код лишь ограниченной группе пользователей, которые нам его и протестируют. Эти пользователи (или "бета-тестировщики" — beta testers) должны являться представителями целевой аудитории (target group), для  удовлетворения потребностей которой и был затеян весь сыр-бор от идеи до поддержки. Бета-тестировщики служат подопытными кроликами, ценность которых заключается в том, что они, являясь типичными пользователями, будут делать с бета-версией веб-сайта те же вещи, что и остальные пользователи после официального релиза, и, следовательно, заранее столкнутся с непойманными (нами) багами, о которых они и сообщат в нашу компанию. Наша интернет-компания отремонтирует эти баги и выпустит официальный релиз, более качественный, чем бета.

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

Альфа-тестированием называется любое тестирование кода ДО передачи его пользователям (включая бета-пользователей).

В завершение завершения разговора о релизе:

Релиз проводится в то время, когда большинство пользователей неактивны. Как правило, это ночь. Во время релиза вывешивается табличка, что, мол, "Производим техническую поддержку, не отчаивайтесь, примерно в 6.00 по Москве все вернется на круги своя. Просим извинить за временные неудобства".

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

• огромное количество пользователей нуждаются в бесперебойной работе нашего веб-сайта;
• наш бизнес делает наибольшие деньги.

Пара важных моментов:

1. Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже в электронном виде) и доступны на интранете.
2. Такие вещи, как утверждение спека, рассмотрение тест-кейсов или инспекция кода, — это не какие-то полицейские мероприятия, призванные подрезать крылышки творческим и свободным личностям. Совершенно наоборот — это средства, позволяющие
• улучшить качество,
• прикрыть спину,
• стать хорошим людям еще лучше.

Оговорка:

В аквариумах интернет-компаний кроме продюсеров, программистов, тестировщиков и начальников обитает еще много других разновидностей не менее полезных особей, таких, как

• веб-дизайнеры;
• системные администраторы и администраторы баз данных;
• народ из службы поддержки и маркетинга;
• бухгалтеры (хлещущие чай);
• спецы по железу (хлещущие пиво) и др.

Мы их всех любим, ценим и, как видите, не забываем. Просто нужно было сделать допустимое упрощение для удобства восприятия нового материала.

Ценная мысль:

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

Эффективное планирование — это одна из важнейших составляющих процесса разработки ПО.

Часть 2

• Цикл тестирования ПО
• Классификация видов тестирования

Цикл тестирования ПО

Цикл тестирования ПО состоит из трех этапов:

1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.

На любом из этапов может быть найден баг (как в ПО, так и в документации), баг должен быть отремонтирован ответственным товарищем (например, программистом или продюсером), и качество ремонта должно быть сертифицировано тестировщиком.

Свяжем цикл тестирования с циклом разработки (не факт что в реальности так оно и будет):

1. Изучение и анализ предмета тестирования начинаются перед утверждением спека (в завершение стадии "Разработка дизайна продукта и создание документации") и продолжаются на стадии "Кодирование".
2. Планирование тестирования происходит на стадии "Кодирование".
3. Исполнение тестирования происходит на стадии "Исполнение тестирования и ремонт багов".

1. Изучение и анализ предмета тестирования
Вопрос: что можно протестировать в интернет-проекте?
Легитимные варианты ответа:

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

Все это правильно, но есть нечто более важное.

Вопрос: для чего пользователи приходят на наш веб-сайт? 

Ответ: для удовлетворения своих потребностей — покупка книг, чтение анекдотов, проверка баланса кредитной карты и т.д. и т.п.

Вопрос: как можно удовлетворить потребности пользователя?

Ответ: нужно придумать (продюсер), написать (программист), протестировать (тестировщик) и передать пользователям (релиз-инженер) средства, которые эти потребности удовлетворят. Этими средствами являются  функциональности интернет-проекта.

Вот формальное определение:

функциональность (functionality, feature) — это средство для решения некой задачи.

Примеры из реальной жизни

Функциональность компьютерных колонок "Volume" решает задачу "Как изменить громкость звука".

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

Функциональность "Принтер"решает задачу"Как распечатать документ".

Примеры из виртуальной жизни

Функциональность "Корзина" решает задачу "Как хранить информацию о товаре, выбранном пользователем".

Функциональность "Добавление товара в корзину" решает задачу "Как добавить товар в корзину". 

Функциональность "Удаление товара из корзины" решает задачу "Как удалить товар из корзины". 

Проверка работы функциональностей называется функциональным тестированием (functional testing).

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

Основными источниками знания о функциональностях служат:

• документация,
• хомо сапиенс, 
• т.е. информация постигается через межличностное общение. Так, в случае возникновения сомнений никогда не мешает подойти к продюсеру, хлопнуть его по плечу и попросить: "Старина, будь добр, объясни мне по-простому пункт 146 вот этого спека". Здоровая дружеская атмосфера в коллективе — это отличное средство для предотвращения ошибок в толковании (идеальной питательной среды для багов);
• сам веб-сайт, который можно изучать посредством эксплоринга. Эксплоринг (exploring (англ.) — "исследование", "разведка") — это изучение того, как работает веб-сайт с точки зрения пользователя.

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

В интернет-компаниях эксплоринг, как правило, применяется в двух случаях:

• когда написан код и отсутствует документация;
• для самообучения.

Конечной целью этапа Изучение и анализ предмета тестирования является получение ответов на два вопроса:

1. Какие функциональности предстоит протестировать?
2. Как эти функциональности работают?

После того как ответы получены, мы переходим к следующему этапу цикла.

2. Планирование тестирования

Эта стадия требует от тестировщика наибольшего творчества и профессионализма, так как именно на ней решается множество головоломок, отвечающих на один простой вопрос: "Как будем тестировать?", причем качество продукта (а значит, и счастье пользователей) напрямую зависит от мудрости найденных решений.

Мудрость найденных решений проявляется в двух вещах:

1. кратких, простых и изящных путях для проверки функциональностей;
2. компромиссе между
• объемом тестирования, который возможен в теории;
• объемом тестирования, который возможен на практике.

Ответы на "один простой вопрос" предстают перед миром в виде тест-документации (test documentation), ядро которой составляют тест-кейсы. Во многих случаях создание тест-документации сопровождается написанием тестировщиком вспомогательных тулов (tool — компьютерная программа), которые облегчают исполнение тестирования.

3. Исполнение тестирования

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

Исполнение функционального тестирования выглядит следующим образом:

• сначала идет проверка новых функциональностей по новым тест-кейсам.
• затем проверка старых функциональностей по старым тест-кейсам.

То же самое, но в профессиональной терминологии:

• тестирование новых функциональностей (new feature testing)
• регрессивное тестирование (regression testing).

Мы исполняем тест-кейсы, рассчитывая найти баги.

Давайте еще раз вспомним:

после нахождения бага тестировщик заносит запись о нем в систему трэкинга багов; 

после того, как программист починил баг, тестировшик проверяет:

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

Тестирование, исполняемое в пунктах 1. и 2., также называется регрессивным тестированием (bug regression testing).

Давайте сделаем небольшое обобщение.

Так как этапы 

1. Изучение и анализ предмета тестирования 

и

2. Планирование тестирования 

переплетены между собой, мы объединим их в контейнер знания, который называется подготовка к тестированию (test preparation или, по простому, test preps).

Итак, большая часть нашего дальнейшего общения будет посвящена двум вещам:

1. Подготовка к тестированию (testpreparation);
2. Исполнение тестирования (test execution).

Краткое подведение итогов

Функциональность — это средство для решения некой задачи.

Проверка работы функциональностей называется функциональным тестированием.

Эксплоринг — это изучение того, как работает веб-сайт с точки зрения пользователя.

Ядро тест-документации составляют наши любимые тест-кейсы.

Вспомогательные программы ("тулы") пишутся для облегчения исполнения

тест-кейсов.

Мы выделили два основных этапа цикла:

1. подготовка к тестированию;
2. исполнение тестирования.

Исполнение тестирования идет в два этапа:

1. тестирование новых функциональностей
2. регрессивное тестирование.

Классификация видов тестирования

1. По знанию внутренностей системы:

• черный ящик (black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).

2. По объекту тестирования:

• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/performance testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).

3. По субъекту тестирования:

• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).

4. По времени проведения тестирования:

• до передачи пользователю — альфа-тестирование (alphatesting);
• тест приемки (smoke test, sanity test или confidence test);
• тестирование новых функциональностей (new feature testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance or certification test);
• после передачи пользователю — бета-тестирование (beta testing).

5. По критерию "позитивности" сценариев:

• позитивное тестирование (positive testing). Позитивные сценарии — это сценарии, предполагающие нормальное, "правильное" использование и/или работу системы.
• негативное тестирование (negative testing).

6. По степени изолированности тестируемых компонентов:

• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or end-to-end testing).

7. По степени автоматизированности тестирования:

• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi automated testing).

8. По степени подготовки к тестированию:

• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).

Часть 3. Тест-дизайн

Искусство создания тест-кейсов

Test case можно перевести как "тестируемая ситуация".

Список тест-кейсов является тест-комплектом (test suite).

Процесс созданием тест-кейса (test case generation).

Процесс исполнения тест-кейса (test case execution).

Главная и неотъемлемая часть тест-кейса — это ожидаемый результат, т.е. тест-кейс может полностью состоять только из ожидаемого результата.

Структура тест-кейса

Чтобы узнать, есть баг или нет, необходимо к ожидаемому результату (ОР) добавить шаги (steps), которые должны привести нас к фактическому результату (ФР). Совокупность шагов называется процедурой (procedure).

Если провести аналогию, то

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

Постановка мозгов

Исходя из основной компьютерной концепции ввод/вывод (на языке оригинала — input/output):

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

Исполнение тест-кейса завершается сравнением вывода фактического и вывода ожидаемого.

Исход исполнения тест-кейса (test case result)

Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух:

Положительный исход (PASS), если ФР равен ОР

или

Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!

Иногда возникает ситуация, когда мы заблокированы (test case execution is blocked), так как не можем пройти все шаги тест-кейса. Например, мы не можем продвинуться дальше, если кнопки "Завершить заказ" из шага 14 не существует на соответствующей веб-странице. В таком случае мы рапортуем баг (в данном случае баг об отсутствии кнопки "Завершить заказ") и откладываем исполнение тест-кейса до устранения бага.

Полезные атрибуты тест-кейса

Уникальный ID (UniqueID)

Приоритет (Test Case Priority)

Описание (Idea)

Подготовительная часть (Setup and Additional info)

История редактирования (Revision History)

Теперь обобщим уже известные нам мероприятия по улучшению

поддерживаемости тест-кейса:

1. Сделать тест-кейс data-driven (управляемые данными).

2. Не описывать шаги по явно очевидным сценариям (например, логин).

3. Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса (например, имя товара).

4. Вынести во внешний документ повторяющиеся сценарии (например, семь шагов оплаты).

5. Два или больше ОР в одном тест-кейсе — это нормальная практика.

Проблемные тест-кейсы

Теперь посмотрим, какие недостатки вы должны выжигать из своих тест-кейсов каленым железом.

1. Зависимость тест-кейсов друг от друга.
2. Нечеткая формулировка шагов.
3. Нечеткая формулировка идеи и/или ожидаемого результата.

Перечисляющиеся в тест-кейсе шаги должны быть объективно четкими и ясными.

Нужно помнить,

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

Краткое подведение итогов

1. Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату (выводу). Излишняя детализация может осложнить поддержку, а излишнее абстрагирование привести к непониманию того, как исполнить тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдельный документ в локальной сети, и в тест-кейсе мы даем лишь ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным (pass), либо отрицательным (fail или баг!!!) результатом. 
5. Исполнение тест-кейса не является завершенным, если исполнитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того же или любого другого тест-комплекта.
7. Атрибуты тест-кейса: 
1. уникальный ID, который уникален в пределах всех существующих в компании тест-кейсов;
2. приоритет (чтобы все знали, кто здесь главный);
3. идея, которая на простом языке объясняет предназначение тест-кейса;
4. подготовительная часть, которая подготавливает нас к исполнению тест-кейса;
5. история редактирования, которая помогает указать на друзей, испортивших наши идеальные тест-кейсы.
8. Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен. Поддерживаемость тест-кейса — одна из основных формальных вещей при создании или модификации тест-кейса.
9. Тест-кейс "проверяет" не более одной идеи. При этом два и более ожидаемых результата легитимны, если истинность идеи вытекает из одновременной истинности этих ожидаемых результатов.
10.  К плохому стилю относятся:
1. зависимость тест-кейсов друг от друга;
2. нечеткая формулировка шагов;
3. нечеткая формулировка идеи тест-кейса и/или ожидаемого результата.
11. Тест-кейсы объединяются в тест-комплекты (как правило, один тест-комплект — это один файл).
12. Как правило, тест-комплект включает тест-кейсы, родственные друг другу тем, что они проверяют определенный участок нашего интернет-проекта или вещи, описанные в определенном спеке.
13. Хорошим стилем является создание нового тест-комплекта для новых тест-кейсов.
14. Тест-кейсы, написанные после проработки спека (до того, как представилась возможность "пощупать" написанное по нему ПО), являются сырыми, и никто не посмеет бросить в тестировщика камень осуждения, если он впоследствии изменит тест-кейсы по мере их исполнения.
15. Создавая или модифицируя тест-кейсы, мы всегда должны помнить о том парне, который будет их исполнять после нас.
16. Состояние тест-кейса: "У них все, как у людей. Рождаются, изменяются и умирают..." — "Новый", "Измененный", "Более недействителен". Хорошая практика — не удалять (remove) отжившие свой век тест-кейсы (или целые тест-комплекты), а переносить их (move) в отдельную директорию, специально созданную для таких пенсионеров.

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

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

"Как правило" было употреблено из-за того, что в некоторых компаниях такого понятия, как "Расписание", не существует в принципе.

Проблема в том, что, как бы ударно мы ни работали, мы можем выполнить лишь определенный объем работы и возникает конфликт между:

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

Чтобы уравновесить желаемое и реальное, используют сметы (estimation).

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

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

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

Итак, как создать тест-смету?

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

Кстати, после того как тест-смета готова, рекомендую увеличить ее на 10%, чтобы учесть такие непредвиденные обстоятельства.

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

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

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

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

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

Кстати, в некоторых компаниях внутри департамента качества существую специальные отделы по созданию тест-тулов.

Вы должны подкорректировать тест-смету в зависимости от вашей оценки того:

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

Итак, при составлении тест-сметы используем вышеперечисленные факторы, слушаем свои опыт и интуицию и советуемся с коллегами.

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

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

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

Каждый из двух этапов тестирования имеет свои условия старта и условия завершения.

Например

Условие старта для подготовки к тестированию: все спеки должны быть заморожены.

Условие завершения подготовки к тестированию: тест-кейсы и прочие подготовительные мероприятия написаны и закончены.

Условие старта для исполнения тестирования: код заморожен.

Условие завершения исполнения тестирования: тестирование новых функциональностей и регрессивное тестирование завершено, нет открытых П1 и П2 багов.

Test Plan (тест-план)

Концептуальная вещь:

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

Элементы тест-плана

1. Название тест-плана, имя автора и номер версии.
2. Оглавление с разделами тест-плана:
3. Введение, в котором мы приводим информацию о сути и истории тестируемого проекта.
4. Документация с требованиями к ПО — здесь мы перечисляем имена, номера и приоритеты спеков и/или другой документации, определяющей тестируемые фича.
5. Фича, которые будут тестироваться, перечисляем и, если нужно, комментируем. Каждой фича назначается приоритет.
6. Фича, которые НЕ будут тестироваться, перечисляем и объясняем, почему НЕ будут тестироваться.
7. Объем тестирования — виды тестирования, которые мы будем проводить, и разъяснения к ним.
8. Тест-документация — перечисление тест-документации, которая должна быть создана для данного проекта.
9. Тест-тулы — функциональности тест-тулов, которые должны быть созданы для тестирования проекта.
10. Критерий начала/завершения — те самые критерии, о которых мы говорили минуту назад:
• критерий начала подготовки к тестированию;
• критерий завершения подготовки к тестированию;
• критерий начала исполнения тестирования;
• критерий завершения исполнения тестирования.
11. Допущения — список допущений, которые мы сделали при составлении данного тест-плана и которые сделаем при тестировании.
12. Зависимости — список вещей (с пояснениями), от которых зависит та или иная часть тестирования.
13. "Железо" и ПО — список и конфигурации "железа" и ПО, которые будут использоваться при тестировании.
14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/продолжено.
15. Ответственные лица — подробный список товарищей (продюсеров, программистов, тестировщиков и пр.), контактная информация и обязанности каждого из них. Такой список может включать лиц со стороны вендора.
16. Тренинг — тренинг, необходимый для данного проекта.
17. Расписание — сроки, имеющие отношение к тестированию данного проекта:
• дата замораживания спеков;
• дата начала подготовки к тестированию;
• дата завершения подготовки к тестированию;
• дата интеграции и замораживания кода;
• дата начала тестирования новых фича;
• дата завершения тестирования новых фича;
• дата начала регрессивного тестирования;
• дата завершения регрессивного тестирования.
18. Оценка риска — предположение о том, как и что может пойти по неправильному пути и что мы в этом случае предпримем.
19. Прочие положения — вещи, не вошедшие в тест-план, о которых неплохо было бы упомянуть.
20. Утверждения — это подписи лиц, которые утвердили тест-план. Чем больше будет таких подписей, тем лучше. По крайней мере, нужны подписи менеджера тестировщика, составившего план, самого тестировщика, продюсера и программиста.
21. Приложения — например, расшифровка терминов и аббревиатур, используемых в тест-плане.
    

Часть 4

• Подготовка к тестированию
• Исполнение тестирования

Подготовка к тестированию

Подготовка к тестированию с точки зрения тестировщика включает:

1. Написание новых тест-кейсов
2. Изменение существующих тест-кейсов

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

Постановка мозгов

Многие вещи, о которых мы будем говорить, могут показаться теоретически простыми, но пусть эта псевдо-простота не вводит вас в заблуждение. 

Приведем аналогию с шахматами. Взрослому человеку нужно 5 минут, чтобы запомнить правила (как ходят/бьют пешки и фигуры, правила рокировки и пр.), а для того чтобы стать мастером игры, нужны сотни сыгранных партий. 

То же самое и с методами тестирования: понять базовые элементы и концепции особого труда не составит. Для того же, чтобы стать эффективным профессионалом, понадобятся месяцы и годы практического применения этих элементов и концепций на реальном ПО.

Для тестировщика подготовка к тестированию — это наиболее сложный, творческий и интересный процесс.

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

Мы — ловцы. И тест-кейсы — это сеть, которую мы:

• плетем (подготовка к тестированию)
• используем (исполнение тестирования)

Ментальный настрой тестировщика

1. Для пользователя код — это инструмент для выполнения каких-либо неотложных задач (например, покупки устройства для подзаводки автоматических часов);
2. Для продюсера — реализация гениальных идей менеджмента, увековеченных в спеке;
3. Для программиста — кусок хлеба с черной икрой;
4. Для тестировщика код — это убежище багов.

Постулат "Software has bugs" ("ПО содержит баги") — это не выдумка лицемеров и лжесвидетелей, а вселенский закон, кормящий тестировщиков.

Раскроем свое сердце истинной сути вещей, заключающейся в том, что ПО своей природе — это баго-содержащее и неблагонадежное существо.

Еще раз:

код — это убежище багов.

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

Еще раз: 

основа работы тестировщика — это поиск багов.

Тестировщик не занимается поиском доказательств того, что ПО работает. 

Мы должны настроить себя на поиск багов в коде, который является убежищем этих самых багов.

Основой такого настроя — ментального настроя тестировщика — является мышление полное подозрительности, недоверия в отношении ПО. Мы должны твердо верить в то, что "был бы код, а баги найдутся".

Методология создания тест-кейсов (testcase design methodology)

(далее — методология)

Методы генерирования тестов:

1. Черновик-чистовик (dirty list-white list).

2. Матричная раскладка (matrices).

Этап 1. Набросок элементов. 

Этап 2. Комбинация элементов.

3. Блок-схемы (flowchart).

Методы отбора тестов:

1. Оценка риска (risk estimate).

Субъективные суждения, основанные на самонадеянном "Абсолютно очевидно", могут элементарно завести нас в ситуацию, когда ресурсы потрачены впустую, так как не учитывают реальности. В то же время выводы, сделанные исходя из достоверной информации, ведут к эффективным решениям даже при нехватке ресурсов.

Оценку риска может сделать только тот, кто:

• владел информацией и
• знал, как этой информацией распорядиться.

Наша задача — это

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

Людьми, которые владеют вопросом, могут быть продюсер, главный бухгалтер, финансовый директор, бизнес-аналитик. Информацию можно получить также из статистики или других источников.

Последний вопрос в отношении оценки риска — это использование полученной информации. Флоу с более высоким приоритетом (который мы отражаем в поле тест-кейса "Приоритет") тестируется

• в первую очередь и
• более тщательно.

2. Эквивалентные классы (equivalent classes).

Эквивалентный класс — это одно или больше значений ввода, к которым ПО применяет одинаковую логику.

Ко всем значениям класса должна применяться одинаковая логика кода.

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

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

Отсев происходит путем применения знаний о тестировании пограничных значений.

3. Пограничные значения (boundary values).

Пограничные значения — это конкретные предельные значения, образующие водораздел между эквивалентными классами.

Для каждого эквивалентного класса может быть лишь один из трех вариантов:

1. Есть только нижний предел.
2. Есть нижний и верхний пределы.
3. Есть только верхний предел.

Пограничным тестированием (boundary testing) называется применение метода тестирования пограничных значений.

Вот полная версия метода тестирования пограничных значений.

1. Сначала тестируется нижний предел данного класса (если он имеется).
2. Затем тестируется верхний предел данного класса (если он имеется).
3. Затем тестируется любое значение внутри данного класса.
4. Затем тестируется верхний предел класса, непосредственно предшествующего данному классу (если предшествую щий класс имеется).
5. Затем тестируется нижний предел класса, непосредствен но следующего за данным классом (если следующий класс имеется)

Политический момент

Как известно, теория и практика - это две разные вещи.

На "практике", если спек более или менее сложный, неизбежно возникнет необходимость в уточнениях.

Знайте, что отвечать на вопросы по спеку — это святая обязанность продюсера.

Вы имеете право, нет, ОБЯЗАНЫ задать ему ВСЕ вопросы по спеку, которые у вас возникнут, ибо шкуру будут спускать с вас, а не с него, если вы из-за неотвеченных вопросов пропустите баги.

Кстати, обязательно сохраняйте всю переписку в отдельном фолдере (папке) е-мейл клиента:

вдруг продюсер дал вам уточнение, оно было неверным, вы написали тест-кейс с ошибкой, не написали тест-кейс вовсе и пропустили серьезный баг?

Нет е-мейла—нет доказательств, есть е-мейл— есть доказательства.

Если уточнение по спеку было сделано устно, пошлите е-мейл продюсеру, где опишите то, как вы поняли уточнение, и спросите "Я правильно понял?".

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

Если ответа снова нет и продюсер не болен, не уехал на ПМЖ в Австралию, а даже очень здоров, и вы видите его в столовой каждый день, то просто перешлите последний из е-мейлов продюсера своему менеджеру и сообщите ему, что не можете работать по спеку.

Менеджер не будет сам говорить с ним, а переправит ваш е-мейл менеджеру продюсеров, чтобы тот спросил у продюсера: "В чем, собственно, дело?" Даю гарантию, через час продюсер сам прилетит к вам, как ни в чем не бывало хлопнет по плечу, как лучшего друга, и проведет с вами столько времени, сколько нужно, травя байки и находя удачные аналогии для того, чтобы вы лучше поняли материал. "Бизнес есть бизнес", вы ищете баги и, чтобы быть эффективным, должны получить всю информацию по спеку.

Важная мысль:

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

Практикуйтесь и помните о примере с шахматами, которым мы поставили себе мозги/

Краткое подведение итогов

1. Хороший тестировщик — это не просто некий работник компании, который может порвать код на части своими прикладными знаниями по тестированию. Хороший тестировщик — это неисправимый циник, нигилист и Фома неверующий — все в отношении кода.
2. Код — это убежище багов.
3. Суть тестирования заключается в поиске багов.
4. В отношении методов генерирования тестов:
• при использовании метода Черновик-чистовик: Черновик - это полет мысли и вдохновения, "мозговой штурм", не ограниченный суетными приличиями бренного света. Чистовик - это подчищенный, причесанный и классифицированный Черновик;
• матричная раскладка может быть лишь простой классификацией элементов, а может и бесконечно углубляться в дебри комбинаций и комбинаций. Главное помнить, что матричная раскладка создается для тестирования, а не тестирование было придумано для матричной раскладки;
• блок-схемы - это дочери добродетели под именем "Наглядность".
5. В отношении методов отбора тестов: оценка риска основывается на том, что мы пытаемся влезть в шкуру наших пользователей и бросить наши ограниченные ресурсы не на бессмысленное кликанье правыми, левыми и даже средними кнопками наших ошалевших мышек, а на тестирование вещей, реально приоритетных для пользователей.
6. Методы генерирования тестов и методы отбора тестов — это ящик с инструментом. Под каждую задачу используется свои инструменты.

Исполнение тестирования

Как мы знаем, цель исполнения тестирования — поиск багов.

Но на самом деле найти баг — это только часть работы. После того как баг обнаружен,

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

Кстати, как мы помним, а и б называются регрессивным тестированием.

Процесс, который начинается с занесения бага в систему трэкинга багов (Bug Tracking System), называется процессом трэкинга багов (Bug Tracking Procedure).

Итак, концептуально СТБ — это инфраструктура, позволяющая:

• создавать,
• хранить,
• просматривать и
• модифицировать информацию о багах.

Атрибуты бага

BUG NUMBER (НОМЕР БАГА)

SUMMARY (КРАТКОЕ ОПИСАНИЕ)

STEPS TO REPRODUCE (ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ)

ATTACHMENT (ПРИЛОЖЕНИЕ)

SUBMITTED BY (АВТОР БАГА)

DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА)

ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА)

COMPONENT (КОМПОНЕНТ)

VERSION FOUND (ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ)

VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ)

PRIORITY (ПРИОРИТЕТ БАГА)

TYPE (ТИП БАГА) (bug (баг), feature request (запрос о фича))

STATUS (СТАТУС)

RESOLUTION (РЕЗОЛЮЦИЯ)

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

В каждой интернет-компании на интранете должна быть страничка "Кто за что ответствен" (Who does What). На этой страничке должны быть перечислены:

• компоненты веб-сайта;

• программисты, которые отвечают за эти компоненты;

• продюсеры, которые отвечают за эти компоненты.

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

Текст (text)

1. Текст может быть неверного содержания (противоречащий спеку): например, неверное сообщение об ошибке.

2. Нужного текста может не быть вовсе.

3. Может быть неправильным шрифт (font), цвет (color), размер (size) текста.

Естественно, что проблемы неверного содержания элемента или полного его отсутствия могут быть не только у текста, но и у всех остальных элементов.

Линк (link)

Ссылка, гиперссылка. Если нажать на линк (или, по-простому, "кликнуть линк") (click link), то мы попадем:

• либо на другую веб-страницу,

• либо на определенное место страницы, на которой находится линк.

Кстати:

1. Линк может быть сломан (broken link), т.е. нажимаем на линк и никуда не идем либо получаем сообщение, что страница не найдена.

2. Линк может вести не туда , куда нужно (misleading link).

Для проверки сломанных линков есть свои инструменты (тулы).

Картинка (image)

Ну, куда же мы без них. Картинки — это графические файлы (как правило, GIF либо JPG), на которые ссылается HTML-код, веб-страницы и которые через Интернет летят на жесткий диск наших компьютеров. Если вы в окне браузера видите картинку, то знайте, что она сохранена на жестком диске.

Кстати:

Сломанная картинка (broken image): ситуация, когда, как правило, путь к графическому файлу в HTML-коде указан неверно или путь указан верно, но сам файл поврежден (corrupted/damaged) и на веб-странице мы видим лишь рамку, в которой должна была быть картинка.

Слинкованная картинка (linked image)

По сути это линк, который представлен не текстом, а картинкой. Соответственно у слинкованной картинки могут быть болезни как линков, так и картинок.

Однострочное текстовое поле (textbox) и Многострочное текстовое поле (text entry area)

Размер текст-бокса (MAXLENGTH), т.е. максимальное количество символов, которое можно ввести в текстовое поле, может быть больше или меньше, чем указано в спецификации.

Проверка количества символов, которое может принять в себя текстовое поле, проводится в рамках тестирования интерфейса пользователя (UlTesting).

Кстати, прекрасным, истинно сероящичным тестом является проверка того, умещается ли наш ввод в соответствующую колонку базы данных. Под вводом в данном случае подразумеваются данные, введенные посредством текст-бокса или многострочного текстового поля.

Пример

При регистрации наш новый пользователь заполняет соответствующую веб-форму и нажимает на кнопку "Зарегистрироваться".

Некий файл (например, написанный на языке Python и живущий на сервере с приложением) трансформирует эту форму в язык, понятный базе данных (язык называется SQL — Structured Query Language), и создает новую строку (record) в таблице, называемой, например, USER ADDRESS (адрес пользователя).

Допустим, что при создании таблицы USER ADDRESS программист ошибочно указал максимальный размер колонки ADDRESS1 в 7 символов (VARCHAR (7)) вместо 37, положенных по спеку. Это приведет к тому, что при создании новой строки в USER ADDRESS данные, включаемые в колонку ADDRESS1, будут ограничены 7 символами, а 8-й и прочие символы будут отсечены (truncated) (кстати, пробел — это тоже символ).

Поле пароля (password field)

Это однострочное поле для ввода текста с тем нюансом, что каждый символ, введенный в это поле, тут же автоматически преобразуется в * (звездочку, или, по-англ. — asterisk) либо в жирную метку (bullet).

В отношении проблем:

размер поля пароля (MAXLENGTH), т.е. максимальное количество символов, которые можно ввести в него, может быть больше или меньше, чем указано в спецификации.

Ниспадающее меню (pull down menu)

Ниспадающее меню дает возможность выбрать одно, и только одно, значение из списка значений меню. Наитипичнейший пример — ниспадающее меню со списком стран на веб-форме регистрации.

Радиокнопка (radio button)

Радиокнопка, также известная под неудобоваримым именем "зависимая кнопка", — это элемент веб-формы, который позволяет выбрать одно, и только одно, значение из списка своих собратьев.

Список называется группой радиокнопок, которая объединена одним названием и/или логичной принадлежностью к группе. Значения радиокнопок взаимоисключаемы, и, таким образом, кнопки взаимосвязаны.

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

Чекбокс (checkbox)

Чекбокс, также известный под неудобоваримым именем "независимая кнопка", — это элемент веб-формы, который позволяет:

установить галочку (check) либо

убрать галочку (uncheck).    

Кнопка (button)

Нажатие на кнопку является заключительным аккордом при заполнении веб-форм. Нажимая на кнопку, мы отправляем веб-форму для обработки на сервер с приложением (application server).

Еще одна мысль

во множестве компаний каждый ваш удар по клавишам клавиатуры (keystroke) невидимо для вас запечатлевается в текстовом файле (log), который является собственностью компании и который, если будет нужно (естественно, не во благо вам), будет поднят вашим менеджером и проанализирован. Впрочем, так же могут быть подняты и проанализированы скриншоты (снимок изображения на экране вашего монитора), которые делаются с определенным интервалом (например, 60 секунд) и также являются собственностью вашего работодателя.   

 

Исполнение тестирования состоит из двух стадий, идущих в следующей очередности:

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

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

Исполнение тестирования. Стадия 1: Тестирование новых фича.

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

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

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

Исполнение тестирования. Стадия 2: Регрессивное тестирование (regression testing).

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

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

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

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

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

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

Третья группа.

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

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

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

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

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

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

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

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

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

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

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

ЧТО:

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

будет переписывать из-за изменения фича и соответственно изменения тест-кейса к ней.

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

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

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

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

КАК:

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

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

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

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

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

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

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

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

была неверна.

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

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

Часть 5.

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

• гигабайты бесплатного ПО, например компайлеры для C++ и интерпретаторы Python;
• тысячи бесплатных курсов по компьютерным дисциплинам, например пособия по изучению языка SOL;
• интернет-форумы на любую тематику, где любой оболтус (включая меня) может задать самый идиотский вопрос и получить на него ответ;
• веб-сайты, бродя по которым мы попутно становимся квалифицированными пользователями Интернета;
• десятки других милых и полезных вещей..

Используйте ресурсы Интернета!!! В нем есть все, что вам нужно, чтобы стать тестировщиком экстра-класса.

Вот список вещей, к которым я предлагаю хотя бы прикоснуться перед поиском первой работы. Потратьте по крайней мере по 10 часов на каждое "прикосновение", причем не просто читайте теорию, а работайте с соответствующим ПО (или на соответствующем ПО),

например:

• в случае с UNIX исполняйте команды, например команду "mkdir", для создания директории или
• пишите код на Python.

1. HTML. Основной язык веб-страниц. Веб-учебник (web tutorial) на английском языке и программа для симуляции может быть найдена здесь: http://www.w3schools.com. Изучите базовые теги (tag).
2. SQL. Язык баз данных. Веб-учебник на английском языке можно найти здесь: http://www.w3schools.com. Изучите отя бы базовые команды и операторы.
3. Python. Веб-учебники на английском языке и установочную программу для интерпретатора можно найти на http://www.python.org. Возьмите самый простой учебник и ощутите всю прелесть простоты и доступности моего любимого языка программирования.
4. UNIX. Вот наипростейший веб-учебник: http://www.math.utah.edu/lab/unix/unix-tutorial.html. Симулятор UNIX для Виндоуз-машин можно скачать здесь: http://www.cygwin.com.
5. C++. Веб-учебник может быть найден здесь: http://www.cplusplus.com/doc/tutorial. Напишите несколько программ, скомпилируйте их, откройте в текстовом редакторе файлы источники (source file), скомпилированные файлы (bytecode file) и ощутите разницу.

Естественно, что мои пояснения о том, ЧТО изучить для каждого из вышеуказанных 5 предметов, — это минимум для того, чтобы иметь элементарное представление, но даже такой минимум — это ваш козырь. Очень рекомендую. То, что сейчас кажется вам сложным и запутанным, будет доступным и понятным завтра. Нужно только иметь терпение и приложить немного усилий.

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

Некоторые из тех, кто начал работать тестировщиком на черноящичном тестировании, распробовали знания из смежных специальностей (например, администрация баз данных) и переместились туда;

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

некоторые продолжают с удовольствием для себя и пользователей заниматься черноящичным тестированием или же перешли к сероящичным или белоящичным делам — к чему лежит душа.

Но чтобы найти в итоге свою нишу, нужно искать, а лучший поиск — это изучение новых вещей.

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