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

Это потому, что обе их движущие мотивы могут быть разными. Разработчик делает то, что ему поручено, а именно пишет правильный код, относящийся к конкретной функции, а это означает, что его область действия может быть ограничена тем, как его часть соответствует более широкой картине для конечного пользователя. Инженеры по контролю качества, с другой стороны, сосредоточены на том, чтобы убедиться, что часть удовлетворяет общее впечатление пользователя, привнося точку зрения пользователя.

Отсюда мы можем увидеть потенциальный конфликт между ними: с одной стороны, кодирование завершено и оно «делает то, что должно делать», а с другой стороны считает, что «его можно было бы выполнить лучше». Хуже, если есть крайний срок.

Итак, вот небольшое руководство о том, как заставить их работать вместе и фактически идти на компромисс, чтобы предоставить действительно высококачественное программное обеспечение.

Начинайте тестирование как можно раньше
Обычно бывает так, что тестировщик не будет проводить тестирование, «пока команда разработчиков не закончит кодирование и сборку продукта». Однако вот предложение. Привлекайте их на самых ранних этапах разработки. Если QA продумает возможные ошибки и сценарии, это действительно поможет SDLC.

Самое раннее тестирование QA также может выявить любые ошибки на ранней стадии. Если команда QA участвует на самых ранних этапах разработки, тестировщики и команда разработчиков могут сообщить, что QA будет тестировать в первую очередь, какие свойства CSS и JavaScript используют разработчики, и могут дать рекомендации по любым потенциальным проблемам на раннем этапе. Тестировщики QA также могут параллельно приступить к работе, начав тестирование кода, что сэкономит много времени и предотвратит ошибки разработчиков. Тот, кто ранняя пташка, ловит червя, или в этом случае QA обнаружит ошибки и сможет исправить их раньше.

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

Это значительно повысит производительность и поможет им наладить сотрудничество между двумя отделами.

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

Используйте инструменты автоматизации и обучайте разработчиков
Нельзя отрицать чудеса инструментов автоматизации, они могут значительно сократить усилия по регрессионному тестированию и предоставить программное обеспечение быстрее, чем когда-либо. Автоматизированное тестирование может помочь вашей группе тестирования сэкономить время и усилия на повторяющихся тестовых сценариях, позволяя им находить более важные сценарии тестовых случаев с их дополнительной пропускной способностью. Такие, как Selenium Grid.
Еще лучше, если даже разработчики также могут его использовать. Ваши тестировщики могут помочь разработчикам быстрее выполнять модульное тестирование, используя среды автоматизированного тестирования.

Наладьте надлежащее общение
Старые специалисты по контролю качества обычно начинают общение с разработчиками с журналов отчетов. Затем они продолжают говорить, следя за журналами. Это не только медленно, но и неэффективно. И QA, и разработчики должны обсуждать и проверять прогресс друг друга так же быстро, как и в быстром темпе рабочего процесса в ИТ-отделе. QA должен уже знать, что делают разработчики и какие проекты они тестировали вручную или в коде. Разработчики должны понимать видение QA о том, что делает «идеальный» или «приемлемый» продукт от QA, поскольку они являются в некотором роде расширением того, что внутренний пользователь будет использовать продукт. Пусть они оба работают вместе во многих проектах, таких как разработка тестов, создание принятых критериев (AC) или в программировании тестов, где они совместно работают над требованиями проекта, выявляют проблемы, разрабатывают код, запускают тесты и многое другое. Всегда избегайте недопонимания.

Имейте правильное мышление
В конце концов, весь смысл проекта, создания программного обеспечения с нуля, многократного тестирования и пересмотра его, заключается в предоставлении наилучшего и удовлетворительный продукт возможен. Обе команды должны понимать, что в конце концов они нужны друг другу и имеют одну и ту же конечную цель. Делать клиентов счастливыми… и, конечно, если продукт плохой, начальство может сократить им зарплату, а вы этого не хотите, не так ли?

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