Первая неделя моей работы тестировщиком закончилась тем, что мебельная фабрика встала. Я предложила ускорить процесс — и моя инициатива остановила производство на несколько дней. Спустя одиннадцать лет я пишу об этом не ради поучений, а потому что мне больно.
Изменения — какие бы они ни были — это всегда сложно. Но российский менеджмент, особенно тот, что вырос из IT‑среды, этого как будто не замечает. Многие из них не прочитали ни одной книги об управлении и планировании — зато искренне верят, что людьми можно управлять как кодом: практики у них — паттерны, люди — функции. Применил лучшие паттерны, задал людям новые функции — всё заработало. Не заработало — заставим писать отчёт. А раз практика сработала в Google, значит, поможет и нам.

Вместо того чтобы оценить свой бизнес, свой процесс и найти подход, который поможет именно тебе, мы хватаем чужое готовое и внедряем его против людей — хотя люди в большинстве случаев и есть основа организации. Я давно в этой теме и пережила, а часто и сама была инициатором, десятков изменений: появление тестирования в процессе, потом автотестирования, внедрение аджайла, скрама, lean и кучи других перетрубаций. И мне больно, что все они повторяют одни и те же ошибки — и мало кто готов это признавать, не то что исправлять. А бездумное внедрение ИИ делает всё то же самое, только максимально быстро.

Дальше — для тех, кто узнаёт себя: ты тот, кто страдает от бездумности и безответственности тех, кто инициирует изменения; ты тот, которому не дают менять процессы дальше своего отдела; ты внедряешь изменения в процессы и уже обжигался об это. Сразу честно оговорю границу: я про процессы и людей, а не про ML‑пайплайн, EDA и PoC. Это другой разговор.

Основной источник багов — процессы. Точнее — то, как люди передают друг другу информацию без потерь. Вернее, то, что без потерь у них как раз не выходит. У каждого своя «нейросетка» со своими весами: очевидное одному для другого — источник сомнений. Сверху рамки: бизнес требует скорости, сотрудники боятся потерять место и статус, начальство боится признать, что чего‑то не знает. С учётом всего этого людям нужно договариваться. И процессы либо помогают, либо мешают.

Две истории про изменения

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

Шла первая неделя моей работы тестировщиком. Мебельная фабрика работала на самописной CRM. Внутри были забиты последовательности операций для изготовления деталей мебели. Техпроцесс меняли вручную, в узком окошке, где операции шли через запятую.Я предложила ускорить: забить данные в Excel столбиком, а потом раскопировать на остальные тридцать процессов, меняя по одной‑две строки из пятнадцати‑двадцати. Мы действительно быстро получили новые процессы и загрузили их.

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

Урок, который я тогда вынесла: ускорять процесс без понимания системы и без плана отката — значит рисковать всем, не имея метрики, которая покажет, что что‑то пошло не так.

Вторая история — про изменение, которое по сути было правильным, а по форме — нет. Шёл шестой месяц. Аутсорс, вотерфлоу: требования известны, релизы расписаны на годы вперёд. Работа тестировщиков распределялась по абзацам ТЗ — каждый писал кейсы по своему абзацу и отправлял отчёт. Кейсы были плохие: не сквозные, не учитывали неочевидные сценарии на стыках.

Когда приезжало руководство организации‑заказчика, я предложила заранее на релиз писать сквозные кейсы, согласовывать их и по ним тестировать. Идею приняли, выделили отдел тест‑аналитиков, и я перешла туда с несколькими людьми.

А потом уволились трое руководителей надо мной и ушла половина команды тестирования. Изменение было правильным, но я провела его через головы тех, кто стоял надо мной, — не продала идею людям, а обошла их. Результат — конфликт.

Дальше еще фирмы и еще ряд процессных изменений с разными исходами.

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

Почему я вообще лезу не в свое дело?

Сейчас выскажу крайне непопулярное мнение, которое вряд ли найдёт отклик у большинства.
Я — QA (Quality Assurance, обеспечение качества). Моя задача — делать процесс качественным, чтобы качественным был результат.

Разница между тремя буквами простая. QT (Quality Testing) — просто тестирование: прогнать сценарии, потыкать кнопки, найти уже готовую ошибку. QC (Quality Control) — контроль качества: проверить готовый продукт на соответствие требованиям и отловить дефект до того, как он уйдёт заказчику. QA — обеспечение качества: настроить конвейер так, чтобы баги не появлялись вообще.

Стандарт отрасли, увы, таков, что, говоря «QA», люди имеют в виду QC, а то и вовсе QT. Под громким словом «обеспечение качества» скрывается контроль или тестирование готового — а вмешиваться в процесс никто не пустит. С позиции QA сложно что‑либо менять, особенно в больших организациях и за границами отдела тестирования.

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

Я истинный фанат ИИ, но с большой осторожностью отношусь к его внедрению в процессы. Это ускоритель. Если внедрить его в место проблем, это просто ускорит генерацию проблем.

Пример, который я видела в найме. Процесс подбора в одной IT‑компании был сломан: HR‑специалисты не разбирались в технологиях и оценивали резюме поверхностно. Когда в этот сломанный процесс добавили ИИ — автоматический отбор, чат‑боты для скрининга, — ошибки не уменьшились, а умножились. ИИ просто ускорил отброс хороших кандидатов.

Правило простое: не автоматизируйте хаос. Сначала выровняйте процесс, потом ускоряйте.
Когда я говорю, что изменения должны быть продиктованы метриками, привязанными к деньгам, а начинать надо с людей, — это не пустая «ии‑фраза». Это мой болезненный опыт, начиная с той самой фабрики.

Ничего нового я здесь не открыла: сорок лет назад Голдратт в теории ограничений сформулировал, что у системы есть узкое место и улучшать надо его, а не всё подряд. Деминг — что большинство проблем лежит в системе, а не в людях. Демарко и Листер — что люди сопротивляются не изменениям, а потере достоинства и контроля. Я лишь прикладываю это к сегодняшнему внедрению ИИ.

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

Изменения не всегда к лучшему

Ниже будет пример изменений которым я не позволила случится. Не потому что «негибкая» и «неготовая к изменениям», а потому что чувствовала что они усугубят проблему, а не решат ее.

Проблема: много инцидентов с прода.
Начальство предложило ввести ревью тест‑кейсов.

Я посчитала во сколько обходится поддержание актуальной тестовой документации:
Классически правильный кейс должен быть атомарным, однозначным и проверять что‑то одно. Возьмём за границу шага кейса одну форму, одну роль и одну цель пользователя (создать заявку, добавить в корзину, удалить документ и тд). При примерно ста пятидесяти шагах таких e2e‑кейсов будет под сто пятьдесят миллионов — комбинаторный взрыв. В зависимости от цели и времени тестирования мы берём свой набор из этих ста пятидесяти миллионов.

Для авторегресса можно сжать сходу до ста пятидесяти (по числу шагов): для последнего шага делаем все проверки сразу и выб ираем путь, которым чаще ходят пользователи. Для мануального регресса — проверяем после каждого шага и начинаем с самого длинного сценария: проходя один кейс, покрываем десять сценариев сразу, и количество сокращается до тридцати. Можно ужать ещё, оценив стоимость каждого кейса: сколько денег потеряет компания, если сценарий не будет работать сутки, и как быстро узнают о проблеме.

Каждый релиз частоты путей и стоимость ошибки переоцениваются заново — с учётом новой функциональности и рынка. Поэтому кейсы регресса меняются каждый релиз. Если всю эту аналитику делать вручную, записывая кейсы в тест‑менеджерские системы, процесс бесконечно дорог — либо даёт результат, который никто не может оценить или исправить.

Внимательный читатель скажет: «Подожди, но пару абзацев назад ты предлагала в целом тоже самое.» И это так. Во‑первых, лет 8 назад я сама придерживалась мнения, что «без тест‑кейсов нельзя тестировать». Во‑вторых, это был аутсорс и тест‑кейсовая документация была обязательством прописанном в договоре между нашей фирмой и фирмой заказчиком. В третьих мы не тянули кейсы из релиза в релиз: протестировали — сдали кейсы — забыли. Да и пользователей не было — одна программа полностью заменялась той что мы разрабатывали в определенный день и час.

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

Более того это был тот самый процесс, который мешал людям договариваться и инцидентов стало больше. Проблема была в фиксированных сроках релиза и когда аналитика и разработка съедали свое время, на тестирование оставалось мало. Баги правили кое‑как на скорую руку, ломая ту часть функционала, которая уже была протестирована. А про баг в аналитике, найденый на этапе тестирования, могли и промолчать, чтобы заново не переписывать кейсы и не перепроходить режим согласований.

Моя мотивация написания статей

Мой опыт хоть и разнообразный: от микро‑бизнеса до биг финтеха все таки сильно ограничен, в том числе собственным восприятием. В том числе восприятием QA, хоть я уже давно им не работаю, но эти воспоминания вызывают много эмоций. Это моя вторая статья и пока я все пишу про боль и «как не надо» внедрять изменения. Я надеюсь дальше писать и о том «как надо». Очень осторожно, не выдавая свои чувства за факты, а приемы, которые где‑то на ком‑то сработали за универсальные. Для этого мне нужно «встать на плечи профессионального сообщества», чтобы сверять свой опыт с опытом тех, кто прошёл глубже меня. А если подобный велосипед уже изобретен, хотелось бы узнать и о нем.