HR: Что делать, если разработчик утверждает, что найденный дефект таковым не является?

Указывать на требования, апеллировать к здравому смыслу, подключать аналитика, чтобы объяснил. Если это поведение не описано в доке, то это баг, либо недоработка. Но недоработка в терминах джиры все равно баг

Проверить ТЗ. Если есть расхождение с ожидаемым результатом – привязываем ссылку на ТЗ.

Если формально это не зафиксировано, но вы чувствуете, что на это стоит обратить внимание – идете к писателю/аналитику/менеджеру, объясняете и в случае согласия это попадает в ТЗ.

Если формально не зафиксировано и менеджер с вами не согласен – дефект закрывается.

Доп. материал:

Доверие между тестировщиками и разработчиками

HR: Пришел баг из продакшена, что делаем?

Воспроизводим, запускаем по пути жизненного цикла дефекта и анализируем причины, как данный дефект прошел в прод: устаревшие кейсы, специфика конкретных устройств или конфигураций которых у тестировщика нет, или это вообще была ситуация срочного релиза и кейсы был но решили выпускать без регрессии и тогда это вопрос к процессам. После исправления дефекта разработчиком проводим повторное тестирование. Добавляем данный дефект в регрессию если его там еще нет. В зависимости от охватываемого функционала и Root Cause этих багов принимается решение о проведении sanity/регрессионного тестирования после подтверждающего.

HR: Кто виноват в багах, найденных в процессе регресса?

Начнем с того, что хорошо, что эти баги нашлись сейчас тестированием, а не после релиза пользователями. Дальше надо уже разбираться отдельно с каждым конкретным багом. Какие могут быть причины:

● Низко-компетентная разработка. В таком случае, баги в процессе регресса будут регулярными. Это может быть связаны с кривым мержем задач версии, некорректно решенными конфликтами при мерже, невнимательности.

● Плохое качество тестирования. Когда тестировщик во время тестирования своей задачи пропустил какой-то кейс, а он потом всплыл при регрессе у другого тестера.

● Другие недостатки в процессах на проекте. Например, в одном релизе едут 2 фичи, которые как-то пересекаются друг с другом по функционалу, но которые тестировали 2 команды (тут может быть как проблема с коммуникациями в проекте, так и проблема в уровне квалификации тестировщиков и разработчиков, которые не взяли во внимание такое пересечение и менеджеров, которые впихнули 2 фичи в один релиз - такое должно быть допустимо только в крайних случаях и в качестве единичных акций, в остальных случаях стоит разбивать такое на 2 релиза и не рисковать качеством и конечной датой релиза).

Также не стоит забывать про обычный человеческий фактор и если такие ситуация проявляются не часто - то берите во внимание, анализируйте, проговаривайте с командой, но не делайте поспешных выводов и не принимайте радикальных решений.

Источник: https://t.me/qa_chillout/92

HR: Как решать конфликты в удаленной команде?

● Для начала запланируйте встречу с коллегой на определенное время;

● Во время разговора сформулируйте свою позицию в такой последовательности:

○ Озвучьте свое наблюдение: что коллега сделал, что вам не понравилось;

○ Выразите словами свои чувства и свою реакцию;

○ Выразите словами значимую для вас потребность, которая была проигнорирована;

○ Предложите решение или сформулируйте ясный запрос;

● После разговора следует зафиксировать ваши договоренности.

Источник:

Как решать конфликты в удаленной команде

HR: Как понять, что тестировщик хорошо сделал свою работу?

Бытует мнение, что основная задача тестировщиков - сломать продукт, на самом деле тот уже приходит на тестирование с дефектами, одна из задач тестировщика как раз их выявить.

Понять, что тестировщик выполнил свою работу хорошо можно по факту выполнения следующих задач:

● продукт проверен на соответствие требованиям;

● сведено к минимуму количество дефектов, которые обнаружит конечный пользователь;

● предоставлена отчетность по актуальному качеству продукта заинтересованным лицам.

 

----- Теоретическая часть -----

Общее

Обеспечение качества (Quality Assurance - QA)

Это часть Quality Management - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и поддержки ПО, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта. Т.е. QA обеспечивает создание правильных процессов для получения в результате качественного продукта. Это также означает создание процессов контроля качества (QC), которые в свою очередь гарантируют, что процессы, установленные QA, соблюдаются. Проще говоря, если тестировщик вступает уже после этапа разработки (не считая, возможно, создания артефактов заранее), то QA участвует в каждом этапе SDLC, начиная еще с составления требований, и занимается не проверкой постфактум уже готового ПО на соответствие требованиям и наличие дефектов, а пытается предотвратить само появление этих дефектов, являясь эдаким “инфлюенсером”, специалистом, влияющим на процессы разработки и улучшающий их качество для обеспечения качества итогового продукта.

Если попытаться перечислить некоторые активности, то получится что-то вроде:

● Проверка/тестирование/верификация требований и спецификаций;

● Оценка рисков (Risk assessment);

● Планирование задач по повышению качества продукции;

● Подготовка тестовой документации (сроки, подход (approach), плана тестирования, тест кейсов и чек листов), тестовых сред и данных. По сравнению с QC и тестированием на этом этапе разрабатывается эффективная модель и последовательность проведения различных тестов продукта, а также описываются инструменты и сценарии, которые обеспечат необходимый уровень покрытия функциональности;

● Процесс тестирования продукта;

● Анализ результатов испытаний, отчетов и других приемочных документов.