Первая неделя моей работы тестировщиком закончилась тем, что мебельная фабрика встала. Я предложила ускорить процесс — и моя инициатива остановила производство на несколько дней. Спустя одиннадцать лет я пишу об этом не ради поучений, а потому что мне больно.
Изменения — какие бы они ни были — это всегда сложно. Но российский менеджмент, особенно тот, что вырос из 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, хоть я уже давно им не работаю, но эти воспоминания вызывают много эмоций. Это моя вторая статья и пока я все пишу про боль и «как не надо» внедрять изменения. Я надеюсь дальше писать и о том «как надо». Очень осторожно, не выдавая свои чувства за факты, а приемы, которые где-то на ком-то сработали за универсальные. Для этого мне нужно «встать на плечи профессионального сообщества», чтобы сверять свой опыт с опытом тех, кто прошёл глубже меня. А если подобный велосипед уже изобретен, хотелось бы узнать и о нем.
ссылка на оригинал статьи https://habr.com/ru/articles/1104702/