5 Советов: Тест дизайн в условиях отсутствия требований
На долю каждого из нас выпадает "удача" выполнять работу в условиях частичной или полной неопределенности. Рано или поздно приходится сталкиваться с проектами, в которых формализованные требования отсутствуют от слова "совсем". Причины могут быть разными: некогда думать и писать, в команде нет аналитиков, в команде есть аналитик и совершенно случайным образом это невеста руководителя проекта, совсем недавно получившая повышение (но это, конечно, выдумка, в жизни так не бывает :).
Все эти причины объединяет одно - какими бы глупыми и несправедливыми они ни были, приложение придется поставлять заказчику, придется его тестировать и разрабатывать тесты. И вот тест дизайнер берется за задачу, вот чистый лист и... наступает ступор.
И что же с этим делать? Так и тянет залипнуть в любимую игрушку (или социальную сеть) или сходить на портал трудоустройства и обновить резюме. Проблема в том, что бегство в данной ситуации не лучшее решение. Даже если несколько раз повезет, задача отпадет сама собой, ее поручат другому или получится подготовить отписку, которая не будет иметь ничего общего с качественным тест дизайном, все равно настанет день, когда придется выполнять работу в подобных условиях. И при этом выполнять ее качественно. Ниже собраны 5 основных советов, которыми я пользуюсь при выполнении своих задач, а также рекомендую коллегам.
1. Принять и простить. Нет, я не принадлежу к глубоко верующим и речь здесь пойдет не про религиозное прощение или иные заповеди. Речь о той реальности, которая вас окружает в текущий момент, и о вашем отношении к ней. Конечно, можно понять все те отрицательные эмоции, которые вызывает все происходящее. Можно злиться и перебирать кости нерадивому начальству, оправдывая это тем сложным и безвыходным положением, в которое вас загнали. Но решит ли это проблему - нет.
Поэтому первое что нужно сделать - принять происходящее таким какое оно есть. У всего этого могут быть вполне адекватные причины. Если вы принадлежите к тем, кто не может спокойно спать, не выяснив все обстоятельства дела, выясните их позже, после того как завершите свою часть работы. Если вы проявите себя как специалист и решите трудную задачу, скорее всего, с вами будут более охотно делиться информацией. Но на текущий момент очень важно принять обстоятельства как данность - формализованных требований в проекте нет и с этим нужно работать.
Второе по важности дело - простить себя. Нужно четко понимать, что ступор - это нормальное и обыденное явление в биологическом мире. Не нужно корить себя за нежелание приниматься за работу, не нужно впадать в отчаянье и взращивать ненависть к себе. Как впрочем и не стоит слишком увлекаться посторонними делами, отвлекающими от основной задачи. Если вы располагаете некоторым запасом времени, я предлагаю насладиться моментом и побездельничать в свое удовольствие. Только не забудьте установить таймер, одного или полутора часов игры или серфинга в интернете вполне достаточно, чтобы восстановить душевное равновесие.
2. Понять что же важно. Каким бы бессмысленным ни казалось происходящее, в вашей команде наверняка есть человек, понимающий все цели и задачи текущего этапа разработки продукта. Поверьте, если компания, в которой вы трудитесь, держится на плаву несколько лет и относительно успешно продает программное обеспечение, значит не все так плохо и люди в ней умеют работать в условиях неопределенности требований (возможно, не с максимальной эффективностью, но умеют). А также отсутствие формализованных требований совершенно не означает, что у заказчика их нет. Требований не может не быть, так как любой продукт решает одну или несколько определенных задач пользователей. Вся сложность сводится к тому, чтобы узнать, кто в вашей команде является основным носителем знаний о создаваемом продукте, подготовить список вопросов и обсудить его с этим человеком.
Действовать при этом вы можете самостоятельно (если точно знаете к кому нужно обращаться) или через непосредственного руководителя. Я всегда предпочитаю действовать сообща с моим руководством, так как мы одна команда и одно дело делаем, несмотря на колоссальную разницу в нашем мировосприятии. И здесь я рекомендую ту же модель поведения. Не оставляйте своего начальника "за бортом", вовлекайте его в процесс обсуждения, советуйтесь с ним, даже если вы уверены, что точно знаете как действовать.
И самое важное - обязательно готовьтесь к обсуждению заранее и фиксируйте всю полученную информацию. Прийти на совещание и тратить время собеседника на вопросы по типу: "Я не знаю что делать. Почему нет требований? Что мне делать? Я не умею так работать, как мне быть?" по меньшей мере непрофессионально. Выделите время, обдумайте какой объем информации вам необходим для старта работ, запишите вопросы, предварительно обсудите их с вашим руководителем. В процессе этой аналитической деятельности произойдут два очень важных и значимых события. Первое - эмоции отойдут на второй план, второе - часть вопросов просто отпадет.
Каждый продукт индивидуален, но все же есть несколько общих вопросов, которые справедливы в любой ситуации:
- Общее видение продукта. Попросите собеседника рассказать общие сведения о создаваемом продукте: заказчик, решаемые пользователями задачи, основные функции системы. Является ли система, разрабатываемой с нуля, или у нее есть прототип?
- Цели запланированных поставок продукта заказчику. Какие функции продукта должны быть разработаны и протестированы к первой поставке? Какое качество продукта ожидается на первых этапах: функциональный прототип, предназначенный для выставок и демонстраций; полностью завершенный продукт с минимальным количеством дефектов?
- Особые пожелания заказчика. Не нужно забывать, что у каждого заказчика есть свои индивидуальные критерии качества. Возможно, сейчас в приоритете пользовательский интерфейс (продукт предназначен для выставки, поэтому опечатки недопустимы). Или заказчику важны замеры быстроты отклика системы.
- Специализированные вопросы по функции, проектирование тестов для которой в работе на текущий момент. Весь спектр вопросов от значений, используемых в выпадающих списках, до особенностей логики обработки данных. Так как вопросов в списке может быть несметное количество в первую очередь остановитесь на приоритетных. На основе ответов по пунктам, изложенным выше, уже можно их определить. Если ответов на какие-то вопросы у собеседника нет, предложите прояснить их с заказчиком. Вы даже можете предложить подготовить письмо с вопросами, которое затем проверит и направит нужным людям ваш собеседник. Главное, все значимые вопросы должны быть проработаны.
4. Оглянуться по сторонам. Скорее всего, тестируемый продукт не будет являться на все 100% уникальным на рынке. Он будет иметь те или иные аналоги и прототипы. Возможно, даже в рамках уже разработанных вашей компанией проектов будет пара тройка похожих систем. Опыт использования этих продуктов, впечатления пользователей, часто задаваемые вопросы и дефекты стоят особого внимания. Изучение этих материалов позволит вам лучше понять пользователей, которые будут работать с продуктом, выявить наиболее вероятные алгоритмы использования.
5. Поговорить с разработчиками. Требования к системе определяются не только бизнесом, но и технической базой, на основе которой разрабатывается код приложений. Из особенностей реализации можно почерпнуть огромное количество идей для тестирования. Прежде чем проектировать тесты поговорите с разработчиками кода. Постарайтесь как можно больше узнать про архитектуру и конечный дизайн продукта, на базовом уровне понять технологии и особенности их применения. Будет полезно попросить разработчика рассказать вам как он понимает назначение той или иной функции системы. Скорее всего, уже на этом этапе найдется несколько расхождений в понимании, которые гораздо проще и дешевле будет разрешить на данном этапе.
Подвести итог я хочу уже давно приевшейся всем фразой - нет ничего важнее для решения задачи, чем просто начать выполнять ее. Я рекомендую глубоко вздохнуть, налить себе ароматного кофе или чая (или чего-то повеселее, если случай совсем запущенный) и начать исследовать один из доступных источников информации. У вас, несомненно, может и должен быть свой ритуал, настраивающий на продуктивную работу, но суть от этого не изменится.
Источников информации о системе существует множество, их количество не ограничивается приведенными в этой статье. Не стоит ими пренебрегать даже в случае наличия качественно формализованных требований к системе.
Да, и еще один нюанс, в качестве послесловия. К сожалению, часто огромная работа по прояснению назначения системы и требований к ней со стороны тест дизайнера завершается ничем. Полученные знания не фиксируются каким-либо образом, а оседают в голове сотрудника, и нужно заметить в скором времени выветриваются из нее. От сотрудника приходится слышать: "Никто не озадачился составлением документов требований к системе. Я то почему должен что-то оформлять, если никто не оформляет". При возникновении подобных мыслей, вспомните как тяжело было вначале. Вам действительно хочется проходить все заново после того, как накопленные знания начнут замещаться новой информацией в вашей голове? В моей практике был проект, в котором спецификации были оформлены гораздо позже завершения тестирования. Документы требований были сформированы на основе, подготовленных моей командой сценариев тестирования. К слову, проекту уже более 3 лет, он активно развивается, а часть системы тиражируется для использования в подобных продуктах. Мы не пожалели о времени затраченном на подробное изложение полученной и обработанной информации, хотя плюнуть и бросить это неблагодарное дело хотелось каждый день.
Комментарии
Отправить комментарий