Мыслетрекер

Джеймс Бах и Майкл Болтон периодически пишут и рассказывают о такой штуе, как Test Framing (а вот здесь есть перевод оригинальной статьи). В рамках этой модели они предлагают всегда держать в голове множество ключевых факторов, влияющих на тестирование (среда, продукт, цели, риски и т.д.). В описанном Майклом Болтоном формате мне такой подход показался очень правильным, но при этом слишком сложным. Методом проб и ошибок я выработала более простую схему для фрейминга тестирования, которая не путает своей сложностью, и при этом добавляет осознанности в тестирование.

1. Ограничение тестовой задачи

Итак, нам поступила задача на тестирование. Это может быть «проверить изменение расположения кнопки», или «оценить работу с новым форматом данных», или «протестировать гигантский продукт к концу следующего года». Вне зависимости от размера и объёма задачи, мы можем ограничить её следующими контекстными вопросами:

• Зачем нам это тестировать? Что от нас хотят получить по результатам тестирования? На что повлияют результаты тестирования?
• Как это должно работать? В каких условиях это должно использоваться? Какие требования, документированные и не очень, нам известны? Что нам непонятно и хочется спросить?
• Как это будет использоваться? В каких условиях работают наши пользователи, на каких окружениях, с какими данными? Что это за люди, с какой квалификацией? Что им важнее всего? Какие проблемы/задачи они будут решать при помощи этого продукта / фичи?
• Какие риски? Что менялось в продукте? С какими типами данных и в каком функционале чаще всего встречаются проблемы? Что могло быть затронуто изменениями? Какие ошибки вам чаще всего встречались в похожем функционале? Какие особенности есть у конкретного разработчика?
• Какие у нас ресурсы? Сколько у нас есть времени? Сколько человек? Когда от нас ждут поверхностных, а когда более детальных результатов? Есть ли у нас достаточно окружений, оборудования, ПО?
• Какова наша квалификация в тестировании подобного функционала? Какими техниками мы владеем? Какие инструменты тестирования знаем? Каких знаний нам может не хватить?

Каждый раз, приступая к задаче, мы должны отвечать на эти вопросы. Это минимальный и базовый набор вопросов, не зная ответы на которые мы не сможем тестировать хорошо! Доверитесь ли вы врачу, который пропишет лекарство без анализов и распросов? Сможете ли вы тестировать продукт, не зная его пользователей и целей? Конечно, ответ на оба вопроса — твёрдое НЕТ. Если вдруг вы понимаете, что какой-то информации по любому из пунктов не хватает — значит, надо идти и выяснять. У бизнес-департамента, у своего руководителя, у менеджера проекта, у разработчика, — у кого получится, у того и выясняйте.

2. На что вляют рамки?

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

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

Допустим, вы вообще не тестировщик, а аналитик или разработчик, и вам надо проверить ПО. Как вы сможете это сделать? Что проверить будет важнее всего? Ответы на вопросы покажут вам, с каких тестов начинать, и что важно не пропустить.

Допустим, у вас (не)большая команда, и вы хотите одинаково понимать тестирование продукта или фичи. В этом случае вы можете совместно обсудить ответы на эти вопросы, зафиксировать их на маркерной доске и обращаться к ним при принятии любых решений. А любые несогласия или разные понимания ответов на те или иные вопросы «всплывут» на этапе обсуждения — а не при тестировании и пропуске ошибок.

3. Тестируем себя

Конечно, легко и просто сказать «я и так всё это знаю, зачем задавать глупые вопросы?». Но давайте вернёмся к примеру с чрезмерно самонадеянным врачом. Вы приходите к нему после ушиба рукой, он смотрит на синяк и говорит: «перелом, ща сделаем гипс». Вы ему аккуратно пытаетесь намекнуть «а может сделаем рентген?», а он смотрит на вас с широко раскрытыми глазами и удивляется: «что я, перелом чтоли издалека не вижу?». Вы расстраиваетесь и идёте к другому врачу. Он делает рентген, МРТ, видит полное отсутствие проблем, советует просто  не нагружать слишком сильно ближайшую неделю руку, и отпускает вас домой. Что вы в этот момент подумаете о первом самонадеянном враче? Скорее всего, что он непрофессионален.

Вы тоже хотите быть непрофессионалами?

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