Что входит в тестовую стратегию
Как составить стратегию тестирования: версия настоящих инженеров
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
0. Разберемся на берегу
Зачем нужна стратегия тестирования?
В первую очередь, конечно же, QA и обязательно менеджер проекта.
Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!
1. Какие типы тестирования будем применять на проекте и почему
В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.
Тестирование установки версии
В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.
Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.
Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.
Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.
Тестирование производительности
На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
| Дано | Решение |
|---|---|
| Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей. | Имеет смысл запланировать volume-тестирование с большими объёмами данных. |
| Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика. | Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду. |
| Приложением пользуется несколько человек в неделю, объём данных минимален. | Тестирования производительности не требуется. |
Регрессионное тестирование
На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.
| Дано | Решение |
|---|---|
| Выкатываем первую версию продукта или модуля программы. | Регрессионное тестирование не требуется. |
| Проект очень большой, и на проведение полного регресса перед релизом новых фич требуется время, сопоставимое со сроком разработки. Требуемый темп поставок этого не позволяет. | Решаем, что регрессионное тестирование не проводим, а больше внимания уделяем другим видам тестирования и мониторингу. |
| Взаимодействие между микросервисами покрыто контракт-тестами. | Проведение полного регресса нецелесообразно. В рамках ручного тестирования проводим регресс функциональности по рекомендации разработчика. |
Интеграционное тестирование
Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.
| Дано | Решение |
|---|---|
| Данные по продажам из портала передаются в аналитическую систему. | Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге. |
Тестирование локализации
Кроссбраузерность и кроссплатформенность
Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.
| Дано | Решение |
|---|---|
| Пользователями мобильного приложения являются сотрудники по всей стране. | Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать. |
| У нашего приложения корпоративные пользователи на стационарных машинах. | Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности. |
2. Приоритеты в тестировании
На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.
В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).
| Дано | Решение |
|---|---|
| Нашей программой пользуются в аэропортах для продажи услуг пассажирам при посадке в самолет. И если в этот момент случится какая-то ошибка, то у нас не будет времени на хот-фикс. Поэтому ошибок быть не должно! | Проверяем сценарий использования в аэропорту в первую очередь. |
3. Окружения для работы
Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
| Дано | Решение |
|---|---|
| На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности. | Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA). |
| Регулярно проводятся сессии бета-тестирования. | Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение. |
4. Работы тестировщика на проекте
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.
Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.
5. Тестовая документация на проекте
6. Каким образом генерируются тестовые сценарии
7. Порядок работы с трекером
В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.
8. Критерии начала и окончания тестирования
Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.
На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
| Дано | Решение |
|---|---|
| На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования. | Считаем задачу проверенной, если мы прошли все пункты чек-листа. |
| На проекте ведется работа по спринтам. | Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше. |
| На проекте составлен список функциональности по приоритетам. | Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка. |
| На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом. | Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5). |
9. Инструменты для работы
Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.
10. Оценка качества проекта и инструменты мониторинга
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
Заключение
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
2 шаг. Анализ информации. На следующем этапе мы из всей кучи информации пытаемся выбрать важное, чтобы на основе этого сформировать стратегию. Мы фильтруем собранную информацию и оставляем самое необходимое.
HTSM состоит из следующих частей:
Project Environment. Я понимаю это как контекст продукта, то есть все, что его окружает: команда, график релизов, ресурсы, артефакты, репорты.
Quality criteria. Какие критерии качества будут важны для нас? В модели перечисляются как основные и общеизвестные критерии (Security, Compatibility, Reliability), так и менее ожидаемые (лично для меня), такие как Charisma. Внутри этих крупных критериев качества вы найдете более мелкие критерии, которые тоже являются своеобразными идеями того, что продукт может уметь в принципе.
Test techniques. Техники тестирования, которые вы можете применять. Опять же, в этой части модели перечисляются основные и общеизвестные техники (функциональное тестирование, доменное тестирование, тестирование, основанное на рисках), которые дают вам некоторую наводку, вроде: «Функциональное тестирование. Подумайте в этом направлении. Тестирование потока данных и операций. Применимо ли это к вашему продукту? А важно ли для вас выполнить тестирование со стороны пользователей? Решать, конечно, вам.»
Perceived Quality. Это результат работы нашей тестовой стратегии. Возможно я не совсем понимаю смысл этой части, но мне непонятно, как эта часть помогает думать о тестовой стратегии 🙂
Можно проследить, какие части HTSM мы используем во время выполнения шагов по формированию тестовой стратегии. Картинка:
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Любовь Тарасова, инженер по контролю качества компании EastBanc Technologies
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
0. Разберемся на берегу
Зачем нужна стратегия тестирования?
Кто составляет стратегию?
В первую очередь, конечно же, QA и обязательно менеджер проекта.
Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!
1. Какие типы тестирования будем применять на проекте и почему
В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.
Тестирование установки версии
В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.
Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.
Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.
Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.
Тестирование производительности
На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
| Дано | Решение |
|---|---|
| Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей. | Имеет смысл запланировать volume-тестирование с большими объёмами данных. |
| Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика. | Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду. |
| Приложением пользуется несколько человек в неделю, объём данных минимален. | Тестирования производительности не требуется. |
Регрессионное тестирование
На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.
| Дано | Решение |
|---|---|
| Выкатываем первую версию продукта или модуля программы. | Регрессионное тестирование не требуется. |
| Проект очень большой, и на проведение полного регресса перед релизом новых фич требуется время, сопоставимое со сроком разработки. Требуемый темп поставок этого не позволяет. | Решаем, что регрессионное тестирование не проводим, а больше внимания уделяем другим видам тестирования и мониторингу. |
| Взаимодействие между микросервисами покрыто контракт-тестами. | Проведение полного регресса нецелесообразно. В рамках ручного тестирования проводим регресс функциональности по рекомендации разработчика. |
Интеграционное тестирование
Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.
| Дано | Решение |
|---|---|
| Данные по продажам из портала передаются в аналитическую систему. | Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге. |
Тестирование локализации
Здесь важно ответить на вопросы о проекте:
Кроссбраузерность и кроссплатформенность
Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.
| Дано | Решение |
|---|---|
| Пользователями мобильного приложения являются сотрудники по всей стране. | Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать. |
| У нашего приложения корпоративные пользователи на стационарных машинах. | Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности. |
Подобным образом необходимо разобрать все остальные типы тестирования:
2. Приоритеты в тестировании
На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.
В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).
| Дано | Решение |
|---|---|
| Нашей программой пользуются в аэропортах для продажи услуг пассажирам при посадке в самолет. И если в этот момент случится какая-то ошибка, то у нас не будет времени на хот-фикс. Поэтому ошибок быть не должно! | Проверяем сценарий использования в аэропорту в первую очередь. |
3. Окружения для работы
Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
| Дано | Решение |
|---|---|
| На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности. | Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA). |
| Регулярно проводятся сессии бета-тестирования. | Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение. |
4. Работы тестировщика на проекте
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.
Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.
Например, это могут быть:
5. Тестовая документация на проекте
Нужно договориться на берегу, а возможно, дальше и регулярно пересматривать формат ведения тестовой документации:
6. Каким образом генерируются тестовые сценарии
Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:
7. Порядок работы с трекером
В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.
Проговорите с командой ключевые моменты:
(Подробнее о способах описывать баги и userstory мы писали в этой статье).
8. Критерии начала и окончания тестирования
Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.
На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
| Дано | Решение |
|---|---|
| На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования. | Считаем задачу проверенной, если мы прошли все пункты чек-листа. |
| На проекте ведется работа по спринтам. | Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше. |
| На проекте составлен список функциональности по приоритетам. | Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка. |
| На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом. | Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5). |
9. Инструменты для работы
Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.
Стоит обсудить такие вопросы:
10. Оценка качества проекта и инструменты мониторинга
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
Заключение
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.