Прошлая часть: Чек-листы и тест-кейсы
И снова здравствуйте.
В прошлой главе мы разобрали что такое тест-кейсы и там упоминалась следующая фраза: «не путайте «тест-кейс» с «тестовым запуском». Тест-кейс не имеет статуса прохождения, запомните это! Тест-кейс – это аналог шаблона на производстве, на основании которого штампуются «изделия». И вот как раз «изделия» могут получиться успешными или неудачными, а шаблон как был шаблоном – так им и остается.». Сегодня мы с этим разберемся подробнее, но, как всегда, пойдем издалека и скомбинируем знания из главы про гибкую методологию разработки ПО и главы про чек-листы и тест-кейсы.
- Вопрос: «Зачем команда разработки что-то разрабатывает на протяжении какого-то спринта?»
- Ответ: «Чтобы бизнес, который платит команде заработную плату, смог заработать больше денег»
- Вопрос: «А за счет чего бизнес зарабатывает деньги?»
- Ответ: «За счет предоставления пользователям программного обеспечения, которое решает проблемы пользователей, и пользователи готовы за это явно/неявно платить»
- Вопрос: «А как бизнесу заработать еще больше денег?»
- Ответ: «Дать пользователям новую версию программного обеспечения, которая решает еще больше проблем, чем предыдущая версия, а значит пользователи более охотно за нее платят».
Что такое релиз?
Вот так, не особо изящно, но надеюсь понятно мы подошли к понятию «релиз». По определению релиз (от английского «release» – «выпускать») – это выпуск окончательной, готовой для использования версии программы.
Если более развернуто, то релиз это выпуск окончательной версии продукта или обновления для него. Он обычно включает в себя все исправления, новые функции и улучшения (как для пользователей, так и для самой команды разработки), которые были разработаны и протестированы за определенный период времени.
Как вы могли заметить – везде фигурирует фраза «окончательная версия» и ведь действительно – есть не только окончательные версии, но и промежуточные. Эти промежуточные версии называют «релиз кандидат» или просто «сборка», или «версия». Это те самые сырые версии продукта, которые содержат какие-либо дефекты, не позволяющие выпускать этот релиз в промышленную эксплуатацию. Когда принимается решение, что текущая сборка является стабильной или у вас закончилось время на тестирование – самый последний релиз кандидат становится релизом и передается пользователям. Например, у меня на текущем месте работы за спринт в 2 недели через тестирование проходят ориентировочно 30-40 релиз кандидатов и только одна сборка становится финальной (т.е. релизом).
Важно понимать, что релиз в разные моменты времени имеет не один и тот же состав. Например, в начале спринта команда планирует что должно войти в состав будущего релиз. Но, как говорится – «ваши ожидания – ваши проблемы» - не всегда задачи оказываются простыми и их удается разработать и протестировать за 1 спринт. Задача, которую не удалось протестировать, просто переносится в следующий спринт и под конец спринта состав релиза финализируется и может отличаться от изначально запланированного.
Или бывает другая ситуация – в начале спринта команда планирует что должно войти в состав будущего релиза. И выясняется, что спринта в 2 недели не хватает на разработку и тестирование, а вот 3 недели – достаточно. Если задача действительно критичная для бизнес-заказчика – спринт просто увеличивают на 1 неделю и состав релиза плюс-минус соответствует тому, что было запланировано.
Эти два примера показывают, что нужно действовать исходя из ситуации и потребностей заказчика в конкретной задаче или возможностей команды по ее реализации. Гибкая методология разработки на то и гибкая, чтобы люди искали общий язык. Главное не забывайте вовремя озвучивать проблемные моменты заинтересованным людям.
Что такое тестовый набор?
Будем честны – не надо иметь 300 IQ, чтобы понять «что такое тестовый набор», но всё же начнем с определения.
«Тестовый набор» – набор тест-кейсов, сгруппированных по определенной общей цели или по некоторому общему признаку. Также их называют тест-сетами (от Test set) или тест-сьютами (от Test suite), или тест-комплектами. Суть от этого не меняется. Пройдемся по примерам.
Пример №1. В результате глав «Составление проверок или первые шаги к тест-дизайну» и «Чек-листы и тест-кейсы» у нас появился полноценный тестовый набор для проверки формы регистрации. Ну и общая цель у них что-то вроде «Убедиться, что форма регистрации работает в соответствии с требованиями».
Усложняем задачу. Представим, что у нас есть 2 формы в системе:
- Форма регистрации.
- Форма изменения данных о зарегистрированном пользователе.
В данном случае мы будем иметь 2 тестовых набора – у первого будет цель «Убедиться, что форма регистрации работает в соответствии с требованиями», а у второго ««Убедиться, что форма изменения данных о пользователе работает в соответствии с требованиями».
Пример №2. В рамках внеочередного релиза планируется выпустить задачу, в рамках которой изменяется допустимая длина поля «Пароль», например увеличиваем ее с 256 до 512 символов (делаем продукт более безопасным). Это поле у нас задействовано и на форме регистрации, и на форме изменения данных о пользователе. Составляя тестовый набор, мы будем делать следующее:
- От формы регистрации мы возьмем все тест-кейсы, которые так или иначе проверяют поля «Пароль» и «Повторите пароль» , и их допустимую длину.
- От формы изменения данных о зарегистрированном пользователе мы возьмем все тест-кейсы, которые так или иначе проверяют изменение поля
«Пароль» и его допустимую длину.
По итогу мы получаем тестовый набор, у которого цель «Убедиться, что все формы на которых так или иначе задействовано поле «Пароль» и зависимое от него «Повторите пароль» работают в соответствии с новыми требованиями и нигде ничего не сломалось».
Пример №3. Представьте, что в вашем продукте 50 различных форм с совершенно разной и независимой логикой. Но так вышло, что версия языка программирования, на котором пишут ваши разработчики, морально устарела и версию нужно актуализировать, например, чтобы использовать новые фишки при написании кода или чтобы каждый второй кандидат на позицию разработчика не отказывался от вашей компании в пользу другой с более популярными на данный момент технологиями. Версию языка программирования увеличили, но для этого пришлось затронуть 50-70% кода проекта. Делать код должен всё тоже самое, но и проверять эти изменения как-то надо. Инженерам по тестированию становится страшно, они собираются все вместе и собирают один огромный тестовый набор, который включает в себя все тест-кейсы с приоритетами Критичный, Высокий, Средний и на пару дней садятся и перепроверяют всю систему. Цель такого тестового набора – «Убедиться, что все формы работают также, как работали раньше и внесение изменений по задаче никак не затронуло текущую логику системы»
Что такое тестовый запуск?
Вот мы и подошли к доказательству того самого утверждения, что тест-кейс не имеет статуса прохождения. И поможет нам «тестовый запуск» (или test execution) – процесс выполнения тест-кейса в определенный момент времени, на определенной сборке, который приводит к конкретному результату.
Представим реальную ситуацию из жизни инженера, который работает по гибкой методологии. При этом особое внимание уделим конкретному тест-кейсу «Проверка работы сервиса проверки пароля на надежность при регистрации» (он упоминался в главе про тест-кейсы).
- В спринте №1 команда реализовала задачу №1 по функционалу регистрации.
- Инженеры-тестировщики написали тест-кейсы на форму регистрации.
- Тестировщикам передали сборку с задачей по функционалу регистрации.
- Тестировщики создали тестовый набор
- Тестировщики начали «тестовые запуски» на переданной сборке.
- Все тесты пройдены успешно.
- Задача №1 ушла в релиз №1.
- В спринте №2 команда реализовала задачу №2 по улучшению сервиса проверки пароля на надежность.
- Инженеры тестировщики написали тест-кейсы по задаче №2.
- Тестировщикам передали сборку с задачей по улучшению сервиса проверки пароля
- Тестировщики создали новый тестовый набор из тест-кейсов по задаче №2 и включили в него тот самый тест-кейс с формы регистрации, чтобы убедиться, что всё работает как раньше.
- Тестировщики начали «тестовые запуски» на переданной сборке.
- Все тесты пройдены успешно.
- Задача №2 ушла в релиз №2
- В спринте №3 произошла та самая глобальная переработка кода по всему проекту. В рамках задачи №3.
- Тестировщикам передали сборку с задачей №3
- Тестировщики создали тестовый набор из всех тест-кейсов системы. Разумеется, туда попал тот самый тест-кейс с формы регистрации, указанный выше.
- Тестировщики начали «тестовые запуски» на переданной сборке.
- Тест-кейс «Проверка работы сервиса проверки пароля на надежность при регистрации» пройден неудачно.
- Создаётся баг-репорт и проводятся работы по его исправлению.
Для удобства понимания – вот картинка:
Особое внимание хочу обратить – сам тест-кейс, как документ, не изменялся. Менялось лишь время, в которое он запускался, и версия программного кода, на которой он запускался. И вот именно тестовый запуск имеет какой-то статус, в зависимости от успешности этого запуска. Распространенные статусы, которые вы встретите на 99% проектов — это «Пройден» (Passed) или «Провален» (Failed). Остальные статусы встречаются гораздо реже, но об их использовании вам обязательно расскажут при трудоустройстве, так как такие вещи регламентируются со стороны команды.
Еще один важный момент – ситуации могут быть разными и в рамках одного тест-кейса вы можете иметь несколько неудачных тестовых запусков в течение одного релиза. И более того – тестовые запуски могут быть провалены по причине неудачного прохождения разных шагов тест-кейса, т.е. в рамках первого прохождения вы обнаружили дефект в шаге №2, а после исправления проблемы шаг №2 был пройден, но шаг №4 содержит новый дефект и снова идет итерация с заведением баг-репорта и его исправлением.
Напоследок добавлю, что на мой субъективный взгляд утверждение «у тест-кейса бывает статус прохождения» — это своего рода «лакмусовая бумажка» для определения хороших / плохих источников информации. Так что, если вы видите статьи, где написано, что «у тест-кейса бывает статус прохождения успешный / неудачный» - знайте, что скорее всего эту статью написал не инженер по тестированию.
Следующая часть: Что такое тест-план? И почему было бы неплохо, чтобы он у вас был...
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля #Релиз #Тестовый_набор #Тестовый_запуск
