Почему разработчики иногда отказываются исправлять баги
Меня зовут Михаил, и я мануальный тестировщик. В этом материале я собрал коллекцию из отказов чинить баги, которые слышал от разработчиков.
Все мы сталкиваемся с отказами в исправлении ошибок. Иногда они обоснованны, а иногда — нет. Но избежать их практически невозможно, даже работая в команде с опытными и ответственными специалистами. Чтобы отказы не пугали и можно было дальше заниматься улучшением качества продукта, я собрал эти примеры. В материале расскажу о способах, которыми разработчик может отказать вам в исправлении бага или изменении реализации.
Почему это важно? Проект создают люди, и одного только тестирования программного обеспечения может оказаться недостаточно, чтобы достигнуть нужного качества продукта. Ведь в широком смысле тестировщик отвечает за построение системы качества на проекте, а это несколько более широкое понятие, чем тестирование того или иного функционала. И чтобы построить такую систему контроля качества, необходимо анализировать не только события на проекте, но и наблюдать за людьми, которые его реализуют. Именно на основе таких наблюдений и составлен этот далеко не исчерпывающий список отказов.
Иллюстрация Марии Рыбак
Коллекция отказов
«Это очень сложно / долго». Правильно этот аргумент должен звучать так: «Мне неохота этим заниматься». Но редко кто так открыто говорит. Адекватное оценивание временных затрат на проекте очень важно. Иногда логика бизнеса может подразумевать, что что-то слишком долгое нужно оставить на потом, чтобы не замедлять прогресс в других частях проекта, особенно на этапе прототипирования. Но как же часто разработчики прибегают к этой отмазке, даже не вникнув в суть задачи.
Тут поможет понимание того, как проект устроен «под капотом». Чем глубже это понимание у тестировщика, тем сложнее ввести его в заблуждение по поводу сроков, необходимых на те или иные изменения, потому как чаще всего замечания по переделке появляются на этапе тестирования.
«Это делал не я» или «Это было сделано до меня». Размытие ответственности происходит практически на любом проекте, где работает больше двух-трех человек. Идеально, когда границы ответственности между разработчиками четко очерчены и у каждой части проекта есть ответственный за нее человек. Но на практике, особенно на крупных проектах, так бывает нечасто. Или обратная ситуация, когда все делают всё.
Найти крайних в этом случае бывает сложно. Если ответственность на себя брать никто не хочет, то приходится ее навешивать и просить поправить баг не того, кто накосячил, а того, кто свободен или способен исправить баг.
«Объясни как, тогда сделаю». Ходят легенды, что есть проекты с исчерпывающей документацией, но я про такие читал только в книгах и никогда не видел своими глазами. Однажды мы реализовывали проект внутреннего информационного портала для крупной международной корпорации. Этот портал содержал подробные инструкции о том, что делать в той или иной ситуации, и даже имел цветовую дифференциацию для того, чтобы сотрудники разных отделов быстро находили информацию по их профилю. Но какой же путанной и безалаберной была документация, описывающая, как это все должно работать.
Мозговые штурмы — это, конечно, часть нашей ежедневной работы. Часто разработчики и вправду не могут представить, какая реализация подходит лучше, и делегируют полномочия по ее выбору. Но также часто они ленятся или перекладывают ответственность. В таких случаях помогает опыт: чем больше проектов было реализовано, тем больше вариантов реализаций было испробовано. Какую-то из них можно использовать и на новом проекте.
Еще помогает посмотреть на проект в целом. Часто бывает так, что разработчик за решением узкой задачи не видит полной картины, и помочь с этим может тестировщик, который смотрит на проект под всеми углами.
«Так никто не делает». В широком смысле это означает: «Я так еще никогда не делал». Обычно такое можно услышать после фразы из предыдущего пункта в ответ на описание реализации, которая тебе видится оптимальной.
Идеально в таких случаях помогает ссылка на проект, в котором уже применяли такую реализацию. Но это, если под рукой есть такая библиотека из проектов. Еще помогает внешняя экспертиза. Можно обратиться к другому разработчику с просьбой оценить возможность реализации. Теперь ситуация будет не «мнение против мнения», а «два знания о том, что реализация возможна, против одного нежелания ее применять».
«Это невозможно». Это более сильная версия аргумента из предыдущего пункта. Когда я сталкиваюсь с таким утверждением, у меня возникают две противоположные мысли. Первая — утверждение одного знакомого программиста из Apple, что в программировании возможно все, что не перечит логике, а ограничителями выступают только время и деньги. А вторая — браузер Internet Explorer. Кое-что в нем и вправду невозможно.
Тут также поможет ссылка на реализацию или мнение эксперта о том, что она все же возможна.
«В спеке про это не сказано». Спек — это последний довод королей. Или как там обычно говорят? Документация на проекте — важный источник требований, но, как уже писалось выше, далеко не исчерпывающий. Документацию пишут люди, и они тоже могли забыть, пропустить, не подумать о каком-то пользовательском сценарии. В конце концов, проект развивается и может банально перерасти свой первоначальный спек. А еще многие вещи могут быть оставлены за скобками, как сами собой разумеющиеся.
В таком случае понадобится аргументация, почему на проекте нужно применить ту или иную реализацию. Если ее не хватает, то приходится поднимать этот вопрос уже на уровень менеджера.
«Сказали сделать только это». Всегда представляю себе хирурга, который из двух пулевых отверстий зашил только одно, так как ему не сказали, что второе пациенту мешает. Чаще всего разработчики так говорят, если доделывают за кем-то или переделывают старый проект. Они как бы говорят: «Я и так вымазался в этом легаси и больше в него не полезу без веской причины».
В таких случаях я обычно взываю к чувству прекрасного: раз уж попал проект в руки, то стоит сделать его лучше, чем он был до этого. Даже если предыдущий создатель делал его явно не руками. Иногда срабатывает, иногда нет.
«Я согласовал такую реализацию с менеджером». С одной стороны, разработчик все сделал хорошо и ответственность на себя взял менеджер. С другой стороны, иногда реализация такая, что или менеджер ничего не понял, или разработчик ему голову запудрил своим «не получится, сложно, долго» и далее по списку.
Помогает твердая уверенность в ошибочности текущей реализации и беседа с менеджером, утвердившим ее. Важно в таких случаях объяснить максимально просто и максимально быстро, что не так и как можно исправить.
«Я не знаю, как это делать». В интернете это называют «троллинг тупостью». Чаще можно услышать от новичка, но бывает так, что и более опытные разработчики не брезгуют так сказать. Независимо от того, искреннее ли это незнание или банальное нежелание, поможет исследование проблемы.
Нужно гуглить, раз разработчик в тупике, искать примеры на том же Stack Overflow. Консультироваться с другими разработчиками. Находить обходные решения. Неопытный разработчик будет благодарен вам за помощь, ленивый будет уязвлен и перестанет так открыто манипулировать. Ну а тестировщик узнает что-то новое и закроет проблему на проекте.
«А что, я должен?» К счастью, редко встретишь такой ответ на просьбу что-то на проекте починить или переделать. Но бывает, что и такое случается. Сразу хочется воскликнуть «Если не мы то, кто?».
Но более действенной тут будет апелляция к менеджеру. Это уже его зона ответственности: кто, что, кому должен на проекте. Попытки убедить человека, что исправление багов — это часть его работы скорее приведет к личному конфликту, чем позитивному результату.
Итог
На примере такого совсем не исчерпывающего списка отказов от разработчиков я попытался показать, что нежелание исправлять баги или менять реализации можно и даже нужно преодолевать. Иногда баги бывают незначительные и на них можно махнуть рукой, иногда баги бывают такие, что за них нужно биться до конца. В одной из компаний в попытке исправить баг я последовательно прошел путь от разработчика, который отказался его чинить, до продюсера проекта через лида тестирования, менеджера по тестированию, директора по тестированию и менеджера проекта. Возможно, это экстремальный пример, но, кроме тестировщика, на пути багов к пользователям больше никого нет.
Найкращі коментарі пропустити