Топ-20 вопросов и ответов на собеседованиях на тестировщика, QA Engineer 

Спасибо за оценку! В работе такое было и не раз, релизили с багами и релизим до сих пор. Но алгоритм работы с такой ситуацией разнится от проекта до проекта. Сейчас я работаю на проекте, где уровень покрытия продукта автотестами лучший в моей практике ( я в IT с 2007 года). 97% покрытия кода unit/integration тестами и всего 10 обособленных end-to-end тестов, которые покрывают важные для бизнеса customer use cases процентов на 90. Это привело к тому, что если даже мы перед самым релизом находим баг, он мелкий и незначительный (все значительное покрыто тестами). Мы просто делаем релиз по плану, а hot fix (исправление бага) выкатываем следом уже через пару часов. Уровень автотестов поддерживается на таком уровне, потому что Тестировщики тоже свои автотесты пишут в код продукта в виде unit/integration тестов. Такие тесты быстрые, стабильные, всегда актуальные и их поддерживают все инженеры. Так как когда разработчик вносит изменения в свою ветку, система (CircleCi) автоматически прогоняет тесты, и если какой-то тест нужно исправить для соответствия обновлениям, тут же правит, иначе Github просто не даст ему вмерджить свою ветку в релиз. Кроме того, в CircleCi прописано правило, что ни один PR не может снижать уровень покрытия тестами ниже 94%, поэтому автотесты пишутся всегда, и все за ними следят. (уровень unit тестов не моя заслуга, когда я пришла на проект, он был в таком классном состоянии, я создала end-to-end тесты, и мои усилия - поддерживать проект на высоте и развивать дальше) Когда проекты были с уровнем автоматизации ниже, и я сама была менее опытна, я пользовалась тем способом, который писала в видео: оценивала риски, какие будут последствия от такого релиза, предлагала варианты действий (на столько на сколько получается) и "отдавала на откуп" продакт менеджеру. По правде говоря, окончательное решение здесь всегда за PM-ом, это тот человек, который знает клиентов и их настроения. Были случаи когда PM прислушивался, спрашивал у разработчиков как быстро исправим баг и релиз немного откладывали. Это, конечно же, в случае действительно критически опасных багов и огромная редкость. Если баг не сильно "вредоносный", обычно всегда стремились релизить в срок и следом сразу готовили "hot fix". В таких проектах релиз более вероятно откладывали по причине неготовности функционала в том виде, котором обещали его выпустить, баги средней и малой тяжести не были проблемой. Но оставались "негласным минусом" в карме тестировщика, к сожалению, нравы еще были незрелые))) Большой получился ответ. Классный вопрос, спасибо Вам за него))

Здравствуйте. В интернете все бывает, голосов похожих много и говорят, у меня запоминающийся голос, но там была точно не я, хотя бы потому что я не знаю кто это :)

Что за вещь?