Мы считаем, что очень важно понимать, что измеряя качество, мы не влияем на него.
или выше речь идет про качество продукта, а не конкретных задач/фич (как ниже)?
Тут просто. Каждый раз, когда мы измеряем качество, находим баги или успешно проводим тесты мы не увеличиваем ни качество продукта вообщем, ни качество конкретной итерации. Качество итерации вырастет, если: 1) Продакт / заказчик решит что надо исправить баг (не всегда так происходит) 2) Разработчик исправит этот баг
Контролируя качество мы создаём артефакты, которые используются в процессе обеспечения качества
очень смешно, учитывая что это базовейшая база, которая в любой литературе и на любых курсах сразу с первых же страниц в лицо прилетает.
В хорошей литературе действительно пишут в основном правильно, вот только не в каждый книжке вы найдёте определение процесса QA.
А вот с курсами ситуация хуже. В описании многих курсов вы увидите, что понятия QA и тестирование перепутаны
Во вторых - зачем вы задаете вопросы такие вопросы на собеседовании?
Компетенция в обеспечении качества для нас важна. Очевидно, что сотрудники, которые способно позитивно влиять на команду и на процессу ценны. Поэтому мы говорим о опыте кандидата в сфере обеспечения качества
Ох, да, думали добавить в эту статью и это рассуждение. Но тут есть и "QA-инженер", и "специалист по обеспечению качества" и что-нибудь ещё... А ведь между "инженер" и "специалист" есть разница, и её тоже надо объяснять... Короче прям отдельная тема)
Роли Scrum-мастер и QA-инженер действительно похоже, но Scrum-мастер не должен обладать инженерными навыками обеспечения качества. Условно линтер scrum-мастер не настроит. Более того, скрам мастерам зачастую рекомендуют не делать изменения самим, а подталкивать команду к изменениям. Так что разница есть
Согласен, наймом и развитием мы тоже сильно влияем на качество. Более того, нам не нужно, чтобы конкретный Лёша становился Васей, нам нужно чтобы все наши сотрудники развивались. А как это сделать? Только работать с процессами: выстраивать качественный найм, создавать инструменты для развития внутри компании...
В том то и дело, что мы относимся к словам QA и QC не как к "ярлыкам". Для нас это процессы, которыми мы занимаемся. И занимаемся мы ими не чтобы набить цену, а чтобы приносить пользу)
Мне не нравится такое определение модульного тестирования. Оно очень широкое и в него можно запихнуть много примеров (например пример данный в этой статье). Вообще фраза "отдельная часть приложения" недостаточно конкретная. Например фронтенд можно назвать отдельной частью приложения. Неужто мы будем считать что тестирование всего фронтенда приложения это модульное тестирование?
Отсюда идёт и неправильно определение интеграционного тестирования
Интересно было почитать. В месте, где речь идёт о скорости прогона тестов, речь идёт о JS? Кажется, что в разных языках скорость прогона одинаковых тестов может отличаться. А ещё для селениума скорость прогона в хеадлес браузерах и обычных наверняка отличается.
Тут просто. Каждый раз, когда мы измеряем качество, находим баги или успешно проводим тесты мы не увеличиваем ни качество продукта вообщем, ни качество конкретной итерации.
Качество итерации вырастет, если:
1) Продакт / заказчик решит что надо исправить баг (не всегда так происходит)
2) Разработчик исправит этот баг
Контролируя качество мы создаём артефакты, которые используются в процессе обеспечения качества
Отличная статья, согласен с многими мыслями, которые тут написаны. Спасибо!
p.s. ох сейчас будет тут комментариев в стиле "тестировщики опять курят..."
В хорошей литературе действительно пишут в основном правильно, вот только не в каждый книжке вы найдёте определение процесса QA.
А вот с курсами ситуация хуже. В описании многих курсов вы увидите, что понятия QA и тестирование перепутаны
Компетенция в обеспечении качества для нас важна. Очевидно, что сотрудники, которые способно позитивно влиять на команду и на процессу ценны. Поэтому мы говорим о опыте кандидата в сфере обеспечения качества
Почему? Процессы QC и QA трубуют разных компетенций, разного склада ума. Если у вас душа лежит к контролю качества - так занимайтесь им.
Спасибо, рад, что оценили!
А мы привели их определения, они действительно самые понятные. Но даже в силабусе было нахватало примеров
К сожалению ИТ эта область в которой нужно развиваться, чтобы оставаться на том же уровне. Вместе с индустрией. Иначе просто отстанем.
И я не говорил что занимаюсь этим один) Просто развивать надо в том числе и тестировщиков, а у кого как не у тестировщиков должна быть эта экспертиза?
В этом они похожи с Scram-мастером. Цель хорошего Scram-мастера - стать не нужным.
Если QA-инженер смог всё сделать в одной команде, он может пойти в другую. Компании развиваются, команд становится больше, светлые головы везде нужны
Спасибо, рад, что вам понравилось!
Без процесса QC обойтись кажется нельзя. Примеров таких я просто не знаю. А вот без отдельной роли, которая занимается только QC обойтись точно можно.
Ох, да, думали добавить в эту статью и это рассуждение. Но тут есть и "QA-инженер", и "специалист по обеспечению качества" и что-нибудь ещё...
А ведь между "инженер" и "специалист" есть разница, и её тоже надо объяснять... Короче прям отдельная тема)
Роли Scrum-мастер и QA-инженер действительно похоже, но Scrum-мастер не должен обладать инженерными навыками обеспечения качества. Условно линтер scrum-мастер не настроит. Более того, скрам мастерам зачастую рекомендуют не делать изменения самим, а подталкивать команду к изменениям. Так что разница есть
Согласен, наймом и развитием мы тоже сильно влияем на качество. Более того, нам не нужно, чтобы конкретный Лёша становился Васей, нам нужно чтобы все наши сотрудники развивались. А как это сделать? Только работать с процессами: выстраивать качественный найм, создавать инструменты для развития внутри компании...
Я этим последние несколько лет и занимаюсь...
В том то и дело, что мы относимся к словам QA и QC не как к "ярлыкам". Для нас это процессы, которыми мы занимаемся. И занимаемся мы ими не чтобы набить цену, а чтобы приносить пользу)
Мне не нравится такое определение модульного тестирования. Оно очень широкое и в него можно запихнуть много примеров (например пример данный в этой статье). Вообще фраза "отдельная часть приложения" недостаточно конкретная. Например фронтенд можно назвать отдельной частью приложения. Неужто мы будем считать что тестирование всего фронтенда приложения это модульное тестирование?
Отсюда идёт и неправильно определение интеграционного тестирования
Интересно было почитать. В месте, где речь идёт о скорости прогона тестов, речь идёт о JS? Кажется, что в разных языках скорость прогона одинаковых тестов может отличаться. А ещё для селениума скорость прогона в хеадлес браузерах и обычных наверняка отличается.