Моя первая статья об интеграции Playwright и GitLab CI в Qase получилась довольно формальной. Переживания о ней были огромными: я хотела сделать ее “правильной” и, самое главное, доступной для каждого, кто решит ее прочитать и применить на практике. В столь технической статье было сложно выразить свое мнение о чем-либо, поэтому в этой статье я бы все же хотела это сделать и немного порассуждать на тему обеспечения качества, и почему это не только про тестирование. Я рассмотрю QA как комплексный процесс, который включает помимо технических аспектов еще и командную работу, планирование, предотвращение ошибок и многое другое.
Со временем каждый из нас выделяет для себя наиболее значимые аспекты в своей работе и принципы, на которые он опирается от проекта к проекту и которые сохраняются или трансформируются во что-то новое, создавая основу. Я придерживаюсь нескольких принципов, которые помогают мне выстраивать работу. Эти принципы можно представить в виде пирамиды, к которой мы вернемся позже.
А пока…
Тестирование и QA — в чем разница?
Когда мы говорим о тестировании, большинство людей сразу думают о поиске багов. Тестирование, как правило, это поиск багов, но тут есть нюанс. Хорош ли QA, который нашел 1000 багов? Наверняка. Но хорош ли продукт, на котором нашлось столько багов? Вот здесь и возникает парадокс: чем меньше багов мы находим, тем лучше. На первый взгляд это может показаться странным — ведь в этом, вроде как, и есть наша работа. Здесь мы подходим к ключевому различию между тестированием и обеспечением качества.
Тестирование — это лишь инструмент для поиска проблем, но само по себе оно не гарантирует качество продукта. QA — это комплексная работа, которая включает планирование, оценку рисков, предотвращение ошибок и, конечно, тестирование. Чем раньше QA включается в процесс разработки, тем выше шансы на создание качественного продукта с минимальным количеством багов.
Пирамида QA
Базовые навыки и принципы QA вместе создают прочную основу. Для себя я их представляю в виде пирамиды, которая показывает, что для достижения качественного продукта нужно пройти несколько ступеней:
-
Саморазвитие и навыки поиска информации
Это основа всей работы QA. Если ты не развиваешься и не умеешь искать нужную информацию, ты быстро отстанешь от индустрии. -
QA хард скиллы
Технические навыки, такие как понимание основ тестирования, работа с инструментами тестирования и знание языков программирования, составляют второй уровень пирамиды. Они необходимы для того, чтобы QA мог эффективно взаимодействовать с процессами разработки. -
Глубокое понимание продукта и эмпатия к пользователю
Понимание продукта позволяет находить скрытые проблемы, а эмпатия к пользователю — оценить, насколько продукт удобен и эффективен для конечной аудитории. Это не только минимизирует риски и ошибки, но и делает продукт более качественным и полезным для тех, кто им пользуется. -
Структурирование и документация
Без четкой документации и организации процесса работа становится хаотичной. QA должен уметь упорядочить свои действия и обеспечить прозрачность работы для всех участников процесса. -
Командная работа
Это вершина пирамиды. Чем слаженнее работает команда, тем лучше итоговый результат. Эффективное сотрудничество помогает предотвращать ошибки на ранних этапах и делает процесс разработки более стабильным и результативным.
Каждый уровень этой пирамиды символизирует важный аспект работы QA, где каждый последующий уровень опирается на предыдущий. Без фундаментальных навыков саморазвития и умения искать информацию невозможно развивать технические компетенции, необходимые для эффективной работы с процессами разработки. Технические знания в свою очередь помогают глубже понимать продукт и оценивать его с точки зрения пользователя. Без понимания продукта невозможно качественно структурировать процесс и документировать тестирование. Завершает все командная работа: даже самые сильные индивидуальные навыки не принесут пользы без слаженного взаимодействия внутри команды. Таким образом, каждый уровень пирамиды взаимозависим, и вместе они определяют прочную базу, без которой невозможно достичь высокого качества продукта.
Теперь я бы хотела чуть более подробно остановиться на каждом из пунктов.
Развитие и поиск информации
Первая ступень пирамиды — саморазвитие и поиск информации — остается ключевым навыком в работе QA. Для того, чтобы наладить эффективную работу недостаточно просто технических навыков. Требуется постоянное саморазвитие, изучение новых инструментов и подходов. И иногда все, что нужно сделать для этого — просто загуглить. Это базовое действие часто выручает и в обычной жизни, но при работе с технологиями, где они развиваются и меняются быстрее, чем успеваешь опомниться, умение быстро находить новую информацию — важнейший навык. Если не знаете, как работает новый инструмент — гуглите. Не уверены в баг-репорте — гуглите примеры. Столкнулись с ошибкой и не понимаете, как ее описать — гуглите, как получить больше информации из DevTools.
С началом развития искусственного интеллекта нельзя не выделить его полезность и в работе QA. Я часто прибегаю к помощи ChatGPT, например, чтобы быстро разобраться с новой библиотекой или получить подсказки по интеграции инструментов. Он позволяет сэкономить время на исследованиях и ускорить процесс тестирования, особенно если этого времени не так уж и много.
QA, который научился быстро находить ответы, сможет решать задачи быстрее и увереннее, не полагаясь каждый раз на помощь со стороны. Со временем этот навык становится фундаментом и ища новую информацию самостоятельно уже перестаешь даже задумываться об этом, а просто открываешь знакомую строку поиска.
QA хард скиллы
Как я сказала ранее, для того, чтобы наладить работу недостаточно просто технических навыков. Умение писать тест-кейсы или отправлять API запросы действительно не гарантирует качество продукта, но, как бы то ни было, без этих навыков, вам также не быть хорошим QA. Думаю, не стоит говорить о важности знаний теории тестирования, инструментов тестирования, языков программирования, баз знаний итд итп. Технические навыки не зря второй уровень пирамиды — успешная работа QA невозможна без хорошего владения этими знаниями. Для создания качественного продукта необходимо разбираться в тестировании и технологиях на глубоком уровне, чтобы эффективно взаимодействовать с процессами разработки и обеспечивать качество на техническом уровне.
Глубокое понимание продукта и эмпатия к пользователю
Понимание продукта позволяет находить скрытые проблемы, а эмпатия к пользователю — оценить, насколько продукт удобен и эффективен для конечной аудитории. Невозможно обеспечить высокое качество продукта, не зная, как и кем он будет использоваться. Поэтому важно не только понимать техническую сторону, но и иметь представление о том, какие задачи решает продукт, и с какими проблемами могут столкнуться пользователи.
В процессе тестирования я стараюсь представить себя конечным пользователем: пройти сценарии использования так, как это делали бы реальные люди, выявить неудобные моменты или ошибки, которые могли быть упущены на других этапах. Это момент, когда можно позволить себе расслабиться и подойти к продукту как простой пользователь, который просто кликает по кнопкам, переходит по ссылкам и пытается найти то, что его интересует. Этот процесс не только приятен, но и крайне полезен, ведь часто ошибки кроются именно на поверхности, в тех местах, где мы слишком углубляемся в детали и забываем о простоте.
Документация
Как уже было упомянуто в пирамиде, хорошая документация обеспечивает структуру и порядок в работе всей команды, а также способствует предотвращению ошибок. Даже когда времени мало, документация остается неотъемлемым элементом работы. Она помогает сохранить логику тестирования, дает понимание того, что уже было сделано, и позволяет избежать повторения одних и тех же ошибок. Это важная часть процесса, которая отражает текущее состояние проекта и помогает другим участникам команды легко включиться в работу.
Качественная документация — это не о том, чтобы написать как можно больше слов. Это о том, чтобы сделать её краткой, четкой и наглядной. Ситуации, когда разработчик не может воспроизвести баг из-за недостаточно подробного баг-репорта, тратят гораздо больше времени, чем если бы на этапе написания отчета были приложены скриншоты и описаны условия. Поэтому документация — это не просто совет начинающему QA, а необходимая составляющая работы, которая экономит время и ресурсы всей команды.
Командная работа
Вершина нашей пирамиды:)
Взаимодействие внутри команды просто невозможно обойти стороной. Чем лучше работает команда и чем более слажены процессы, тем меньше остается пробелов в работе и тем меньше багов остаётся. Четко поставленные задачи, использование юнит-тестов разработчиками, участие QA в процессе на ранних этапах — все это снижает количество ошибок. Так что, даже если QA, о котором мы говорили в самом начале, нашел не 1000 багов, он все еще хороший QA. А продукт без этих багов вообще просто супер!
Каждый член команды вносит свой вклад, и без этого взаимодействия качественного продукта не получится. Нельзя выделить одного человека и возложить на него все неудачи и удачи продукта. К сожалению или к счастью, один он бы не справился, чтобы все это учинить:) Таким образом, когда каждый на своём месте делает всё возможное для предотвращения ошибок, тестирование превращается в финальный этап, где количество багов становится минимальным, а продукт — максимально готовым к использованию.
В заключение
Так в чем же тогда задача QA в этом процессе, как не в поиске багов? Роль QA — не только искать ошибки, но и помогать предотвращать их. Разработчики ответственны за то, чтобы код был качественным, проект-менеджеры — за то, чтобы требования и задачи были четкими и понятными, а QA — за то, чтобы обеспечить прозрачность процесса тестирования и помогать предотвратить проблемы до их возникновения.
Это не только про поиск багов. Помимо тестирования, QA составляет тест-план еще на ранних стадиях проекта, который может стать основой для всей команды. По этому плану разработчики могут заранее учитывать возможные риски в коде, видеть чёткие ориентиры, где и как будут проходить тестирования, какие модули требуют особого внимания. QA может участвовать в обсуждении требований и задач на уровне всей команды, помогая улучшить их чёткость и предотвратить потенциальные недоразумения в дальнейшем. Это позволяет интегрировать тестирование прямо в процесс разработки, а не рассматривать его как отдельную задачу.
Таким образом, тестирование становится не просто формальными проверками, это погружение в мир продукта, в котором у вас есть возможность одним из первых уловить настроение и представить будущее развитие этого продукта, представить как им будут пользоваться.
ссылка на оригинал статьи https://habr.com/ru/articles/845890/
Добавить комментарий