Мы подготовили для вас перевод статьи Дмитрия Ярыгина, QA-инженера с более чем 8-летним опытом работы в крупных проектах по всему миру, преподавателя курса «Мобильный QA-инженер» в OTUS. Хотите развиваться в этом направлении? Приглашаем вас посетить бесплатный двухдневный интенсив «Введение в автоматизацию тестирования мобильных приложений на Selenium и Appium» .
Качество тестирования.
Кто несет за это ответственность? Многие годы в моей голове был только один ответ на этот вопрос.
Конечно, QA-инженер! Ведь я сам QA-инженер.
Я точно знаю, насколько важно протестировать качество программного продукта, который планируется выпустить на рынок.
Однако я заметил некоторые закономерности, возникшие во время тестирования.
Они заставили меня задуматься о процессе тестирования в целом и о том, как его можно улучшить.
Должны ли разработчики тестировать свой код? Спасибо за вопрос.
Если вы разработчик, то вы знаете все тонкости своего кода или, по крайней мере, знаете о своем коде больше, чем инженер по контролю качества.
Вы знаете свой код вдоль и поперёк и понимаете, где могут возникнуть проблемы.
Если вы знаете, где может быть проблемная область кода, сообщите об этом QA-инженеру.
Да, оно само найдется в какой-то определенный момент, но архитектуру приложения вы все равно знаете лучше.
Тестировщики оценят, если вы сообщите им, где ожидать проблем.
Мы QA-инженеры, мы сосредоточимся на этом и покроем тестами, чтобы вы меньше волновались.
Любая дополнительная информация, которую могут предоставить разработчики, определенно будет полезна.
Модульные тесты — это определенно то, что должны делать разработчики, это их ответственность.
Юнит-тесты помогут вам избежать ненужных ошибок и ненужных отчетов о них.
Лучше избегать ошибок до того, как код попадет в команду тестирования, верно? Несколько слов о тестировании собственного кода.
Я считаю, что разработчики должны хотя бы дым-тестировать свой код. Нет необходимости в обширном тестировании.
Просто проверьте, что код работает с каким-то набором входных данных, и передайте его команде тестирования, чтобы они могли над ним работать дальше.
Если код не работает на этом этапе, то зачем вообще отдавать его в QA? Вы получите десятки сообщений об ошибках, даже если уже знаете о наличии проблем — это только замедлит процесс разработки.
Мы пропустили ошибку.
Виноваты ли в этом тестировщики? Да и нет. Каждый раз, когда обнаруживается ошибка, особенно в рабочей среде, вам и вашей команде есть что обсудить.
Есть несколько причин, почему ошибка появилась только на этом этапе:
- Место появления ошибки никогда не было приоритетом для тестировщиков.
Очень часто никто не задумывался об ошибке, появившейся в производстве.
Это результат отсутствия общения между разработчиками и тестировщиками.
Не было взаимопонимания относительно того, насколько важно было протестировать ту или иную область.
Классическими примерами такой халатности являются проблемы производительности и безопасности.
Если вы знаете, что эти области имеют решающее значение для вашего приложения, сообщите об этом команде.
- QA не обладает необходимыми знаниями в тестируемой области.
Это также распространенная проблема.
Разработчики написали функцию и автоматически предположили, что QA понимает, как она работает внутри и снаружи.
Что ж, догадки никогда не являются хорошей стратегией для анализа качества серьезного проекта.
Если вы видите какой-то важный аспект, убедитесь, что ведущий QA-инженер и его команда тоже его видят и понимают. Обойти этот этап невозможно.
- Разработчиков это особо не волнует. Мы все люди.
И у всех нас есть жизнь помимо работы.
Некоторые разработчики долго и упорно работают над созданием качественного продукта, общаются с тестировщиками, сообщают им о возможных проблемах и тому подобное.
А есть разработчики, которым все равно.
Они не употребляют этот продукт каждый день и не понимают его важности.
Для них это всего лишь побочное задание, которое нужно выполнить и забыть.
Проще говоря, их не волнует, что конечный продукт будет низкого качества.
- QA-инженерам плевать.
Вот другая сторона медали.
Не всем тестировщикам интересен проект. Некоторым людям просто нужно закончить тестирование, сделать красивый отчет и забыть об этом.
Их не заботит качественное тестовое покрытие; они не хотят общаться с разработчиками.
Обсуждать ошибки можно, но такие тестировщики могут просто не посчитать их важными и даже не зарегистрировать.
- Тестировщики недостаточно квалифицированы.
Другая проблема может заключаться в том, что тестировщики просто недостаточно квалифицированы для тестирования вашего приложения.
Например, вам нужно провести тестирование на проникновение, но все, что в вашем распоряжении — это команда тестировщиков, которые умеют проводить только ручное тестирование.
В этом случае они просто не будут знать, как к этому подойти.
Здесь нужно либо полагаться на разработчиков, либо подбирать больше людей в свою команду.
квалифицированные QA-инженеры, которые точно будут знать, как проводить тестирование в этой конкретной области.
- Отсутствие исследований пользователей.
Разработчики знают, как создать приложение, а инженеры по контролю качества знают, как его взломать.
А что насчет пользователей? Пользователи — это реальные люди, которые будут использовать ваше приложение в реальном мире.
Они не собираются его ломать.
Просто они все разные и имеют разные цели, но все хотят достичь их с помощью вашего приложения.
QA-инженеры могут привыкнуть к ошибке и понять, что она возникает нечасто и поэтому не имеет большого значения.
Пользователь этого не потерпит. Если ваше приложение сломалось, следующим шагом будет его удаление и поиск альтернативы.
Это реальность.
Исследование пользовательской аудитории и/или наличие тестовой группы пользователей — две стратегически важные вещи.
- Плохая организация процесса общения.
В идеале должен быть простой процесс сортировки ошибок, который позволял бы оценивать ошибки, возникающие в результате контроля качества (или, по крайней мере, правильно расставлять приоритеты) и передавать их разработчикам, чтобы они понимали свою рабочую нагрузку.
При возникновении любого недопонимания тестировщик и разработчик всегда должны иметь возможность связаться друг с другом и решить проблему в течение нескольких минут или часов.
Если этот процесс не налажен и обе стороны не торопятся искать причину недопонимания, то ничего хорошего из этого не выйдет. Обе стороны будут имитировать активность, но на самом деле обе окажутся в тупике и ждут кого-то третьего, кто сможет прийти и волшебным образом разрешить сложившуюся ситуацию.
Это в корне неверный подход.
- Тестеров не хватает. Приложение может быть сложным и требовать тестирования на нескольких платформах и браузерах.
Для этой задачи может оказаться недостаточно всего нескольких инженеров по обеспечению качества.
Подумайте о том, чтобы нанять больше людей или перераспределить существующие ресурсы, чтобы уделять больше внимания тестированию.
- Разработчики перегружены.
Вокруг вас могут быть идеальные и высококвалифицированные специалисты, но они работают в постоянном стрессе и никто не может им помочь.
Да, они находятся под давлением и у них просто нет времени общаться с командой QA. Это очень распространенная проблема и одна из основных причин, почему программное обеспечение оказывается плохим.
- Качество не в центре внимания.
Рассмотрим и этот сценарий.
Здесь и там было несколько мелких ошибок.
Ни один из них не является критическим.
Однако пользователям приложение не нравится.
Отзывы плохие.
UX ниже среднего.
И почему все? Да потому что никто не думал о создании качественного продукта.
Разработчики делали свою работу, тестировщики — свою, но за самим процессом контроля качества никто не следил.
Разработка приложений должна объединять команды, делая их одним целым.
Если такого настроения в команде нет, то о качестве никто не заботится.
Если вы хотите узнать, кто виноват в провале проекта, это просто.
В этом могут быть виноваты QA-инженеры, разработчики и менеджеры.
Или все вместе.
Главный вопрос: почему мы должны искать виноватых вместо того, чтобы брать на себя ответственность за качество проекта? Виновником мог быть любой, кто не осознавал важности тестирования конкретной функции.
Единственный вопрос должен быть: «Мы делаем действительно хороший продуктЭ» .
Если ответ на этот вопрос положительный, то не должно быть сомнений в том, что все команды делают одно большое дело.
Виновных не будет, и все будут довольны, ведь обеспечение качества – это ответственность каждого! Теги: #qa #testing #Тестирование веб-сервисов #Тестирование мобильных приложений #otus #тестирование качества #инженер по автоматизации контроля качества #стратегия контроля качества #мобильное обеспечение качества
-
Рост Программных Решений Erp В Индии
19 Oct, 24 -
Взгляните На Hp Pavilion-Dv6-3050Us
19 Oct, 24 -
Регистрация Открыта
19 Oct, 24 -
Пол Грэм: Будущее Веб-Стартапов
19 Oct, 24 -
Лауреаты Игнобелевской Премии 2007 Г.
19 Oct, 24 -
Как Восстановиться После Выгорания На Работе
19 Oct, 24
