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