Комментарии 9
Инженеры по... хм... обеспечению качества - не могут это самое качество обеспечить? У вас не возникает когнитивного диссонанса?
Может пора признать, что классическая схема, которую выдает поисковик на запрос "чем QA отличается от тестирования" - QA -> QC -> Testing - неактуальна?
QA (обеспечение качества) и QC (управление качеством) несомненно связанные понятия, пересекающиеся - но, не являются частью друг друга.
Тестирование - это как раз часть QC
Contror ≠ Managment, а лишь одна из его функций, и она реактивная, в отличие от QA.
Но меня тоже смутила некоторая попытка в статье снять ответственность с QA, путая их с QC.
Цитата: реальность: "QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют".
QA как раз определяют риски, подсвечивают их и имеют влияние на релиз и на команду, запрещая выпускать дефектованый продукт. QC же борется с последствиями, подсчитывая количество дефектов и жалоб от пользователя.
Всё верно, я так и написала. Мы подсвечиваем риски начиная с требований, заканчивая непосредственно релизом. Выносим вердикт и рекомендации по его выпуску. В начале статьи я обозначила, что команды у нас продуктовые и ответственность за качество несёт команда. Разница лишь в том, что решение о выпуске релиза принимают совместно QA-lead, TeamLead и PM.
Control - управление, management - ... менеджмент. Трудности перевода
Тестирование - часть QC. Просто кто-то когда-то решил, что тестирование это не круто, давайте будем называть тестировщика - QA. Называть, в общем, ничего, можно. Но, нужно понимать, что к обеспечению качества это не имеет отношения
А я не писала, что не могут. Я ведь сделала акцент на подключении на ранних этапах. Это как раз задача QA в чистом виде. Я подсветила, что в наших командах качество продукта - общее дело. Часть корабля, часть команды. У нас продуктовая разработка, а не аутсорс.
Спорить относительно терминологии QA и QC не вижу смысла. Тестирование может быть частью как QA, так и QC, на мой взгляд. Более того я отметила, что у нас тестировать могут и разработчики.
QA - это разработчики-сеньоры в команде, с соответствующими зарплатами, материально-техническим обеспечением и технологиями - внутренние требования к качеству. Или закон о защите прав потребителей, 152 ФЗ и т.д. - внешние требования к качеству
На эти требования инженеры-тестировщики практически не могут никак влиять
Спорить действительно нет смысла. Об всем этом написано и в силлабусе ISTQB, и в ISO 25000 / дублирующих ГОСТ'ах. Но, никто не любит читать первоисточники
Даже в Википедии специально акцентируется внимание на том, что Обеспечение качества не нужно путать с Управлением качеством и наоборот
Вы поймите меня правильно - подключение на ранних этапах - это хорошо, это правильно. Но, это не QA. Тестирование требований - это все-равно тестирование
И на уменьшение количества багов тестировщики повлиять не могут - поэтому все правильно у вас написано. Если разработчик генерит больше багов, чем фич - можно купить ему лицензию webstorm, вместо блокнота, которым он пользуется, можно отправить его на курсы, можно приставить ментора. Можно расстаться с этим разработчиком в крайнем случае
На что из перечисленного у вас в компании могут влиять тестировщики?
Ну сколько можно, я понимаю что паразитировать на вайтишниках легко. Но скоро на Хабре будут одни статьи про питон и qa
Подсветить проблемы, предложить улучшения - это, разве, не есть то самое улучшение качества продукта? Продукт, который не имеет критических багов и удовлетворяет ожидания пользователей = качество, в свою очередь это тоже в некоторой степени позволяет повысить удовлетворённость продуктом со стороны пользователей, соответственно, количество жалоб будет не в огромных объёмах. "Значительно" естественно, не получится, но в целом имеет место быть. Кстати, тестировщики обычно выставляют не приоритет, а severity, поскольку бизнес владеет информацией о ресурсах, ожиданиях и прочем.
Относительно количества багов, тут тоже косвенно QA может влиять в том плане, что процессы будут совершенствоваться, приниматься дополнительные меры. Ну, например, на одном из моих проектов юнит тестирования поначалу не было, баги плодились в огромных количествах, по итогу менеджмент с подачи лида все таки ввел юнит тестирование, и вуаля, количество багов стало уменьшаться.
НаQA нам QA?