Вам показали демо. На экране все двигалось гладко, кнопки нажимались, отчет собирался. Вы приняли работу, заплатили, выдохнули. А через месяц бухгалтер приносит цифру, которая не сходится, и выясняется, что при одном редком сценарии система дважды списывает остаток.
Это не значит, что вас обманули. Это значит, что «показали, как работает» и «проверили, что работает» - две разные вещи, и на второй кто-то решил сэкономить. Разбираемся, что такое качество на человеческом языке и почему именно на нем экономить дороже всего.
Что такое контроль качества простыми словами
Контроль качества - это не финальная кнопка «проверить» перед сдачей. Это отдельная работа, где человек намеренно пытается сломать систему до того, как ее сломает ваш реальный день.
Он вводит отрицательное количество. Оставляет обязательное поле пустым. Проводит документ задним числом. Делает возврат на товар, которого уже нет на складе. Запускает два действия одновременно. Разработчик писал программу, чтобы она работала, - тестировщик проверяет, что она не ломается, когда что-то идет не по сценарию. А в бизнесе не по сценарию идет постоянно.
Разница между этими двумя ролями и есть разница между «сдали в срок» и «сдали то, что можно включать в оборот».
Чем «работает у меня» отличается от «протестировано»
«Работает у меня» - это когда разработчик прошел свой собственный маршрут: завел товар, продал, посмотрел отчет. Один путь, чистые данные, спокойный темп. На этом маршруте не бывает ошибок - он его сам и построил.
«Протестировано» - это когда систему прогнали по маршрутам, которых разработчик не закладывал. По вашим граничным случаям: конец месяца, когда все проводят разом; клиент с долгом и предоплатой одновременно; товар, который вернули, переоценили и продали снова. Качество живет именно здесь, на стыках, а не на главной кнопке.
Готовая коробка проходит проверку у вендора - но под усредненный сценарий, тот самый «как у всех». Ровно те ваши операции, из-за которых вы и заказываете систему под себя, вендор не тестировал: их в его модели нет. Значит, отвечать за них на ваших данных все равно кто-то должен - вопрос лишь в том, тестировщик заранее или ваш бухгалтер по факту.
Почему баг в проде дороже
«Прод» - это когда система уже в работе, на живых деньгах и живых клиентах. Ошибка, найденная здесь, стоит не столько, сколько стоит ее починить. Она стоит того, что успела натворить, пока ее не заметили.
Посчитайте на своем процессе, без чужих цифр. Возьмите вероятную ошибку - скажем, неверное списание. Умножьте, как часто срабатывает редкий сценарий, на число операций в день и на число дней до того, как кто-то заметит расхождение. Это объем испорченных данных. Добавьте цену каждой: возврат денег, потерянный клиент, ручная сверка всего периода, штраф, если задело отчетность. И только сверху - стоимость самой правки, которую теперь делают в спешке и в проде, где цена ошибки при ремонте выше.
Сравните это с работой тестировщика на этапе сборки, где та же ошибка ловится на пустой базе и правится за счет исполнителя. Экономия на проверке почти всегда оборачивается тем, что вы оплачиваете тот же дефект дважды, и второй раз - вместе с последствиями.
Как выглядит система, в которую качество заложено по ходу
Утро конца месяца. Ваши люди проводят документы пачками, кто-то ошибается в дате, кто-то дважды жмет «провести». Система не падает и не пропускает ошибку молча: она останавливает дубль, подсвечивает пустое поле, не дает списать больше, чем есть. Бухгалтер видит красное там, где раньше сам ловил бы это через неделю по расхождению.
Так выглядит качество, встроенное в разработку, а не приклеенное в конце. Оно не в отдельном отчете о тестировании - оно в том, что тихих сбоев не происходит, потому что кто-то намеренно их спровоцировал заранее и закрыл.
С чего начать, если доверия к качеству нет
Не обязательно перепроверять всю систему разом. Возьмите один процесс, где ошибка дороже всего, - тот, что трогает деньги или склад. Именно его покрываем проверкой на граничных случаях: перечисляем, что может пойти не так, и прогоняем каждый сценарий на данных, похожих на ваши.
Вы получите не обещание «все надежно», а список: вот что проверили, вот как повело себя в опасных местах, вот что теперь система не даст сделать. Этого достаточно, чтобы понять, как команда относится к качеству, и на фактах решить про следующий процесс.
Что делаем мы
Cloudplus - официальный партнер фирмы «1С» в Узбекистане, юрлицо ООО «Ecommerce». 15+ лет в разработке, 7 из них в Узбекистане, 120+ сотрудников в Ташкенте, 100+ внедрений.
Тестирование у нас - не финальная галочка, а часть работы с самого начала. Мы проверяем систему на ваших граничных случаях, а не на удобном демо-маршруте, и показываем, что именно проверили. Исходники ваши, поэтому и качество проверяемо: вы видите, а не верите на слово.
Про игровую студию APP1: выручка шла с консольных, мобильных и веб-площадок, у каждой свои выгрузки. Свести их в один учет мало - нужно, чтобы цифры сходились при любых расхождениях в исходных данных. Именно на стыках форматов и живет здесь качество.
Что дальше
Назовите один процесс, где ошибка обходится дороже всего. Опишите словами, как он идет сейчас, - ТЗ писать не надо. Мы разберем, где он уязвим, и покажем на ваших данных, как система ведет себя там, где обычно все и ломается.
Ташкент, ул. Буюк Турон, 77. Телефон +998 71 207 71 24. Телеграм @cloudplusss.
- Разработка под процесс - если нужна система, качество которой можно проверить, а не принять на веру.
- Кейс APP1 - как свели выручку с разных площадок в один сходящийся учет.