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).
 
-Мониторинг — процесс выявления проблем, которые возникают на бою у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.
+Мониторинг — процесс выявления проблем, которые возникают в эксплуатации у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.
 
 Используйте эти процессы все сразу или частично, в зависимости от ваших рисков.
 
 Например, вы не прорабатываете детально ТЗ и рискуете не учесть что-то важное. Можно:
 - снизить риски за счёт тестирования — переложить на него тестирование требований, хранение знаний и выяснение как все работает на самом деле
-- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть на бою.
+- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть в эксплуатации.
 
 Если же вы решили прописать все в ТЗ, то можно меньше тестировать и больше отдать на проверки — как ручные и автоматические. Такое часто бывает в заказной разработке на государственных проектах — утверждённое ТЗ и программа приёмо-сдаточных испытаний.