🎯Когда задачу можно считать сделанной? С точки зрения руководителя проекта — это задача, которая внедрена и сдана на продуктиве. Для QA-специалиста — это задача, которая прошла проверку. С точки зрения разработчика — это задача, в которой он уже не может при отладке найти ошибки.
Если разработчик написал код, то он ещё не сделал задачу. Впереди проходить смок-тестирование, отрабатывать базовые позитивные и негативные сценарии.
Есть объективная проблема. Хороший разработчик — это созидатель, поэтому он плохо выполняет функцию QC . Забавно, но именно в руках хорошего разработчика начинает правильно работать даже чужой код. Человек просто инстинктивно обойдёт те места, где что-то может сломаться и пойти не так. Пользователи на продуктиве ведут себя не так, и иногда сильно удивляют техническую команду своей фантазией.
QA-специалисты обычно помогают программистам. Например, заранее пишут тесты для задачи и отдают их разработчикам, чтобы они могли использовать их при отладке.
Чаще всего проблемой становятся не нормальные ошибки программиста, а сформированные негативные паттерны поведения, которые могут искажать восприятие целых команд разработки. Например, в месте сопряжения работы разработчика и QC-специалиста возникает негативный паттерн: «Разработка через багфикс». Разработчик говорит, что:
▪ошибки будут всегда, и это нормально;
▪️разработчики — плохие тестировщики;
▪️работа QC-специалиста состоит в поиске ошибок.
После чего разработчик пропускает стадию отладки и отправляет код, который даже смок-тестирование пройти не может, к QC-специалисту. По сути, считает свою задачу сделанной, когда код написан, а не когда отладка выполнена.
🚨Дополнительным фактором является неправильный учёт времени разработки в организации. Нередко затраты на тестирование и багфикс начинают кратно превышать время на разработку. Это первый сигнал о том, что у вас происходит разработка через багфикс.
Кроме того, время на тестирование и исправление обычно ограничено. Из-за этого часто недотестированный функционал уходит на продуктив, где пользователи начинают страдать от частых ошибок.
❗️От того, что вы умеете быстро доставлять дефектный код на продуктив, счастья никому не будет.
У себя мы сделали просто. Оценки и отметки времени делаются в рабочих часах. Задачей считаем только то, что можно потрогать руками (с точки зрения пользователя), поэтому оценка выполнения зачастую выше 4 часов. Задачу программиста воспринимаем сделанной, только когда она прошла тестирование. Багфикс записываем в трудозатраты по задаче. А при передаче задачи на тестирование программист проводит демонстрацию работы функционала. Это организационный способ убедиться в проведении отладки.
👍Рецепт не универсальный, но для заказной разработки подходит.
