В процессе разработки программного обеспечения тестирование занимает уникальное положение. Тестировщики отвечают за то, чтобы каждая часть кода, разработанного в рамках проекта, не содержала ошибок и работала в соответствии с техническими и бизнес-требованиями.
Это означает, что QA инженеры должны обладать всесторонним пониманием каждого проекта и его целей. Кроме того, они должны иметь четкое представление о том, что может пойти не так в работе определенного веб-сайта или приложения. Они также должны быть в курсе технических и цифровых инноваций, чтобы знать, какие могут возникнуть ошибки или угрозы, которые необходимо тестировать.
Ищите работу Junior QA? Тогда вам в наш телеграм канал QA Вакансии. Каждую неделю 7 лучших вакансий с телеграм контактом HR компании.
Учитывая круг обязанностей тестировщика, вполне естественно, что в своей повседневной работе он будет сталкиваться с многочисленными проблемами. В этой статье выделены наиболее распространенные из них, а также пути их решения.
БОЛЬШЕ ВОПРОСОВ С СОБЕСЕДОВАНИЙ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ QASOBES
Содержание:
Проблемы, с которыми сталкивается QA инженер
Ниже перечислены некоторые из распространенных проблем, с которыми сталкивается QA инженер, а также способы их решения.
1. Изменения требований в последний момент
Довольно часто в проектах гибкой разработки требования к проекту меняются в середине спринта. Хотя это расстраивает всю команду, в первую очередь страдают тестировщики. Возможно, им придется переделать весь объем работы по тестированию, поскольку даже самые незначительные изменения в кодовой базе должны пройти через множество тестов, чтобы убедиться в их стабильности и совместимости с существующим кодом.
Например, если в браузере что-то было обновлено, тестировщикам придется провести тестирование совместимости, чтобы убедиться, что существующие функции сайта будут работать безупречно даже после обновления браузера. С другой стороны, если новая функция добавляется на сайт в последнюю минуту, необходимо провести кросс-браузерное тестирование, чтобы убедиться, что функция идеально работает в нескольких браузерах.
Естественно, эти изменения, сделанные в последнюю минуту, могут создать много неудобств для тестировщиков, особенно если установлены сжатые сроки, в которые необходимо предоставить результаты.
Решение
Решить эту проблему непросто, поскольку цифровой мир постоянно развивается. Вполне возможно, что какую-либо функцию необходимо изменить или модифицировать из-за каких-либо изменений в отзывах пользователей или обновлений программного обеспечения. Например, функция может быть изменена из-за недавнего обновления браузера.
Тестировщикам следует подготовиться к тому, что это будет происходить достаточно часто. Если изменения требований происходят ближе к концу спринта, тестировщики могут провести как можно больше тестов за отведенное время. Перед началом проекта необходимо четко объяснить всей команде, что изменения в программном обеспечении, внесенные в последнюю минуту, не смогут быть полностью протестированы в заранее установленные сроки.
Сообщая заранее о реальных ограничениях тестирования, QA инженеры могут быть уверены, что в конце спринта они не покажутся необоснованными. Кроме того, разработчики и другие заинтересованные стороны будут знать, чего можно ожидать от тестировщика, и смогут установить соответствующие сроки.
2. Недостаточная информация о пользовательских историях
Основная задача тестировщика — сформулировать тестовые примеры на основе возможных путей пользователя. Однако для создания тестовых случаев у QA должна быть подробная информация о пользовательской истории. Эта информация должна исходить от владельцев продукта, которые лучше всего понимают, что должно делать программное обеспечение и как пользователи будут в нем ориентироваться.
Однако, если сам владелец продукта не имеет четкого представления о пользовательских маршрутах, он не сможет донести его до тестировщика. Тестировщик, в свою очередь, не сможет создать тестовые примеры, которые позволят всесторонне проверить сайт или приложение на предмет недостатков в пользовательском опыте. В таких ситуациях процесс тестирования теряет свой смысл.
Решение
Здесь тестировщики должны в какой-то степени опираться на собственные суждения. Вместо того, чтобы полагаться на требования и пользовательские истории, тестировщики могут порассуждать о высокоуровневых сценариях, с которыми пользователь может столкнуться при использовании определенного программного обеспечения. Например, тестировщики самостоятельно могут сформулировать набор вероятных пользовательских сценариев на основе концепции сайта или приложения, а не бесконечно ждать их от заказчика.
Когда тестовые сценарии пишутся на основе высокоуровневых вариантов использования, изменения в деталях функции приведут к незначительным изменениям в тестовой документации. Это связано с тем, что контекст и более широкий путь пользователя остаются неизменными. Следовательно, QA инженерам придется приложить меньше усилий.
3. Недостаточный опыт в автоматизации
Проекты Agile-разработки требуют от тестировщиков технической компетентности, особенно в отношении интеграционного тестирования и тестирования API. Они также должны уметь создавать скрипты для автоматизации тестирования пользовательского интерфейса с помощью таких инструментов, как Selenium.
Если у тестировщика имеется опыт только в ручном тестировании, он столкнется с серьезными проблемами при предоставлении результатов с той скоростью, которая ожидается в проекте, управляемом автоматизацией.
Решение
Тот, кто хочет работать в сфере QA, должен обладать определенными знаниями в сфере языков программирования, часто используемых для написания тестовых сценариев. Примерами таких языков являются Ruby и Java.
Даже при знании языка важно уметь пользоваться инструментами, необходимыми для работы. Например, Selenium очень эффективен для автоматизации браузеров, и знание того, как он работает, очень полезно для тестировщика.
Аналогично, JMeter – это инструмент для проведения нагрузочного тестирования с открытым исходным кодом, который достаточно легко освоить и который весьма полезен в сценариях автоматизации.
4. Недопонимание между тестировщиками и разработчиками
Профессиональная напряженность между командами разработчиков и тестировщиков все еще довольно часто встречается на практике. Команды разработчиков могут считать, что тестирование – это финальная стадия процесса, и тестировщикам не нужно ничего, кроме списка пользовательских сценариев и технических требований.
Однако тестировщикам сложно выявить недостатки в коде, если они не знакомы с процессом разработки. Без понимания того, как работает эта часть программного обеспечения, им будет трудно создать тестовые сценарии, которые будут качественно выявлять баги.
Решение
Сотрудничество между разработчиками и QA инженерами улучшает процесс тестирования. Делясь знаниями с самых ранних этапов разработки ПО, разработчики помогают тестировщикам принимать более точные решения о том, какие именно тесты нужно проводить для обеспечения качества и функциональности программного обеспечения.
Когда тестировщики могут принимать обоснованные решения, разработчики также выигрывают, поскольку всестороннее тестирование компонентов ПО гарантирует, что они будут готовы к внедрению после каждого спринта.
Решение вышеперечисленных проблем не только облегчит жизнь QA инженерам, но и оптимизирует процесс разработки программного обеспечения, сделав его более эффективным и экономичным. Облегчив работу тестировщикам, организации смогут гарантировать, что их программные продукты разработаны с учетом всех бизнес-требований и функционируют наилучшим образом.
5. Неудачные тесты в реальных пользовательских условиях
Иногда программное обеспечение не функционирует в реальных условиях так, как ожидается. Однако оно успешно прошло тесты в контролируемой среде. Тестирование на эмуляторах и симуляторах только имитирует браузер или устройство и обеспечивает контролируемую среду для тестирования программного приложения, поэтому в реальных условиях, когда возникает множество ограничений, оно может не сработать.
Решение
В таких случаях всегда рекомендуется тестировать программное обеспечение на реальных устройствах и браузерах, чтобы убедиться, что реальные условия пользователя, такие как заряд батареи, push-уведомления, медленная сеть, биоаутентификация, учтены для большей точности. Для этого можно либо создать собственную цифровую лабораторию, либо воспользоваться облаком реальных устройств, например BrowserStack. Если сравнивать варианты “построить” и “купить”, то покупка более рентабельна и требует меньше усилий по настройке и обслуживанию.
Перевод статьи «5 Challenges Every QA faces and How to solve them».