Home

Автор: Мелисса Иден (Melissa Eaden)

Оригинал статьи: http://testingandmoviesandstuff.blogspot.ru/2016/08/finding-allies-in-testing.html

Перевод: Ольга Алифанова

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

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

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

Служба поддержки – это ваш союзник

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

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

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

Инструкторы сражаются на передовой

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

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

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

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

Менеджеры продукта – это ваши защитники

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

История из жизни: никогда, никогда я не смогу сказать, что разработка продукта или бизнес-аналитика – это легко и просто. Во-первых, вы должны уметь четко и внятно писать, общаться с разработчиками и менеджментом на двух разных уровнях, и сообразить, как решать проблемы, возникающие в ходе разработки. Если ваше решение было неверным – последствия этого тоже на вас. Я замещала бизнес-аналитика, когда он ушел в отпуск, и написала пару юзер-стори, основанных на дефектах из бэклога. Я разработала критерии приемки и даже сделала пару иллюстраций того, как, с моей точки зрения, специалисты UI должны решить эти проблемы. Я работаю в QA уже четыре года, и подумывала перейти в аналитику, потому что неплохо пишу и хорошо владею навыком коммуникации, поэтому идея временно замещать бизнес-аналитика казалась мне очень удачной – это же возможность прокачать дополнительные скиллы! Написать юзер-стори было самой простой частью моей задачи (что не означает, что это просто само по себе!). Они прошли ревью, и участники команды разработки расспрашивали меня про мои требования и критерии приемки. Обе юзер-стори потом подправлялись, и когда они были готовы, началась настоящая работа. Они были взяты в разработку только через три недели, а я отслеживала их жизненный путь вплоть до деплоя. На протяжении двух недель меня регулярно бомбардировали вопросами, и я даже поучаствовала в Scrum-встречах команды, ответственной за внедрение этих фиксов. Не побоюсь сказать – это очень сложная работа! Вы должны понимать, о чем идет речь на встречах, и быстро выдавать полезные ответы. Ваша команда должна доверять информации, исходящей от вас, а вы, в свою очередь – их обратной связи. Доверие – это крайне важная часть работы аналитика. Крайне! Те, кто утверждает, что это не так, несет пургу, или же понятия не имеет о том, сколько труда нужно вложить, чтобы хотя бы одна юзер-стори (не говоря уже о целом проекте) сработала и не испортила другие участки. Плюс ко всему – если вы плохо разбираетесь в разработке продукта, это будет заметно сразу же, и куда быстрее, чем у любой другой роли в проекте. Эта профессия многого требует от вас, и я с большим уважением отношусь к людям, долгое время работающим в аналитике.

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

Любимые пользователи

Если вы можете налаживать контакт с пользователями – сделайте это. Пользователи – это неиссякаемый источник информации о вашей системе. Да, они не знают всех тонкостей и хитросплетений, но всегда смогут сказать вам, что им нравится, а что не нравится. Когда вы получаете эту информацию напрямую, а не от службы поддержки, вы получаете ее от реального, живого человека, а не от безликого "пользователя". Когда вы задаете пользователям вопросы, на которые они могут ответить (потому что хорошо знают свою область деятельности) – и когда они видят, как именно вы пытаетесь развивать продукт – вы начинаете лучше понимать свою аудиторию. Некоторые компании используют спец-версии приложения для внутреннего использования – и это тоже неплохо, - однако проблема тут в том, что иногда меньше знаешь – лучше спишь, а вы знаете чересчур много. Куда больше обычного среднестатистического пользователя! Поэтому вы легко закроете глаза на мелкие проблемы – может, вы просто в курсе, что именно их вызывает, или точно знаете, что они не будут исправляться. Но, возможно, именно эти проблемы нужно отстаивать и добиваться их исправления, даже если это какая-то мелочь! Такие "мелочи" могут превратиться в большие потери для бизнеса, в зависимости от продукта и его пользователей.

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

И предостерегу вас напоследок

Будьте осторожны, развивая подобные взаимоотношения – не доводите до ситуации, когда что-то начинает происходить через голову тех, кто должен об этом знать, или когда конфиденциальная информация утекает за пределы компании или отдела. Ваша цель в том, чтобы добиться продуктивного сотрудничества, а не в том, чтобы такие взаимоотношения стали источником проблем, и компании пришлось принимать меры, чтобы ограничить контакты между отделами (или с пользователями).

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

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