Проверка — это отдельная инженерная задача
На днях я решал одну задачу: нужно было сверить аббревиатуры ячеек в базе данных с последней утвержденной методологией. Вроде бы ничего сложного, но на деле всё оказалось иначе.
Где прячется дьявол
Около 80 ячеек. Они дублируются, пересекаются в других столбцах и подтягиваются из разных систем. В методологии сущность называется одним образом, в базе данных — вторым, в Weeek — третьим. Чтобы проверить это эффективно, мне пришлось сначала придумать сам алгоритм проверки. И только потом — запустить его.
Два ключевых вопроса, на которые отвечает хорошая проверка
— Всё ли соответствует последнему подтверждённому решению?
— Есть ли ошибки и проблемы, которые нужно устранить?
Звучит просто. Работает сложно.
Почему исполнитель не должен проверять себя сам
Разработчик или программист может провести проверку. Поначалу — вполне нормально. Но в какой-то момент, когда система разрастается, эту работу должен делать отдельный человек — инженер по качеству.
Причин две. Первая: у него уже сформирован нужный майндсет и инструментарий. Вторая, и она важнее: у него есть свежий взгляд. Тот, кто сам создавал систему, уже не видит её глазами новичка — он видит то, что хотел сделать, а не то, что получилось на самом деле.
Разделение ролей «исполнитель — тестер» — это не бюрократия. Это инженерная необходимость.