Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Заменил "бой" на "эксплуатацию" #423

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Заменил "бой" на "эксплуатацию" #423

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions tlroadmap/roles/technical-lead/product-quality/testing/test-optimization/ru.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
## Почему ветка важна?
Менеджер:
- Оптимизирует штат тестировщиков
- Влияет на скорость доставки фичи до боя
- Влияет на скорость доставки фичи до эксплуатации
- Понимает, почему тестирование проводится так и занимает столько времени

Разработчик:
Expand All @@ -20,7 +20,7 @@
## Что будет, если её не делать?
- Команда не будет понимать, сколько времени и сколько тестировщиков надо, чтобы снижать критичные риски в продукте:
- Риск "раздувания" штата тестировщиков
- Сложно планировать сроки, когда фича будет на бою
- Сложно планировать сроки, когда фича будет в эксплуатации
- Непонятно насколько эффективно тестирование

## На кого может быть делегирована?
Expand Down Expand Up @@ -50,8 +50,8 @@
- Что будет, если ваш продукт будет сложно поддерживать?
- Что будет, если ваш продукт будет уязвим для взлома?
- Что будет, если в вашем продукте будет сложно разобраться пользователям?
- Как быстро вы поймёте, что у вас баг на бою и оцените, насколько он критичный?
- Как быстро вы исправите баг, который нашли на бою?
- Как быстро вы поймёте, что у вас баг в эксплуатации и оцените, насколько он критичный?
- Как быстро вы исправите баг, который нашли в эксплуатации?

Чтобы снизить эти риски, используйте три процесса — тестирование, проверку и мониторинг.

Expand All @@ -63,13 +63,13 @@

Более подробно про тестирование и проверки — [оригинал](https://www.developsense.com/blog/2009/08/testing-vs-checking/), [перевод](http://qastugama.blogspot.com/2013/09/blog-post_6.html).

Мониторинг — процесс выявления проблем, которые возникают на бою у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.
Мониторинг — процесс выявления проблем, которые возникают в эксплуатации у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.

Используйте эти процессы все сразу или частично, в зависимости от ваших рисков.

Например, вы не прорабатываете детально ТЗ и рискуете не учесть что-то важное. Можно:
- снизить риски за счёт тестирования — переложить на него тестирование требований, хранение знаний и выяснение как все работает на самом деле
- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть на бою.
- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть в эксплуатации.

Если же вы решили прописать все в ТЗ, то можно меньше тестировать и больше отдать на проверки — как ручные и автоматические. Такое часто бывает в заказной разработке на государственных проектах — утверждённое ТЗ и программа приёмо-сдаточных испытаний.

Expand Down