Подготовили для вас перевод статьи Дмитрия Ярыгина, QA Engineer с опытом работы в крупных проектах мира более 8 лет, преподавателя курса «Mobile QA Engineer» в OTUS. Интересно развиваться в данном направлении? Приглашаем пройти бесплатный двухдневный интенсив «Введение в автоматизацию тестирования мобильных приложений на Selenium и Appium».  Качество тестирования. Кто несет за это ответственность? В течение многих лет в моей голове был единственный ответ на этот вопрос. Конечно же, QA-инженер! Ведь и сам я отношусь к QA-инженерам. Я точно знаю, насколько важно протестировать качество программного продукта, который планируется выпустить на рынок. Тем не менее, я заметил некоторые закономерности, которые встречаются во время тестирования. Они заставили меня задуматься о процессе тестирования в целом и о том, как его можно улучшить. Спасибо, что спросили. Если вы разработчик, то вы знаете все тонкости и подводные камни в своем коде, или по крайней мере, вы знаете о своем коде больше, чем QA-инженер. Вы знаете свой код вдоль и поперек и понимаете, где может возникнуть проблема. Если вы знаете, где может быть проблемный участок кода, подскажите QA-инженеру. Да, он сам найдет его в какой-то определенный момент, но вы все равно знаете архитектуру приложения лучше. Тестировщики будут признательны, если вы сообщите им откуда ждать беды. Мы – QA-инженеры, сосредоточимся на нем и покроем тестами, чтобы вы меньше беспокоились. Какая-либо дополнительная информация, которую могут сообщить разработчики, явно пойдет на пользу. Юнит-тесты – это определенно то, чем должны заняться разработчики, это их зона ответственности. Именно юнит-тесты помогут избежать ненужных ошибок и излишних отчетов о них. Лучше избежать ошибки еще до того, как код попадет к команде тестировщиков, не так ли? Несколько слов о тестировании вашего собственного кода. Я считаю, что разработчики должны по крайней мере проводить smoke-тестирование своего кода. Нет необходимости проводить обширное тестирование. Просто проверьте, что код отрабатывает на каком-то входном наборе данных и отдайте его команде тестировщиков, чтобы уже они работали над ним дальше. Если код не заработает уже на этом этапе, тогда зачем вообще его отдавать QA? Вы получите десятки сообщений об ошибках несмотря на то, что вы уже знаете, что проблемы есть – это только замедлит процесс разработки. И да, и нет. Каждый раз, когда обнаруживается ошибка, особенно на продакшене, вам с вашей командой есть что обсудить. Существует несколько причин, почему ошибка проявилась только на этом этапе: Сегодня приложения становятся все сложнее и сложнее. Если хочется найти, кто виноват в провале проекта – это просто. Виноватыми могут оказаться QA-инженеры, разработчики и руководители. Или все вместе. Главный вопрос заключается в том, почему мы должны искать виноватых вместо того, чтобы взять на себя ответственность за качество проекта? На месте виноватого может оказаться любой, кто не осознал важности тестирования конкретной функции. Единственным вопросом должно быть: «Делаем ли мы действительно хороший продукт?». Если ответ на этот вопрос положительный, то не должно быть сомнений в том, что все команды делают одно большое дело.  Никого не нужно будет винить и все будут счастливы, поскольку обеспечение качества – это общая задача! CRM/Email-маркетолог