Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Вопрос от тестировщика:

Как быть с багами прода? Когда менеджмент спрашивает "Ты это вообще тестировал?", что мне отвечать?

Когда менеджмент спрашивает "Почему ты не нашел этот баг?", первый шаг – внутри себя взять на себя ответственность за поиск багов, но не обязательство найти все баги до единого. Это, конечно, похвальное стремление, но такое обязательство неразумно, и менеджмент не должен требовать его т вас.

Помните: как тестировщики, мы не кладем в продукт никаких багов! Большая часть багов скрыта – и эмпирически, любой никем – досель – не найденный баг был спрятан достаточно глубоко – даже люди, которые его туда положили, не смогли его найти.

Следующий шаг – встать на позицию того, что вопрос может быть разумным; менеджеру, возможно, нужны объяснения, а не оправдания или защита. Конечно, тон вопроса и манеры спрашивающего могут предполагать обвинение, но пока что отложим это в сторонку.

Дайте трезвую и честную оценку своей работе. Когда вы размышляли над проблемой прода, мелькнуло ли в голове что-то такое, что вы, с вашей точки зрения, должны были заметить? Или же вы поступали разумно, работали ответственно и тестировали тщательно? Можно ли дать утвердительный ответ на оба вопроса?

Очень важно при такой оценке спросить себя, что вы на самом деле делали. Делали ли вы что-то продуктивное – вроде исследования и отчетности по другим багам, - но в то же самое время разрушительное для поиска именно этого бага? Делали ли вы что-то важное, вроде покрытия частей продукта, подверженных риску, но в результате нашли относительно немного багов? Настраивали ли вы инструменты, которые повышали эффективность вашего тестирования, что привело к нахождению важных проблем?

Или же вы были заняты чем-то менее полезным? Например…

• Тратили ли вы больше времени на исследование и отчетность по багам, нежели это необходимо? Возможно, миппинг – быстрая беседа с разработчиком или менеджером – принес бы больше пользы.
• Покрывали ли вы сравнительно неважные части продукта? Возможно, стоит чаще возвращаться к тест-миссии вместе с клиентами, чтобы ваше тестирование лучше концентрировалось на значимых для них проблемах.
• Создавали ли вы очень формальные, процедурно структурированные тест-сценарии, которые не были вам нужны, или стали позднее невалидными из-за перемен в продукте? Может, набор списков рисков и чеклисты были бы лучшим вариантом.
• Создавали ли вы автоматизированные проверки, которые просто поверхностно убеждались, что все в порядке (что, возможно, должны были сделать разработчики)? Сократил ли этот труд время на глубокое изучение продукта и поиск менее явных багов? Потратили ли вы много времени на борьбу с интерпретацией, дебагом и поддержкой проверок?
• Если вы делали что-то непродуктивное, было ли это вашим выбором, или обязанностью, навязанной вам менеджментом?

Отвечая на вопрос, держите в уме эти варианты. Если вы и в самом деле пропустили что-то, что с вашей профессиональной точки зрения должны были заметить – если вы просто что-то упустили или сделали ошибку – признайте это, и дайте понять, что вы извлечете из ситуации урок.

Но, возможно, вы действовали разумно и делали другие значимые вещи, и можете обосновать свою работу. Возможно, урок из ситуации могут извлечь все:

• Возможно, нам нужен более тестируемый продукт.
• Возможно, нам нужно улучшить доступ к информации или к разработчикам. Возможно, нам нужна помощь от большего количества людей с различным опытом и навыками.
• Возможно, разработчикам нужно больше времени на проверку своей собственной работы. Возможно, каждому разработчику нужен напарник.
• Возможно, если бы продукт не был так чертовски забагован, мы бы потратили меньше времени на исследование багов и отчетность по ним, что позволило бы нам выкроить время на нахождение этого бага.

Суровая, холодная правда о жизни и тестировании: никто не может сделать все, и никто не может делать все на пять с плюсом. Учитывая это, и вы и менеджмент должны принять как данность, что вы просто не можете обязаться найти все до единого баги – и что мы можем чему-то научиться у тех багов, о которых мы не знали до этого дня.

Обсудить в форуме