Lessons learned in software testing – уроки 1 и 2.

0atermath • 16 Oct 2007 • Переводы, Тестирование

Три года назад, в начале карьеры тестировщика, многое было мне неизвестно: я ворошил книги, зачитывался методологиями, но не было системы — того, что объединило бы все кусочки в единую картину. Не хватало представления о месте тестировщика в команде, о весе его вклада в работу, банального ощущения того, что ты стоишь на правильном пути.

Книга «Lessons learned in software testing» как раз протягивает ниточки между разрозненными соображениями. И хоть она рекомендуется уже опытным тестировщикам — новичок в ней найдет тоже много интересного, прежде всего для понимания философии тестирования.

Урок 1. Светить всегда, светить везде.

Проект это как езда на автомобиле: иногда это путешествие на дачу ясным днем, в большинстве же случаев это вождение грузовка по незнакомой горной дороге в темную ночь. И в таких поездках нужно включать фары. Вот тестировщики и есть «фары» проекта. Менеджеры и разработчики могут до хрипоты спорить над картой, но только вы можете дать им понять где они, куда хотят попасть и насколько близок обрыв.
Конкретные обязанности группы тестирования различаются на всех проектах, но основная задача неизменна: тестирование проводится для сбора информации. И самые серьезные решения по проекту/продукту делаются на основе этой информации.

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

Урок 2. Задача¹ определяет ваши действия даже в мелочах

Задача тестировщика может зависеть от конкретной компании, отрасли, проекта, конкретной команды . Необходимость формирования общих практик тестирования на фоне технических и культурных различий между профессионалами в данной области — это, пожалуй, один из самых серьезных вызовов развитию тестирования как искусства (craft). Большая часть этих различий объясняется разными целями команд : так, например, для одной команды тест-план это вспомогательный инструмент, и может быть наскоро набросан на салфетке. Для других же тест-план — это часть продукта, который поставляется вместе с системой, а, значит, он должен отвечать ряду требований по формату, содержанию, объему.

Любое из следующих требований может определять ваши задачи. Что в команде ожидают от вас?

• Быстро находить важные дефекты
• Производить общую оценку качества продукта
• Подтверждать, что продукт соответствует определенным стандартам
• Помогать клиентам улучшить качество и тестируемость продукта
• Гарантировать соответствие тестового процесса отчетным стандартам
• Рассказывать клиентам о тестировании и о взаимодействии с тестировщиками
• Следовать определенному набору методов и/или правил
• Помогать предсказывать и контролировать стоимость поддержки
• Помогать клиентам улучшить процессы
• Работать на минимизацию времени, затрат и нежелательных эффектов
• Делать вообще что угодно — лишь бы удовлетворить конкретные нужды клиентов
• …

Если вы тратите кучу времени и усилий на требования, реализация которых клиентам не нужна, то вы работаете «в стол» — в лучшем случае вы непродуктивны. Определите свою задачу с менеджером, уточните. До тех пор, пока вы не придете к согласию в видении ваших задач, у вас не будет базиса для работы.

Что делать, когда не знаешь, что делать? Один из ответов — пересмотреть задачи. Именно они определяют круг проблем, над которыми вы работаете. Если вы четко представляете себе свою задачу, то можете определить, что делать дальше. Также вы всегда сможете на пальцах объяснить окружающим, чем вы занимаетесь и зачем. Если вы не можете разобраться с предстоящей работой — это свидетельство того, что надо обратиться к начальству

Что делать, когда известно, что точно надо делать? По крайней мере хоть раз пересмотреть свой замечательный план, чтобы убедиться, что вы не сосредоточились только на одной части задачи, забыв про остальные.
Замечательные два вопроса, всю мощь которых лично я понял только к концу первого года работы. Ненужная работа — это роскошь, которую тестировщик, как и разработчик, не может себе позволить. Отсюда как раз вытекает необходимость четкого руководства ведением проекта и/или тесные взаимоотношения в команде.

¹ В оригинале использовано более звучное слово — миссия