From da898fa6168d630088e4e7c8703adaf0fe1893b1 Mon Sep 17 00:00:00 2001 From: Evgenii Morozov <3673110+iinegve@users.noreply.github.com> Date: Thu, 28 Dec 2023 03:39:41 +0300 Subject: [PATCH] =?UTF-8?q?=D0=97=D0=B0=D0=BC=D0=B5=D0=BD=D0=B8=D0=BB=20"?= =?UTF-8?q?=D0=B1=D0=BE=D0=B9"=20=D0=BD=D0=B0=20"=D1=8D=D0=BA=D1=81=D0=BF?= =?UTF-8?q?=D0=BB=D1=83=D0=B0=D1=82=D0=B0=D1=86=D0=B8=D1=8E"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../product-quality/testing/test-optimization/ru.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tlroadmap/roles/technical-lead/product-quality/testing/test-optimization/ru.md b/tlroadmap/roles/technical-lead/product-quality/testing/test-optimization/ru.md index 27b067d9..2766f795 100644 --- a/tlroadmap/roles/technical-lead/product-quality/testing/test-optimization/ru.md +++ b/tlroadmap/roles/technical-lead/product-quality/testing/test-optimization/ru.md @@ -5,7 +5,7 @@ ## Почему ветка важна? Менеджер: - Оптимизирует штат тестировщиков -- Влияет на скорость доставки фичи до боя +- Влияет на скорость доставки фичи до эксплуатации - Понимает, почему тестирование проводится так и занимает столько времени Разработчик: @@ -20,7 +20,7 @@ ## Что будет, если её не делать? - Команда не будет понимать, сколько времени и сколько тестировщиков надо, чтобы снижать критичные риски в продукте: - Риск "раздувания" штата тестировщиков - - Сложно планировать сроки, когда фича будет на бою + - Сложно планировать сроки, когда фича будет в эксплуатации - Непонятно насколько эффективно тестирование ## На кого может быть делегирована? @@ -50,8 +50,8 @@ - Что будет, если ваш продукт будет сложно поддерживать? - Что будет, если ваш продукт будет уязвим для взлома? - Что будет, если в вашем продукте будет сложно разобраться пользователям? -- Как быстро вы поймёте, что у вас баг на бою и оцените, насколько он критичный? -- Как быстро вы исправите баг, который нашли на бою? +- Как быстро вы поймёте, что у вас баг в эксплуатации и оцените, насколько он критичный? +- Как быстро вы исправите баг, который нашли в эксплуатации? Чтобы снизить эти риски, используйте три процесса — тестирование, проверку и мониторинг. @@ -63,13 +63,13 @@ Более подробно про тестирование и проверки — [оригинал](https://www.developsense.com/blog/2009/08/testing-vs-checking/), [перевод](http://qastugama.blogspot.com/2013/09/blog-post_6.html). -Мониторинг — процесс выявления проблем, которые возникают на бою у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код. +Мониторинг — процесс выявления проблем, которые возникают в эксплуатации у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код. Используйте эти процессы все сразу или частично, в зависимости от ваших рисков. Например, вы не прорабатываете детально ТЗ и рискуете не учесть что-то важное. Можно: - снизить риски за счёт тестирования — переложить на него тестирование требований, хранение знаний и выяснение как все работает на самом деле -- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть на бою. +- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть в эксплуатации. Если же вы решили прописать все в ТЗ, то можно меньше тестировать и больше отдать на проверки — как ручные и автоматические. Такое часто бывает в заказной разработке на государственных проектах — утверждённое ТЗ и программа приёмо-сдаточных испытаний.