Очень интересно читать подобные успешные(или не всегда) истории, приятно видеть, что иногда бизнесу реально донести важность таких активностей.
Отдельный респект за кукушку, у нас было что-то похожее, но делалось не слишком осознанно и централизованно.
Поделюсь и своей историей ZBP с предыдущего проекта -
Начальство начальства пришло с идеей уменьшения кол-ва багов и дало добро на уменьшение скорости разработки новых фич (ситуация из ряда фантастики, конечно, но речь про внутренние сервисы и про большое кол-во претензий к ним)
После анализа всех очередей в трекере нашли порядка 1200 багов, каждый был воспроизведён\закрыт и прошёл обсуждение с менеджерами относительно баг/не баг и приоритета. На всё про всё ушло примерно 4 недели и на выходе получилось порядка 900 багов.
Каждый месяц была примерная цель уменьшать общее кол-во багов на 10% (включая новые), которую мы успешно профакапили, но примерно за 6 месяцев сократили кол-во в половину.
Важную часть сыграл не только фикс багов, но и разбор всех новых проблем по пятницам, где мы нашли в процессах дыры (например, сделали адекватный код фриз за сутки до релиза)
Чем закончилась история, к сожалению, не знаю, т.к. самовыпнулся на мороз :)
Как по мне - лучше нормализовать и улучшить процессы(затащить на проект код ревью, юнит тесты, автотесты) тем самым предупреждая появление новых багов на проде, нежели фиксить P3 и P4, которые в один прекрасный момент просто уйдут с редизайном.
Обязательное наличие ISTQB (или brainbench и прочих QA сертификаций) — отличный способ продать своего гребца подороже. В начале своей карьеры на одной из галер за сам факт сдачи Foundation ISTQB обещали повышение и вообщем то это был единственный плюс от сертификации за всё время.
Я не уверен, что заучивание терминов не всегда совпадающих с реальностью, может реально влиять на эффективность рядового тестировщика и честно считаю трату 100 евро (а теперь он, оказывается, уже 150 евро) напрасной.
Если учесть, что сертификат ещё и переподтверждать нужно через 5 лет после получения, то становится вообще грустно.
Тут стоит напомнить, что даже если уровнять убер-бомбил и таксопарки в плане налогов и законов, то убер сможет выехать из ситуации на уровне сервиса. Буквально 3 года назад факт отсутствия навигатора в машине таксопарка считался нормой (с тех пор в желтых такси не катался, спасибо), а хамовитость и прочие сопутствующие а-ля «э, смотри голосуют, давай я остановлюсь, подкину их если по дороге» никуда у российских таксистов не пропадут, т.к. это давно сформированный образ, с которым никто не планирует бороться.
Есть подозрение, что в данном случае речь не про обычную дыру в заборе, а про забор, сквозь который можно пролезть лишь облив его кровью девственницы под высокой луной.
В любом продукте будут дыры, которые разработчики и безопасники предусмотреть на момент релиза не смогли.
И если говорить про своевременность, то свой забор мы починили и, как хорошие соседи, предложили владельцу ближайшего участка тоже починить забор, т.к. производитель у заборов одинаков. Но вот беда, сосед сказал, что ему лениво прислушиваться к нашим советам и вообщем он сам будет решать, что ему делать со своим забором.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Очень интересно читать подобные успешные(или не всегда) истории, приятно видеть, что иногда бизнесу реально донести важность таких активностей.
Отдельный респект за кукушку, у нас было что-то похожее, но делалось не слишком осознанно и централизованно.
Поделюсь и своей историей ZBP с предыдущего проекта -
Начальство начальства пришло с идеей уменьшения кол-ва багов и дало добро на уменьшение скорости разработки новых фич (ситуация из ряда фантастики, конечно, но речь про внутренние сервисы и про большое кол-во претензий к ним)
После анализа всех очередей в трекере нашли порядка 1200 багов, каждый был воспроизведён\закрыт и прошёл обсуждение с менеджерами относительно баг/не баг и приоритета. На всё про всё ушло примерно 4 недели и на выходе получилось порядка 900 багов.
Каждый месяц была примерная цель уменьшать общее кол-во багов на 10% (включая новые), которую мы успешно профакапили, но примерно за 6 месяцев сократили кол-во в половину.
Важную часть сыграл не только фикс багов, но и разбор всех новых проблем по пятницам, где мы нашли в процессах дыры (например, сделали адекватный код фриз за сутки до релиза)
Чем закончилась история, к сожалению, не знаю, т.к. самовыпнулся на мороз :)
Как по мне - лучше нормализовать и улучшить процессы(затащить на проект код ревью, юнит тесты, автотесты) тем самым предупреждая появление новых багов на проде, нежели фиксить P3 и P4, которые в один прекрасный момент просто уйдут с редизайном.
Я не уверен, что заучивание терминов не всегда совпадающих с реальностью, может реально влиять на эффективность рядового тестировщика и честно считаю трату 100 евро (а теперь он, оказывается, уже 150 евро) напрасной.
Если учесть, что сертификат ещё и переподтверждать нужно через 5 лет после получения, то становится вообще грустно.
В любом продукте будут дыры, которые разработчики и безопасники предусмотреть на момент релиза не смогли.
И если говорить про своевременность, то свой забор мы починили и, как хорошие соседи, предложили владельцу ближайшего участка тоже починить забор, т.к. производитель у заборов одинаков. Но вот беда, сосед сказал, что ему лениво прислушиваться к нашим советам и вообщем он сам будет решать, что ему делать со своим забором.