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

На моей визитке, кроме имени и контактов, есть еще три вещи.

Самое очевидное – «тестировщик ПО». Это то, чем я занимаюсь. Я тестирую софт и помогаю коллегам улучшить показатели в этой области.

«Антрополог ПО» было добавлено после долгих раздумий на Conference of the Association for Software Testing (CAST) в 2011 году. Майкл Болтон выступал с докладом о развитии программного обеспечения, в частности тестирования как социальной науки. Это зацепило меня и заставило о многом задуматься. Главным образом мои мысли касались отношений между людьми и приложениями. При оценке принципов работы ПО эти взаимоотношения весьма важны и составляют существенную часть сути тестирования.

Это подводит нас к третьему и самому важному пункту – «постановщик вопросов». Это похоже на QA, и часто термин путают с тестированием. Сколько помню себя в сфере разработки ПО, так и было. Это раздражало меня некоторое время. В 2009 году я разговаривал с Майклом Болтоном, Фионой Чарльз, Линн МакКи, Нэнси Кельн и другими. В этой беседе постоянно использовалась формулировка: «Тестировщики задают вопросы, чтобы узнать, как реагирует или должно реагировать ПО». Постановка вопросов ведет к получению информации о софте, о том, как мы взаимодействуем с ним, и, определенно, к еще большему количеству вопросов. По крайней мере, до тех пор, пока на большинство вопросов не будут найдены ответы, удовлетворяющие заинтересованные стороны.

А это вновь возвращает нас к «тестировщику ПО».

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

В прошлом году я устроилась в небольшую команду, где разработчики действительно ценили тестирование и рассматривали его как неотъемлемую часть всего цикла создания продукта. Я никогда не забуду одну из первых планерок, где мы обсуждали новый элемент. Один из разработчиков насупился и сказал: «Да уж, но как мы собираемся его тестировать?». В результате весь проект изменили.

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

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

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

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

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

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

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

Это заметно сокращает время обратной связи, повышает уверенность и ускоряет процессы QA. Кому такое может не понравиться?

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

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

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

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