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