Согласно классической схеме работы на проекте, программисты пишут код, а инженеры по тестированию ПО ищут ошибки в нем и передают их на исправление.
Однако сегодня встречается и другой вариант – руководители проектов сознательно не привлекают специалистов по тестированию, мотивируя это тем, что и сами разработчики могут справляться с поиском дефектов.
Почему так происходит? Можно ли обойтись без тестировщиков на проекте? Читайте в нашей статье.
Почему иногда пренебрегают инженерами по тестированию?
Периодически на стартапах руководители решают обойтись без людей, которые занимаются только тестированием разрабатываемого продукта.
В этом случае программисты вынуждены сами обеспечивать качество кода, даже когда методика разработки напрямую не построена на выполнении таких действий.
Конечно, есть много опытных профессионалов своего дела, для которых качественно выполненная работа – вопрос принципа. Однако нее все относятся к проверке кода ответственно.
Некоторые руководители проектов с использованием гибких методологий разработки (agile) иногда могут пренебрегать услугами тестировщиков, уверенно полагая, что они нужны лишь на проектах с каскадной моделью.
Кто может брать на себя роль QA-инженера?
В вышеописанных случаях роль тестировщика на проекте выполняют сами разработчики или даже заказчики. Рассмотрим, как происходит контроль качества продукта в таких ситуациях.
Разработчики
Непосредственные авторы кода иногда занимаются поиском дефектов. В своей работе они прибегают к следующим практикам:
Code Review:
Метод часто используется на agile проектах. При написании кода разработчик сам постоянно его проверяет. Таким образом, он находит опечатки, повышает качество продукта и добивается единого стиля письма.
TDD (Test-Driven Development):
Прием разработки через тестирование. Перед созданием самого кода программисты пишут автоматические тесты разрабатываемых приложений, которые и будут определять требования к коду.
Continuous Integration:
Методика создания ПО, при которой для более быстрого поиска дефектов на ранней стадии программисты непрерывно интегрируют все рабочие копии в одну ветвь разработки и проводят автоматизированные сборки проекта.
Парное программирование:
Код пишут сразу двое специалистов – один из них работает над самим кодом, а второй все время проверяет готовую часть. Периодически программисты меняются местами.
Заказчик
Иногда даже заказчик обеспечивает качество готового решения. В таких случаях он принимает проделанную работу после каждой итерации.
Такие ситуации периодически возникают на проектах с использованием гибких методологий, когда заказчик хочет еще и проанализировать работу команды.
Так всегда ли нужны тестировщики?
Описанные выше ситуации иногда встречаются на практике. Но можно ли до конца быть уверенным в том, что без привлечения инженеров по тестированию качество продукта останется на высоте?
Теперь давайте рассмотрим аргументы в пользу того, почему же тестировщики нужны на проектах.
Специфические навыки тестировщиков
Тестирование продукта требует от специалистов особых навыков, которые сильно отличаются от требований, предъявляемых к разработчикам.
Инженеры по тестированию, помимо внимательности, природной любознательности и тяге к исследованию, должны быть дисциплинированны и готовы к тому, что временами им придется выполнять монотонную работу.
Для нахождения некоторых дефектов порой придется мыслить нестандартно и творчески подходить к решению проблемы.
QA-инженеры должны также знать и понимать работу тестируемого ИТ-решения и охватывать всю картину в целом, чтобы не упустить ни одну деталь.Анатолий Карпин, редактор Minsk1.netПри перепечатке материалов, ссылка наhttp://minsk1.netобязательна!