Home

Автор: Ким Нап (Kim Knup)

Оригинал статьи: https://punkmiktests.wordpress.com/2016/05/15/thoughts-encouraging-change-when-you-are-the-only-tester/

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

Из моего рассказа на подкасте Testing In the Pub многие знают, как меня ценят на моей работе. Меня всегда приглашают на kick off-встречи, на которых мы говорим о том, что мы создаем и почему, и команды просят меня составить ментальные карты для тестирования.

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

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

Они все-таки решили нанять меня, а потом – целую команду тестировщиков. О том, как это произошло и чему я научилась, я и хочу рассказать.

Проблемы

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

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

Итак, список насущных проблем был таким:

• Медленная обратная связь или ее отсутствие
• Нет специализированного тестирования новой/существующей функциональности
• Фронт-энд автоматизация, которая занимала более 60 часов (4 часа, если запускать тесты параллельно), при этом тесты часто ломались.
• Ноль доверия к Selenium-тестам: если они падали, то правились тесты, а не код приложения.
• Отсутствующие юнит-тесты
• Результаты тестов бизнес-логики (которых было немного) должны были проверяться экспертами в этой области.
• Заинтересованные лица не участвовали во встречах.
• Никто не пытался поставить себя на место пользователя.

Как я пыталась решить эти проблемы

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

Моим первым шагом было общение с бизнес-стороной – но не с менеджерами, а с теми, кто действительно использует нашу систему как администратор, и понимает проблемы пользователей.

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

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

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

Я столкнулась с некоторыми трудностями, когда просила команды перенаправлять некоторые баги на их менеджеров, чтобы эти баги попали в наш спецпроект. Люди часто отвечали "Так работало всегда, я уже пытался поднимать этот вопрос – это бесполезно".

Команда разработки даже предложила автоматизировать ряд проверок, но люди всегда опасаются перемен.

Что изменилось

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

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

Я объяснила свою позицию, чтобы то, чем я занимаюсь, стало понятно всем. Раньше меня постоянно спрашивали, буду ли я писать автотесты – например, юнит-тесты и Selenium – что я совершенно не собиралась делать. Тогда я наткнулась на статью "Задачи тестировщика" Джеймса Баха и написала свою собственную версию, изложив, в чем моя ценность и что именно я делаю.

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

Последствия

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

Хозяйке на заметку: не позволяйте называть себя "обеспечением качества" и другими подобными терминами, если вы только начинаете работать в этой компании, и это совсем не ваша задача.

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

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

Найм и создание команды

Я в основном отвечала за найм тестировщиков.

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

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

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

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

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

Мы проводили встречи по обмене знаниями каждые две недели, делились новыми техниками и подходами.

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

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

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

Нам даже удалось затащить на конференцию наших разработчиков, и они даже делали доклады!

Итак, к чему это я

Главное, что я сделала – это начала общаться с людьми.

Ищите тех, кто думает так же, как и вы, и делитесь с ними своими идеями, знаниями, навыками и опытом.

Создайте библиотеку ресурсов, по которым вы сможете учиться. Может, это будет физическая библиотека или страничка в Wiki со списком литературы, видео или анонсами конференций.

Парная работа

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

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

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

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