Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Я бы советовал начать с выполнения тестов. Но этот совет может несколько смутить тех, кто убежден, что тестирование имеет дело только с неким (почти) готовым продуктом и нацелено на поиск ошибок кода. В Rapid Software Testing мы смотрим на вопрос шире: тестирование – это процесс оценки продукта путем его изучения через опыт, исследование и эксперименты, включающие до некоторой степени вопросы, наблюдения, моделирование, вмешательства, и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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