Home

Автор: Наталья Руколь, ведущая Школы Тест-Менеджеров, очередной запуск которой начнется 20 мая.

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

Как это произошло? Как избежать подобных ситуаций в будущем? Как реабилитировать своё доброе имя перед коллегами?

Я уже рассказывала о пропуске ошибок глазами тестировщика. А в этой статье давайте разберёмся с позиции тест-менеджера: какие возможные проблемы приводят к пропускам, и каковы способы их решения.

Причины пропуска проблем

Представьте себе, что у вас что-то болит, и вы записываетесь к доктору. На приеме он даже не пытается выслушать симптомы, а сразу назначает лекарство. Что вы сделаете? Скорее всего, сбежите от него. И правильно сделаете! Лечение невозможно без диагностики, и, только точно зная источник проблемы, её можно решить.

В тестировании и разработке ПО всё то же самое. Хотите что-то улучшить? Значит, вы хотите вылечить проблему. Найдите её!

Давайте посмотрим на стандартные причины пропуска ошибок, и для удобства восприятия поделим их на 2 категории: проблемы в процессе и человеческий фактор.

Процессные проблемы

1. Отсутствие достаточного времени на тестирование финальной сборки

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

2. Нехватка информации о продукте

Вы не знали каких-либо нюансов, влияющих на тестирование. Что, загрузка файла зависит от размера? Разные версии браузеров тоже влияют, недостаточно тестировать на последней?

3. Недостаточное понимание пользователя

Такое тоже бывает. Мы используем продукт так, как описано в справке. А пользователи – так, как им надо для решения своих проблем. Увы, иногда эти действия оказываются разными!

4. Неполные/неточные требования

<sarcasm> Конечно, вы должны уметь читать мысли и работать в условиях полного отсутствия документации. Но если вдруг в какой-то момент ваши способности оракула дали сбой, то это может привести к отсутствию тестов на неизвестное требование. </sarcasm> То есть, иногда пропуск ошибки вообще от вас не зависит.

5. Неизмеримое тестовое покрытие

За всё нужно платить. Без оценки тестового покрытия давать какие-либо гарантии невозможно. Если вы не знаете, сколько вы протестировали – как вы можете быть уверены, что не пропустили критичные ошибки? Конечно, никак не можете!

6. Недостаток общения, неналаженные коммуникации

Тестировщики не знают, что меняют программисты. Программисты не знают, как тестируются их наработки. Аналитики не рассказывают, что просят пользователи. Все сидят по углам, делают «свою» работу, и в результате проектная команда делает много кусочков одного паззла, которые невозможно сложить вместе.

Проблемы человеческого фактора

1. Нехватка квалификации

Вы дали тестировщику очень поверхностную задачу «протестируй здесь всё», но он не знает, что вы имели в виду. С учётом своих навыков он проверяет всё, что может. И не анализирует границы, не знает требуемых инструментов, не использует подходящие техники. Тынц, тынц... Только не говорите, пожалуйста, что это он виноват!

2. Нехватка ответственности

Такое часто происходит при обратной ситуации: вы слишком детально объясняете всё своим сотрудникам, даёте избыточно точные инструкции, а потом ещё и проверяете результаты их работы. Это называется микроменеджмент. В результате такого избыточного контроля сотрудники перестают чувствовать свою ответственность, а у вас всё равно не хватит времени перепроверить всё. Результат – плохое тестирование – неизбежен. И кто виноват?

3. Демотивация, незаинтересованность в происходящем

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

4. Неподходящие люди

Чтобы эффективно выполнять свои задачи, тестировщики должны быть прирождёнными тестировщиками. Не просто людьми «я тут мимо проходил, решил потестировать», а фанатами своего дела. Некоторые тест-менеджеры утверждают, что таких видите ли мало, или их сложно найти, или ещё что-нибудь. Долой отмазки! Поиск идеально подходящих сотрудников – тоже задача ТМа.

И что делать?

Итак, проблемы в процессе – головная боль тест-менеджера. Проблемы человеческого фактора – тоже наши. Что бы ни случилось, свалить ни на кого не удастся. Так что давайте их решать.

Для начала, давайте анализировать причины пропусков. Какие из вышеперечисленных пунктов «про вас», а какие – не очень? Один из учеников школы тест-менеджеров написал в чате: «Ребята, я пошёл спрашивать коллег и выяснять причины проблем и недовольств. Чем больше я их выяснял, тем понятнее становилось, что делать. Оказывается, иногда достаточно спрашивать и внимательно слушать.»

Действительно, диагностика – залог успешного лечения. Но как разбираться со всеми этими проблемами? И как подготовиться заранее, чтобы проблемы не возникали?

Предлагаю составить чек-лист из необходимых действий и регулярно проверять, на сколько ваша команда тестирования ему соответствует:

1. Время на тестирование планируется заранее

Срок финального тестирования должен быть согласован. Есть риски пропусков? Учитесь преподносить их правильно. Невозможно выделять достаточно времени? Автоматизируйте для повышения скорости! Но вы должны всегда уметь найти решение с учётом того времени и ресурсов, которые у вас есть. Не хватает? Кричите, трубите в рог и стучите в бубен. И даже можете топать ногой J Тестирование – ваша ответственность, если вам не хватает ресурсов – умейте аргументировать необходимость в расширении. Это, кстати, тоже целое искусство!

2. Продукт анализируется и исследуется вместе с разработчиками

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

3. Вы знаете, чем живёт ваш пользователь

Не контактируете пользователя напрямую? Исследуйте через аналитиков и техподдержку. Читайте обращения и жалобы, узнавайте все тонкости у внедренцев. В каких условиях работают пользователи? Какая у них квалификация? Что им нужно от продукта? Они – истинное мерило качества, а не сухие метрики. Поэтому вам просто необходимо опираться на их ожидания от продукта.

4. Вы сами следите за пониманием требований, даже если их нет

Ну хорошо, требований нет. Расслабьтесь, их ни у кого нет. Что делать в таком случае? Документируйте сами. Обсуждайте с аналитиками. Внедрите практику передачи фич на тестирование ещё и от них. Требования – это карта, без которой вы заблудитесь и далеко не уедете. Чем детальнее карта, тем точнее маршрут.

5. Вы оцениваете тестовое покрытие

Внедрите те процедуры оценки, которые подходят вашему процессу. Есть тесты и требования? Делайте трассировку. Есть требования? Помечайте статус их тестирования и сборку, на которой они были проверены. Ничего нет? Рисуйте майнд-карты и делайте на них пометки, используйте оценку покрытия кода (<a href=” http://en.wikipedia.org/wiki/Code_coverage “>Code coverage</a>). Вы не просто получите циферки «что покрыто» - вы сразу увидите, что НЕ покрыто, и где требуются тесты.

6. Коммуникации определены

Иногда нам кажется, что общение – это просто общение. Все люди взрослые, могут договориться. Как бы не так! Определите точно: кто, в каких случаях, каким образом и с кем должен взаимодействовать, и как фиксировать результаты. Побудьте занудой, это полезно! Со временем у участников проекта разовьётся культура общения, которой так не хватает современным ИТ-коллективам!

7. Вы развиваете свою команду

Конечно, каждый сам несёт ответственность за своё развитие. Но не всем понятно, куда и как надо развиваться, особенно начинающим специалистам. В результате они и развиваются мало, и много времени тратят не на то, что нужно. Расскажите им, каких знаний и навыков им не хватает – со стороны это всегда заметнее! Помогите им с развитием. Можете позволить тренинги – организуйте. Не можете – подготовьте сами. Внедрите практику внутреннего обучения, чтобы каджый сотрудник делал доклады каждый месяц. Сделайте полку с книгами. Покажите всеми своими действиями, как вы сами цените развитие. Ваши сотрудники – ваше зеркало!

8. Сотрудники чувствуют ответственность

Убедитесь, что ваши тестировщики – это ценные и любимые сотрудники, благодаря которым вы достигаете наилучших результатов. Не винтики и шурупики вялотекущего процесса, а влияющие на общий результат специалисты. Закрепите за каждым зону ответственности: часть функционала, или тип тестирования, или вид задач. Спросите, кто за что хочет отвечать, и помогите им успешно справиться с любой задачей. Как говорится, «у сильного полководца нет слабых воинов». Дайте свободу и ответственность, помогите справиться – от этого всем будет только лучше, и проекту тоже.

9. Сотрудники мотивированы

И это – ваша самая главная задача. Знаете ли вы их мотиваторы? Есть ли у вас точная стратегия работы над климатом в коллективе? Делать людей счастливыми проще, чем кажется. Понять необходимость – сложнее.

10. У вас идеальная, самая мощная и крутая команда в мире

Что говорят про свои команды Джобс, Гейтс, и другие успешные менеджеры? Они говорят, что всего достигли благодаря своей команде. Думаете, им повезло? Как бы не так! Это результат кропотливой работы, а иногда – самопожертвования. Но вы ведь не хотите быть очередным менеджером, про которого сотрудники сплетничают в курилке, вы хотите быть очередным Джобсом? Это не сложно, успешных менеджеров делает их команда. Самая, самая, самая сильная в мире.

Когда это всё???

Конечно, перечисленный список проблем далеко не полон. И решений тоже. Но это тот старт, без которого нельзя говорить об эффективном тестировании. Уделять много внимания команде, общаться с проектной командой, строить процессы – всё это требует времени. Но поверьте, все эти затраты окупятся сторицей!

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