Как хаос превратить в порядок

Проекты с идеальным порядком, к сожалению, встречаются крайне редко. Чаще всего мы сталкиваемся с хаосом разной степени беспорядочности: от «черт ногу сломит» до мелких проблем, лишь изредка дающих знать о себе (например, при появлении новых сотрудников). Но, закрывая глаза даже на совсем небольшие дефекты, мы все больше приближаемся к настоящему «апокалипсису», способному «убить» самые интересные и стабильные проекты. Все как в «теории разбитых окон»: чем чаще мы не замечаем проблемы – тем больше их становится, и тем прочнее они внедряются в нашу жизнь. Увы, по-другому не бывает.

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

7 оттенков хаоса, и как с ними бороться

1. Плохо сформулированные требования.
Пожалуй, это самая распространенная проблема. На мой взгляд, полностью соответствующее требованиям техническое задание (ТЗ) можно сравнить со снежным человеком: вроде бы, про него все слышали, но точных доказательств существования нет. Мне тоже не доводилось встречаться с этой «неведомой зверушкой», поэтому каждый проект приходится начинать с выяснения степени актуальности и полноты существующих требований.

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

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

2. Отсутствие требований.
Проблема эта также встречается довольно часто, но, как мне кажется, отсутствие требований – это все-таки лучше, чем ТЗ сомнительного качества. Сделать все «с нуля» в разы легче, чем пытаться «распутать клубок» из замысловатого текста, устаревшей информации и сплошной недосказанности.

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

Итак, у проблемы отсутствия требований есть несколько путей разрешения:
  • Идеальный вариант – создание ТЗ с нуля, как это ни банально звучит. При наличии запаса времени грамотный аналитик (или тестировщик) тщательно соберет всю информацию и напишет прекрасные требования, которыми сможет пользоваться вся команда. В дальнейшем останется только актуализировать их при появлении изменений.
  • Составление тестов — помогает «убить сразу двух зайцев»: получить как представление о продукте, так и собственно тесты, по которым можно проверять сервис. Любые изменения необходимо будет вносить только в один документ (это еще один плюс).
  • Создание псевдо-требований в виде таблички, в которой собраны ссылки на источники информации по каждой функциональности. Этот вариант хорош, когда на проекте все описание продукта содержится только в багтрекере или разбросано по разным документам.

Конечно, есть еще вариант «забить и тестировать по памяти», но многие знают, что память может подвести в любой момент, поэтому не будут полагаться на такой вариант.

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

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

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

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

4. Непонятно, какие задачи выполнять, и что делать дальше.
Уверена, что я не единственная, кто прошел через всю боль попыток получить ответ на простой вопрос: чем нужно заниматься после выполнения порученной работы. Самое неприятное – «висеть» в ожидании задачи и вообще ничего полезного в этот период не делать. Такое чаще всего бывает с новичками в команде (и не важно, джуниоры это или опытные специалисты). Они не разбираются в проекте, не знают, какие есть проблемы, и до чего часто не доходят руки, поэтому могут так и просидеть день-другой без дела, пока им не дадут новое задание. Особенно остро этот вопрос стоит в послерелизное время: «полный завал» внезапно прекращается после выпуска продукта на продакшен, и всем вдруг становится нечего делать.

Для таких ситуаций всегда полезно иметь наготове список задач, которые можно выполнять независимо от релизов или спринтов. Есть такие варианты:
  • доска в системе багтрекинга (если она используется на проекте) – всегда можно наглядно посмотреть, что сделано, над чем еще ведется работа, а к чему еще не приступали;
  • табличка в том же Google Drive, где собрано описание всех задач с исполнителями и статусами готовности. Например, табличка может быть такой:

По клику на картинку откроется полная версия.

Самое главное тут – обеспечить сотрудникам постоянную занятость и отсутствие простоев. И дело вовсе не в том, что каждый должен приносить пользу команде и не сидеть зря, а в том, что проводить время без дела скучно и неинтересно. На любом проекте найдутся задачи, на которые никогда не остается времени (например, устаревшая документация).

Я уже не говорю о том, что без плана работы вообще сложно представить себе какой-либо более-менее успешный проект. Сотрудники должны всегда знать, чем им заниматься дальше (особенно в условиях интенсивной работы над продуктом), иначе вскоре на проекте возникнет настоящий хаос, начнут появляться простои, а за ними последует и неминуемый срыв сроков. Поэтому заблаговременным планированием задач и их распределением между всеми членами команды не стоит пренебрегать.

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

Таким образом, для каждой задачи нужно иметь:
  • четкое и понятное описание: как все должно работать и какие функциональности могли быть затронуты в процессе написания кода;
  • хотя бы пару строк в комментариях от разработчика о том, что и как сделано (если уж так получилось, что другого описания нет).

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

Кстати, связи между частями продукта легко отслеживать с помощью карты функциональностей. Такую «штуку» всегда полезно иметь под рукой. Допустим, разработчики исправили баги в каком-то модуле (а проблемы в итоге появились в другом) или добавили новую «фичу» (сразу понятно, что еще нужно проверить во время регрессионного тестирования). На карте можно увидеть, какие блоки имеет смысл проверить вместе с исправленной или новой функциональностью, а также какие есть связи и приоритеты. Это снимет целый ряд вопросов, поскольку все и так наглядно.

Пример такой карты приведен ниже. На ней отображены разделы продукта, их функциональности и параметры. Красный цвет – высокий приоритет, оранжевый – средний, зеленый – низкий. Стрелки показывают связь между разными частями тестируемого приложения.

По клику на картинку откроется полная версия.

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

Для решения таких проблем необходимо сделать следующие шаги:
  • создать справочник по обязанностям и должностям сотрудников (потом при необходимости всегда можно заглянуть в такую шпаргалку);
  • описать, кто конкретно в компании отвечает за нестандартные вопросы, повышение зарплат и может помочь в непонятных ситуациях. Никто не отменял форс-мажоры, конфликты и банальное желание повысить доход – сотрудники должны понимать, с кем это все можно обсудить.
К примеру, таблица может выглядеть вот так:

По клику на картинку откроется полная версия.

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

Мне очень помогли справиться с этой ситуацией простые гуглотаблички. Как только начинается новый проект, я:
  • создаю в них список задействованных сотрудников;
  • описываю задачи, которые за всеми закреплены.

В процессе работы каждый сотрудник заходит в таблицу и проставляет статусы по мере выполнения. Это дает возможность оценить объем уже сделанного и понять, сколько еще осталось. Таким образом, появляется полная картина ситуации на проекте, и не приходится донимать людей вопросами. Помимо статусов и задач в табличку можно добавить колонки для комментариев и любой другой информации (на случай возникновения непредвиденных проблем): сразу будет видно, где именно и по какой причине выполнение задачи отложено или затруднено, а также что можно сделать в данном случае. А еще таблица не раз помогала мне легко и быстро предоставить информацию о статусе проведения работ руководителю, который внезапно озаботился состоянием проекта.

Ниже можно посмотреть примеры таблиц, которые я часто использую в работе.

Таблица 1

По клику на картинку откроется полная версия.

Таблица 2

По клику на картинку откроется полная версия.

Что в итоге?

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

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

Об авторе

В «Лаборатории Качества» с 2013 года. Начинала с тестировщика, выросла в полноценного тест-менеджера. Приняла участие в тестирование ряда мобильных и web-проектов. С 2016 года совмещает основную деятельность с преподаванием на курсе «Школа успешных тестировщиков» Натальи Руколь.

Поиск
Облако меток
api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)ПОИНТ (2)Приёмочное тестирование (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (2)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (2)тестирование мобильных приложений (1)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (2)
Получите совет