ICL Services
Новости
30 июня 2021
Новости

Готово!

Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook

Ok

Управляемое тестирование: с чего мы начинаем, чтобы не было мучительно больно

В авторской статье на Хабре руководитель группы тестировщиков в ICL Services Екатерина Кияшева рассказала о том, как правильно и безболезненно подготовиться к этапу тестирования программного обеспечения.
Привет, Хабр! В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я.

И если вы, при наличии всех процессов тестирования,

  1. – выводили в PROD не то, что протестировали;
  • – тестируете не то, что нужно;
  • – находите баги в PROD, которых точно нет в тесте;
  • – вынуждены много раз тестировать одно и то же из-за процессных сбоев

– знайте, эта статья для вас.

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

DISCLAIMER

1. Перечисленное ниже является структурой “предподготовки”, а не готовым шаблоном. Инструменты, подходы, процессы представлены на правах примеров. По уму они должны выбираться исходя из особенностей проекта и продукта. Эти кейсы подходят большой линейке, но не всей (особенно боюсь поднять халивар на тему GIT flow). В любом случае, буду рада обсудить другие кейсы и особенности проектов в комментариях.

2. Наличие “предподготовки” позволяет обеспечить тестирование высокого уровня, но не гарантирует его. Однако при наличии базовых настроек гораздо проще отследить, где проседает тестирование, и принять меры.

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


Коммуникации

Хорошо выстроенные коммуникации позволяют превратить формальные проверки в клиентоориентированное тестирование.


Роли в проекте

Мы выделяем 5 значимых ролей для тестировщика со следующим предназначением:

  • Разработчик – поставляет информацию об алгоритме фичи. Это не вопрос “что тестировать”, его мы не задаем. Знание механизма дает возможность применить техники тест-дизайна на промежуточных шагах и отловить не очевидные дефекты;
  1. Аналитик/Дизайнер – поставляет информацию о бизнес-процессе пользователя и конкретных требованиях. Является последней инстанцией в спорных вопросах с разработчиком о работе продукта;
  2. Руководитель продукта/Заказчик – формирует содержание релиза. Лучше всех знает, как должны работать и выглядеть фичи, является последней инстанцией в спорных вопросах о продукте с аналитиком;
  3. Поддержка – поставляет информацию о качестве выпущенного релиза. Настоящий кладезь знаний о том, как именно используется продукт;
  4. Руководитель проекта – отвечает за графики работ, балансирует между содержанием, качеством и сроками каждой поставки. От него мы получаем информацию о первостепенных задачах и должны информировать об угрозах поставки: проблемах, блокирующих тестирование, нестабильной версии, критических дефектах. Понятно, чтобы не стать мальчиком, которого съели волки, нужно говорить о реальных рисках.

Тестировщик может хорошо проверять требования и сам продукт на соответствие нуждам конечного пользователя, когда все проектные роли найдены и с ними налажен инфообмен: о бизнес-процессах “как есть” и “как нужно”, алгоритме реализованного, условиях использования продукта и “как получилось”. Сложность поиска ролей в том, что в IT часто Должность не совпадает с Исполняемой ролью. Иногда требуется проявить настойчивость, чтобы найти все, и результаты стоят затраченных усилий.

Инфоканалы

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

  • Daily Meeting – на созвонах с командой тестировщик слышит и может сам уточнить что придет в тест, может поднять сложный вопрос сразу к нескольким ролям, например, аналитику, разработчику и руководителю проекта.
  • Рабочие чаты – наполняются тематическими каналами. На всех проектах есть канал, в который включена рабочая группа. В него тестировщики дублируют ссылки на заведенные дефекты и решают проблемы, блокирующие тестирование. В случае производственной необходимости вводятся дополнительные каналы, например с аналитиками или дизайнерами. Так тестировщики сокращают длину коммуникаций и вовремя получают актуальную информацию.
  • Почтовые пересылки – это регулярные отчеты о событиях на проекте, обычно автоматизированные. В том числе и отчеты о ходе и результатах тестирования.

Признаки хорошо настроенных инфо каналов:

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

В обратном случае тестировщики превращаются в бук — “почему раньше не сказали!” и “ну я же говорил(а)!”



Продолжите чтение статьи Екатерины читайте на Хабре.

Поделиться:

Свяжитесь с нами

Контакты Пресс-службы
Телефон 8 (800) 333-98-70

pr@icl-services.com

Будьте в курсе новостей

Подпишитесь на рассылку и будьте в курсе наших последних новостей

Подписаться на рассылку
Спасибо, что подписались на рассылку новостей! Адрес подписки успешно добавлен! Ok
На сайтах icl-services.com используются cookie-файлы. Оставаясь на сайте, вы даете свое согласие на использование нами cookie-файлов. Если, прочитав данное сообщение, вы не согласны, просим вас покинуть сайт.

Задать вопрос эксперту

Ф.И.О*
E-mail*
Наименование организации*
Должность*
Телефон*
Вопрос*

Заказать звонок

Ф.И.О*
Контактный телефон*
E-mail
Компания*
Наверх