Разбираемся с проблемами QA и улучшаем тестирование

Разбираемся с проблемами QA и улучшаем тестирование

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

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

1.0 Сложности

Неясные требования и цели

Хотя в Agile менять требования в середине спринта не рекомендуется, такое иногда происходит. Это стресс для всей команды, в том числе тестировщиков. Ведь объём тестирования тоже меняется.

Сценарий тестирования должен соответствовать конечной цели проекта. Поэтому важно чётко их сформулировать и донести заранее. Иначе может получиться вовсе не тот продукт, который ожидался.

Дороговизна и непонятная оценка качества

Компетентная agile-команда поможет снизить затраты на QA, приступив к тестированию на первых этапах проекта и выполняя его на протяжении всего цикла разработки. Проблемы, найденные на этом этапе исправить значительно проще и дешевле. А ещё исследования показывают, что аутсорсинг может снизить затраты на тестирование ПО на 25–45%. Правда, нужно подобрать квалифицированную QA команду.

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

Нехватка коммуникации и простои

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

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

2.0 Решение

Культура QA

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

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

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

Частое регрессионное тестирование также может смягчить некоторые проблемы, связанные с ранним и частым тестированием. Команда QA определит конкретные области, в которых может возникнуть регрессия, что поможет свести к минимуму время тестирования без ущерба для покрытия. Автоматизация также является отличным способом частого тестирования, и её можно внедрять постепенно.

Обучение

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

Agile и непрерывное тестирование

С развитием Agile и DevOps стал популярным миф о том, что «тестировщики не нужны». Конечно, это не так. Тестирование, как и разработка, меняется, и новые методики помогают повысить качество конечного продукта.

Мы в Evrone исповедуем Agile и QAOps — сочетание QA и DevOps. Члены нашей команды умеют работать удаленно, сотрудничать с командами заказчика и избегать основных проблем QA-аутсорсинга.

77
1 комментарий

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

1
Ответить