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