Комментарии 18
Если я сокращу статью до:
1) многие путают QA и QC
2) QC видит только ошибки
3) QA видит весь продукт в масштабе…
4) и поправляет, когда девелоперы делают что-то не так
5) QA это хорошо
что я упущу из статьи?
Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.
e-ivanchenko, смотрим ГОСТ Р ИСО 9000-2015: «Качество — степень соответствия совокупности присущих характеристик объекта требованиям». Все, и не надо фантазировать про потребителя и прочее. Вот как требования выявили, так и получили…
Опять же, специалисты по QA не занимаются они вот этим:
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.
То что тут описанно это QC, ага оно самое, верификация и валидация.
В задачу QA входит например поставить процесс релизного менеджмента или например если мелко, процесс обработки изменеий в коде, пулл реквестов.
Повторюсь, QA инженеры работают с процессами, просто обычно они не поднимаются выше процессов обеспечения качества, а вот инженеры по процессам, работают уже с любым уровнем.
e-ivanchenko по картинке, где стоимость изменения растет вверх от времени. Это будет так если вы поклали орган на атрибут качества под названием сопровождаемость.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.
А книги нагло врут про реальную жизнь…
В стандартах есть тестирование, это так к слову.
Еще раз, «Качество — степень соответствия совокупности присущих характеристик объекта требованиям».
С этим мы можем работать, улучшать и прочее. С тем что думают пользователи внезапно нет.
Мы можем предпринимать набор действий, а вот результат слабо предсказуем.
Именно поэтому QA специалисты работают с ОБЕСПЕЧЕНИЕМ качества. Их задача убрать преграды на пути других, что бы они сделали продукт качественно, основной инструмент это процессы.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Потому что ты написал это в чистом виде QC. Именно QC специалисты определяют достаточно критериев для приемки той или иной фичи или нет. Иногда ПМИ заставляют писать аналитиков, но аналитик и тестировщик это одно и то же, набор навыков у них один.
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Эти люди есть везде где активно используют ИСО или CMMI, просто в части компаний придумывают свой альтернативный путь и идут по нему.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Посмотрите, что есть сопровождаемость по стандартам.
Нравиться мне когда сравнивают не сравнимое. Но скажу. Компании которые упираются в том числе и в качество, делают так, что бы стоимость исправления дефекта была одинаково низкой, хоть на проде, хоть в доке. И этим занимаются специалисты по качеству. Так что второй пример, пример именно фиговой работы QA.
Собственно тут и определяются два пути развития: либо учись программировать и становись матерым SDETом, либо учись увлекательно говорить и становись менеджером. Есть ещё QA аналитик, кстати. В России таких вакансий не встречал, но есть… Что-то среднее между бизнес аналитиком и тестировщиком. Скажем, если нужно нового клиента прикрутить к существующим бизнес процессам. Соответственно нужно понять как адаптировать клиента и софт друг под друга. QA analyst будет одним из участников такой адаптации.
Тестирование странная пограничная область. Разработчики и бизнес перетягивают тебя на свою сторону, потому что таково положение дел: одни делают вид, что работают, другие делают вид, что управляют. Поэтому матёрый тестировщик всегда переходит на тёмную сторону: становится своим у тех или других. Только евангелисты продукта могут быть по настоящему привержены качеству, но они далеки и от QA и от QC.
"QA — низшее звено пищевой цепочки."
Ну… Ну… Занимаюсь автоматизированным тестированием микросервисов в большом проекте. Умею настраивать docker, mysql, mongo, elasticsearch и кучу сопутствующих фреймворков, сервисов и т.п. + знание бизнес логики. А вот программисты иногда даже не знают продукт который пишут. И часто поменять программиста легче, чем QA. Так кто там "низшее звено"?
Пройдёт ещё время и у тебя перестанет бомбить на эту тему )))
Может ещё статью написать в чем разница между «Функционалом» и «Функциональностью»?)
Тоже будет полезно
- анализировать требования (не читать их, а анализировать, раскладывая их на сущности, подсущности и свойства всех этих шняг)
- придумывать тестовые ситуации
- формулировать и записывать тестовые ситуации
- выполнять тестовые ситуации
тянули за собой и отдельные проектные роли, вроде Тест-Дизайнер, Тест-Аналитик и Тест-ТестерОбыкновенный (Исполнительный, Тупой, Бесперспективный, ну, вы же знаете). И над всеми был нужен Тест-Менеджер или Координатор усилий группы людей. Отдельные роли и (не всегда) отдельные люди.
Было хорошо, если весь дизайн и аналитику для тестирования делали аналитики, которые требования формулировали. Чаще нет.
Со временем бизнес упростил всё, пусть придёт ОДИН чувак, который и требования осознает, и тесты придумает, и сам их выполнит. И уже давно появились люди, которые не знают, что можно/нужно по-другому, и которых старая терминология не настораживает, а только слегка смущает. А значит, можно всё старьё проигнорировать или обобщить, и ничего плохого не случится. QA, QC… иди ищи баги и обеспечивай качество, едрить.
Сегодня бизнес просит всё так же ОДНОГО чувака, который сделает всё сам и потом автоматизирует. «QA» вы его назовёте или «Big-Bang QA Guru» — всем однородно.
Кто ты, QA-инженер или тестировщик?