Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2018/03/four-and-more-questions/

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

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

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

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

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

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

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

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

Мы также можем спросить вот о чем: что получится, когда мы закончим работать? Из чего оно состоит? Можно ли взглянуть на диаграмму? Какие функции предлагает продукт, что он должен делать? Что будет вводиться, обрабатываться и выводиться? (Есть ли у нас словарь данных?) От чего продукт зависит? Что зависит от него? (Есть ли список зависимостей? Список того, что поддерживается и что нет?).

Для кого мы его делаем? Если мы создаем продукт, то мы, безусловно, делаем его для того, чтобы им пользовались люди. Иногда мы ошибаемся, чересчур концентрируясь на отдельном типе пользователя: том, кто непосредственно взаимодействует с продуктом, смотрит на экран и манипулирует клавиатурой, мышью или экраном. Зачастую, однако, этот человек – всего лишь агент кого-то другого: к примеру, подумайте о ПО операционистов банка. Стоит подумать не только об операционисте, но и о клиенте с другой стороны окошка, о валютных трейдерах, о менеджере операциониста. Заинтересованные лица существуют и за пределами непосредственного использования продукта – это те, кто поддерживает его, соединяется с его API, тестирует его, документирует, получает от него выгоду, или защищает его в суде.

Поэтому мы также можем спросить: На кого еще влияет продукт? На кого они работают, и с кем? Что значимо для них? (Эти вопросы относятся к операционной, связанной с созданием ценности тестируемостью). Кто будет поддерживать продукт? Обеспечивать его деятельность? Тестировать? Документировать?

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

Поэтому мы можем спросить: Что плохого может произойти? Что хорошего может не случиться? При каких условиях это может (не может) произойти? Чего может не хватать? Что может оказаться в наличии, хотя не дожлно? И для кого мы не делаем наш продукт – к примеру, хакеры или воры?

Как мы узнаем, что что-то пошло не так? Это еще один вопрос, связанный с тестируемостью, а также с оракулами. Как говорил Джеймс Бах, "тестирование – это искусство сравнивания невидимого с противоречивым, чтобы предотвратить немыслимое, случившееся с неизвестным". Если проблема нетривиальна, то покрыть тестами надо огромное пространство, а баги и падения не всегда сообщают о себе. Часть нашей работы – помышлять о немыслимом и помочь этим невидимым штукам стать зримыми, чтобы мы смогли выявить проблемы – в идеале до релиза. Некоторые проблемы могут сбежать от нас (а также от проверок непрерывного деплоя, если мы их делаем).

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

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

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

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