Изменение существующих тест-кейсов и/или
Удаление существующих тест-кейсов.
Иногда требуется создание/модификация тест-тулов, но об этом мы здесь говорить не будем, так как фактически тест-тулы — это чистой воды программирование, облегчающее исполнение тест-кейсов.
Кстати, дни начала и завершения подготовки к тестированию указаны в расписании тестирования (test schedule), которое является публичной (в пределах компании) информацией. Таким образом, тестиров-щик может рассчитывать свои силы, т.е. уходить с работы в 4 дня или 4 утра в зависимости от достигнутого им прогресса.
Постановка мозгов
Многие вещи, о которых мы будем говорить, могут показаться теоретически простыми, но пусть эта псевдопростота не вводит вас в заблуждение.
Приведем аналогию с шахматами. Взрослому человеку нужно 5 минут, чтобы запомнить правила (как ходят/бьют пешки и фигуры, правила рокировки и пр.), а для того чтобы стать мастером игры, нужны сотни сыгранных партий.
То же самое и с методами тестирования: понять базовые элементы и концепции особого труда не составит. Для того же, чтобы стать эффективным профессионалом, понадобятся месяцы и годы практического применения этих элементов и концепций на реальном ПО.
173
174
Тестирование Дот Ком. Часть 3
Для тестировщика подготовка к тестированию — это наиболее сложный, творческий и интересный процесс.
Венцом этого процесса являются тест-кейсы, которые после их исполнения на стадии "Исполнение тестирования" смогли бы превентировать встречу пользователей и багов.
|
|
|
Мы— ловцы. И тест-кейсы— это сеть,которую мы
• плетем (подготовка к тестированию) и
• используем (исполнение тестирования).
Как мы помним, тест-кейс содержательно состоит по крайней мере из ожидаемого результата, но, как правило, это комбинация:
• идеи тест-кейса,
• сценария и
• ожидаемого результата.
И те, и другие, и третьи можно почерпнуть из множества источников:
• спеков,
• опыта,
• эксплоринга,
• общения,
• интуиции и
• других кладезей информации.
Вопрос:что отличает тестировщиков от других участников процесса разработки ПО, которые тоже могут придумать тест-кейсы, основываясь на спеках, опыте, эксплоринге и т.д.? Ответ: отличают нас две профессиональные вещи:
• ментальный настрой;
• инструментарий, т.е. прикладные знания.
Сначала о ментальном настрое замолвим мы слово.
Ментальный настрой тестировщика
Помните наблюдение, что, попадая в лес,
• плотник видит доски,
• художник — пейзажи, а
• биолог — материал для диссертации?
Нигилистический настрой и практическая методология 175
Так вот,
• для пользователя код — это инструмент для выполнения каких-либо неотложных задач (например, покупки устройства для подзаводки автоматических часов);
|
|
|
• для продюсера — реализация гениальных идей менеджмента, увековеченных в спеке;
• для программиста — кусок хлеба с черной икрой;
• для тестировщика код — это убежище багов.
Постулат "Software has bugs" ("ПО содержит баги")— это не
выдумка лицемеров и лжесвидетелей, а вселенский закон,кормящий тестировщиков, а следовательно, и их жен, детей, говорящих попугаев и лысых кошек. Не будем же лишать наших домочадцев лакомого куска и раскроем свое сердце истинной сути вещей, заключающейся в том, что ПО своей природе — это баго-содержащее и неблагонадежное существо.
Еще раз:
Код — это убежище багов.
Итак, навесив ярлыки, идем дальше...
Как известно, ищущий да обрящет(из этого не следует, что не ищущий не сможет обрести. Однако логичнее предположить, что именно тот, кто ищет, найдет больше. По крайней мере, как правило...).
Тестирование — это ПОИСК багов.
"ПОИСК"— это ключевое слово, точно раскрывающее смысл нашей профессии, которая принципиально требует от нас, как иот сыщиков, и прикладных знаний, и интуиции, и ментальных установок.
|
|
|
Постановка мозгов
Концепция "поиска багов" как пути, по которому идет тестировщик для превентирования свидания пользователя и багов, начисто отметает идею о том, что тестировщик, подобно ОТК (отдел технического контроля в СССР), сертифицирует продукт на качество и ставит штамп "Проверено, багов нет". Ничего мы не сертифицируем, да и штампов у нас нет, кроме тех самых... в паспорте...
Еще раз: основа работы тестировщика — это поиск багов.
Тестировщик не занимается поиском доказательств того, что ПО работает.
176
Тестирование Дот Ком. Часть 3
Мы должны настроить себя на поиск багов в коде, который является убежищем этих самых багов.Nice and simple.
Основой такого настроя — ментального настроя тестировщи-ка — является деструктивное мышление, полное подозрительности, недоверия и априорного отрицания даже потенциального наличия добродетелей — все в отношении ПО.Мы должны твердо верить в то, что "был бы код, а баги найдутся".
Пытливый ум внимательного слушателя сразу же сгенерирует вопрос, на который я тут же отвечу.
Вопрос:«О каком деструктивном мышлении мы можем говорить, если у нас есть такое понятие, как "позитивное тестирование", и позитивные тест-кейсы настолько важны, что мы исполняем их в первую очередь?»
|
|
|
Ответ:"Позитивное тестирование и принцип первичного исполнения позитивных тест-кейсов — это технический аспект. Де-структивность в мышлении — это аспект ментальный. Даже если мы создаем тест-кейс с позитивным сценарием, мы должны искать способ, чтобы обнаружить баги".
Дорогие друзья! Взращивайте и лелейте в себе неисправимый пессимизм в отношении идеи о коде, свободном от багов.
Смотрите на код как на виртуальную вещь, которая в процессе тестирования послужит еще одним доказательством постулата о несовершенстве мира. Если вы настроите себя на деструктивное мышление в отношении кода, то ваша интуиция включится на всю катушку и прекрасные идеи для тест-кейсов будут стаями роиться в ваших головах, как только вы прочитаете спек.
Парочка сладких десертов
—Скажите, а исполнится ли загаданное желание, если я загадаю его, сидя между двумя программистами?
—Конечно, исполнится, но... будет глючить!
Хирург, инженер и программист сидят в баре и обсуждают, чья профессия является древнейшей:
Хирург: Моя профессия является древнейшей, потому что Богу нужны
были знания по хирургии, чтобы извлечь из Адама ребро.
Инженер: Но еще до этого был хаос, и, чтобы сделать мир из хаоса,
Богу нужны были инженерные знания.
Программист: Ха! Кто же, как вы думаете, создал весь этот хаос?
Нигилистический настрой и практическая методология 177
Теперь, настроенные и решительные, переходим к профессиональным прикладным знаниям, а именно к методологии создания тест-кейсов(testcase design methodology) (далее — методология).
В одной из прошлых бесед мы говорили
о первой части методологии — формальной сторонепостроения тест-кейса.
Сегодня же речь пойдет
о второй ее части — содержательной сторонетест-кейса.
Искусство создания содержательной части тест-кейсов заключается в нахождении тех "золотых"
• идей тест-кейсов,
• сценариеви
• ожидаемых результатов,
которые при исполнении тестирования помогли бы обнаружить больные, багосодержащие места тестируемого ПО.
Какие два этапа составляют процесс, называемый "выбор"?
1. Сначала нам нужно увидеть, что имеется в наличии.
2. Затем, используя некий критерий (-ии), мы выбираем или не выбираем.
Например, выбирая щенка,
1) мы должны увидеть одного или больше щенков (что имеется в наличии) и затем
2) посмотреть, как весело он (они) бегает, как блестят его глазенки и пр. И посмотрев, решить — брать или не брать.
Подход к выбору сценариев концептуально схож:
1. Что имеется в наличии, мы видим после использования методов генерирования тестов(methods of test generation);
2. Орудиями отбора являются методы отбора тестов(test selection criterion).
Развертываем:
Методы генерирования тестов:
1. Черновик-чистовик (dirty list-white list);
2. Матричная раскладка (matrices);
3. Блок-схемы (flowchart).
178
Тестирование Дот Ком. Часть 3
Методы отбора тестов:
1. Оценка риска (risk estimate);
2. Эквивалентные классы (equivalent classes);
3. Пограничные значения (boundary values).
Методы генерирования тестов
1. Черновик-чистовик (dirty list-white list).
2. Матричная раскладка (matrices).
3. Блок-схемы (flowchart).
1. "ЧЕРНОВИК-ЧИСТОВИК"
Это самый простой и практичный метод. Суть проста. Два этапа:
а. Черновик (dirty list)
В процессе (и/или после) прочтения спека, эксплоринга ПО и/или получения информации о ПО другим способом, не анализируя и отдавшись вдохновению и фантазии, мы просто набрасываем на лист бумаги (или в файл Ворда), являющийся черновиком (dirty list), ВСЕ идеи, связанные с тестированием, которые только могут прийти в голову, — идеи в самом широком смысле этого слова, включая идеи для тест-кейсов, сценарии, отдельные элементы сценариев (шаги и/или данные), ожидаемые результаты, вопросы для выяснения у продюсера и пр.
Еще раз: ВСЕ идеи — даже самые на первый взгляд далекие от здравого смысла. Локальный мозговой штурм.
б. Чистовик (white list)
Затем мы начинаем анализировать написанное (и, если нужно, получать ответы на вопросы) и переносим на чистовик вещи, имеющие право на жизнь. Право на жизнь определяется на основании информации из спека, общения, интуиции, критериев отбора тестов, разговора с программистом и пр. При переносе на чистовик мы также уточняем наши идеи и группируем их (например, по позитивности и негативности; по функциональным направлениям и т.п.). Таким образом, как правило, первый чистовик превращается во второй черновик, и мы берем следующий лист бумаги и, надеясь, что он будет чистовиком, начинаем пере-
Нигилистический настрой и практическая методология
179
носить на него наши идеи и т.д. В итоге в один из светлых майских дней мы все-таки получаем чистовик. На основании материала из чистовика мы пишем тест-кейсы.
Сейчас рекомендую вам немедленно взять ручку, лист бумаги и потратить 15 минут на генерацию черновика по тестированию автомата для продажи банок с колой (любимый тест рекрутеров из "Майкрософта"). Начинаем:
• Проверить, что покупателю выдается именно та банка, которую он хочет.
• А что, если покупатель нажмет на кнопку два раза?
• А что, если покупатель попробует наклонить аппарат, чтобы банки посыпались как из рога изобилия?
• Проверить, что правильно выдается сдача.
• Какая реакция на монетку иностранного государства?
• И т.д. и т.п.
После того как черновик готов, потратьте 15 минут на составление чистовика и затем 30 минут на составление тест-кейсов по полной форме:
• идея,
• сценарий (шаги и данные) и
• ожидаемый результат.
Ручаюсь, что этот час окупится сторицей, чем бы вы ни занимались в жизни, и вы ни разу не пожалеете, что потратили 60 минут времени на подобный тренинг.
2. МАТРИЧНАЯ РАСКЛАДКА
Давайте без прелюдий и патетики перейдем к примеру.
|
|
| Сделаем матричную раскладку. |
Украдем макет первой страницы регистрации из цикла разработки ПО:
180
Тестирование Дот Ком. Часть 3
Этап 1. Набросок элементов(табл. 1)
Таблица 1 Набросок элементов
| Индекс | Индекс_эл_001 | Индекс_эл_002 | Индекс_эл_003 | Индекс_эл_004 | Индекс_эл_005 | Индекс_эл_00б | Индекс_эл_007 | Индекс_эл_008 | Индекс_эл_009 | Индекс_эл_010 |
| Индекс введен? | ||||||||||
| да | X | |||||||||
| нет | X | |||||||||
| Индекс действующий? | ||||||||||
| Да | X | |||||||||
| нет | X | |||||||||
| Значения индекса | ||||||||||
| 6 цифр | X | |||||||||
| 5 цифр | X | |||||||||
| 7 цифр | X | |||||||||
| Включает буквы | X | |||||||||
| Включает специальные символы (например, &) | X | |||||||||
| Включает пробелы | X | |||||||||
Таким образом, у нас получилось 3 подгруппы:
1. "Индекс введен?"
2. "Индекс действующий?" (существует ли адрес с таким индексом в Российской Федерации?)
3. "Значения индекса".
Каждый из элементов имеет свой уникальный ID, например, элемент, когда пользователь вводит в поле индекса 6 цифр, мы обозначили как Индекс_эл_005 (элемент номер 005 страницы с индексом).
Буквенная часть ID (Индекс_эл) — это вещь произвольная. Просто мне кажется, что для разбираемого примера это название интуитивно и логично.
Прошу заметить, что мы набросали элементы как позитивных, так и негативных сценариев.
Нигилистический настрой и практическая методология 181
Этап 2. Комбинация элементов(табл. 2)
Теперь мы начинаем комбинировать элементы между собой.
Таблица 2 Комбинация элементов
| Индекс | Индекс_эл_001 | Индекс_эл_002 | Индекс_эл_003 | Индекс_эл_004 | Индекс_эл_005 | Индекс_эл_00б | Индекс_эл_007 | Индекс_эл_008 |
| Позитивные тесты | ||||||||
| индекс действителен, 6 цифр действующего российского индекса: 119602 | X | |||||||
| Негативные тесты | ||||||||
| индекс недействителен, 6 цифр: 000000 | X | |||||||
| индекс недействителен, 5 цифр: 11960 | X | |||||||
| индекс недействителен, 7 цифр: 1196021 | X | |||||||
| индекс недействителен, буквы: 1196о2 (буква "о" вместо нуля) | X | |||||||
| индекс недействителен, специальные символы: 11(602 (символ "(" вместо девятки) | X | |||||||
| индекс недействителен, пробел между цифрами: 1196 02 | X | |||||||
| пустое место | X | |||||||
Как видно, мы скомбинировали элементы табл. 1 в сценарии.
У каждого из сценариев есть свой уникальный ID, например сценарий, когда в поле индекса не вводится никакого значения, проходит под штампом Индекс_ком_008 (комбинация номер 008 страницы с индексом).
Кстати, обратите внимание:
• в данном конкретном примере мы играем с частью сценария под названием "данные"(варианты индекса),
• сначала расписываем позитивные, а затем негативные сценарии,
• сценарий Индекском 008 не был комбинацией элементов табл. 1, а напрямую следовал из элемента Индекс_эл 002.
182
Тестирование Дот Ком. Часть 3
Вопрос:зачем мы присваивали уникальный ID каждому из элементов в табл. 1, если мы их не используем? Ответ:иногда в табл. 2 вписывается не содержание элементов (как мы это сделали), a ID. Кроме того, если у элемента есть ID, то это просто удобно для ссылки.
Например
• при обсуждении, когда у вас и вашего коллеги есть по экземпляру табл. 1 или
• когда я рассказываю вам о матричном методе.
Итак, у нас есть 8 сценариев для страницы, когда пользователь должен ввести некое значение (либо пустое место) для индекса места жительства. Мы можем сразу же, используя эти сценарии, написать тест-кейсы. Ожидаемым результатом для всех, кроме Индекс_ком_001, будет перезагрузка страницы с индексом с сообщением об ошибке:
"Введите действительный российский индекс".При этом текст "Индекс места жительства*" будет красного цвета.
Для ИндекскомОО 1 ожидаемым результатом будет следующая страница:
Теперь вспомним об этапах покупки книг:
а. Регистрация (если нет счета пользователя).
б. Заполнение книгами виртуальной корзины.
в. Редактирование корзины: какие-то книги может убрать,
каких-то купить больше, чем одну.
Нигилистический настрой и практическая методология
183
г. Указание деталей доставки.
д. Оплата.
Так вот мы придумали сценарии только для первой части нашей версии регистрации (вторая часть — это страница с именем, фамилией, е-мейлом, паролем и подтверждением пароля). У второй части тоже будут свои табл. 1 и табл. 2.
Более того, у каждого из остальных этапов тоже могут быть свои одна или более связок табл. 1 — табл. 2.
Черноящичное тестирование веб-проекта — это манипуляции с одной или больше веб-страниц, зависимых друг от друга, определенная комбинация которых ведет нас к определенному ожидаемому результату.
Таким образом, иногда появляется потребность
• в табл. 3, когда сценарии из табл. 2 становятся элементами более сложных сценариев,
• в табл. 4, когда сценарии из табл. 3 становятся элементами еще более сложных сценариев,
• и т.д.
Кстати,
иногда в табл. 1 мы сразу отражаем возможные значения для нескольких связанных между собой веб-страниц.
Я знаю, что матричный метод в начале работы по нему кажется сложным и запутанным. Единственный способ освоить его — это использовать на практике, что мы с вами сейчас и сделаем.
Однажды в классе по "юниксу" на занятии по теме "Регулярные выражения" (наука поиска паттернов в тексте) один товарищ удивительно метко выразил физическое состояние всех студентов: "Это как операция на головном мозге". Я не удивлюсь, если в начале использования матричного метода у вас будет схожее состояние.
Итак, предлагаю вам сейчас самостоятельно создать табл. 1 и табл. 2 для второй части регистрации. Также прошу вас написать тест-кейсы по полной форме на каждый из сценариев первой и второй частей регистрации.
Далее.
184
Тестирование Дот Ком. Часть 3
Одна из прелестей матричного подхода заключается в наглядности — мы видим перед собой таблицу со структурированными вариантами сценариев, и нам удобно комбинировать их в более сложные сценарии или непосредственно переносить их в тест-кейсы.
Кстати, во многих случаях нет смысла идти дальше табл. 1, например когда сценарии для тест-кейсов непосредственно вытекают из элементов табл. 1 или когда сценарии для тест-кейсов можно просто домыслить, скомбинировав в уме элементы табл. 1.
3. БЛОК-СХЕМЫ
В беседе о продюсерах и вещах, которые им нужно улучшить в своей работе, мы уже говорили о блок-схемах. Блок-схема— это графическая презентация некого процесса.
Блок-схемы допускают разные уровни абстракции, например процесс регистрации можно представить и в таком виде:
Процесс регистрации
Эта блок-схема и ее сестра из беседы о цикле разработки ПО
• похожи тем, что демонстрируют нам логикуработы регистрации и
• различаются тем, что имеют различную детализациюэтой логики.
Нигилистический настрой и практическая методология
185
Всвоей работе тестировщики используют ту степень детализации, которая нужна для конкретной ситуации:если мы тестируем самурегистрацию, то нам необходима большая степень детализации (процесса регистрации) по сравнению с ситуацией, когда нам нужно увидеть место регистрации как часть процесса покупки.
Идея о разных степенях абстрагированности раскладки в зависимости от того, ЧТО и КАК мы тестируем, напрямую относится и к черновику-чистовику, и к матричному методу.
Вот элементарные, непробиваемые и вечные формы (блоки) для составления блок-схем, которых вам будет достаточно в большинстве ситуаций:
|
|
Точка начала/концаблок-схемы может содержать название этой точки (например, название веб-страницы) или просто и со вкусом величаться "Начало"/"Конец".
Это любойэтап процесса, кроме этапов начало/конец, решение или перенос.
Решение— некая точка, после которой возможны, как правило, два варианта развития процесса.
Переносставится в том случае, если данное ответвление процесса представлено (будет представлено) другой блок-схемой.
Вот несколько рекомендаций по составлению блок-схем.
1. Перед составлением блок-схемы назовите основной процесс,описываемый ею, например "Процесс регистрации".
2. Сначала набросайте путь основного течения процесса, например, в случае с регистрацией это три блока, показанные на последней блок-схеме (страница 1, страница 2 и подтверждение).
3. Называйте каждый блок кратко и информативно.
4. Приводите ссылки на полезную информацию, например, см. Спек #9017 — это ссылка на соответствующий спек.
186
Тестирование Дот Ком. Часть 3
5. Для наглядности презентации старайтесь скомпоновать блок-схему таким образом, чтобы процесс шел сверху вниз и слева направо.
6. Для превентирования ошибки в толковании избегайте пересечения стрелок.
7. Протестируйте (проверьте) законченную блок-схему на предмет соответствия спеку или другому источнику.
Для тренировки нарисуйте блок-схему следующей ситуации.
Идея: вскипятить чайник.
Вот вам в помощь блоки решений, которые предстоит разложить в блок-схеме:
1. Вода в чайнике есть/нет.
2. Плита включена да/нет.
3. Чайник кипит да/нет.
Для совершенствования в составлении блок-схем очень рекомендую найти ресурсы в Интернете или купить книгу.
Блок-схемы — это визуальные источники идей для тестирования.Кроме того,
как и в случае со всеми методами генерации тестов, процесс создания блок-схем вызывает рождение множества превосходных идей для тестирования, открывает тестировщику новые грани ПО и вызывает ряд вопросов, которые не возникли бы при простом прочтении спека.
Политический момент
как известно,
теория (простое прочтение спека перед его утверждением) и практика (работа со спеком при создании тест-кейсов) — это две разные вещи.
На "практике", если спек более или менее сложный, неизбежно возникнет необходимость в уточнениях.
Нигилистический настрой и практическая методология 187
Знайте, что отвечать на вопросы по спеку — это святая обязанность продюсера.
Вы имеете право, нет, ОБЯЗАНЫ задать ему ВСЕ вопросы по спеку, которые у вас возникнут, ибо шкуру будут спускать с вас, а нес него, если вы из-за неотвеченных вопросов пропустите баги.
Кстати, обязательно сохраняйте всю переписку в отдельном фолдере (папке) е-мейл клиента (дайте фолдеру наименование (Ю) спека): вдруг продюсер дал вам уточнение, оно было неверным, вы написали тест-кейс с ошибкой/не написали тест-кейс вовсе и пропустили серьезный баг?
Нет е-мейла — нет доказательств, есть е-мейл — есть доказательства.
Если уточнение по спеку было сделано устно, пошлите е-мейл продюсеру, где опишите то, как вы поняли уточнение, и спросите "Я правильно понял?".
Если продюсер не отвечает, пошлите ему тот же е-мейл из фолдера е-мейл клиента "Отправленная почта", чтобы он видел, что уже один раз проигнорировал ваш запрос.
Если ответа снова нет и продюсер не болен, не уехал на ПМЖ в Австралию, а даже очень здоров, строит дачку в Малаховке, и вы видите его в столовой каждый день, то просто перешлите последний из е-мейлов продюсера своему менеджеру и сообщите ему, что не можете работать по спеку.
Менеджер не будет сам говорить с ним, а переправит ваш е-мейл менеджеру продюсеров, чтобы тот спросил у продюсера: "В чем, собственно, дело?" Даю гарантию, через час продюсер сам прилетит к вам, как ни в чем не бывало хлопнет по плечу, как лучшего друга, и проведет с вами столько времени, сколько нужно, травя байки и находя удачные аналогии для того, чтобы вы лучше поняли материал. "Бизнес есть бизнес", вы ищете баги и, чтобы быть эффективным, должны получить всю информацию по спеку.
Теперь суперважная вещь в отношении методов генерирования и отбора тестов.
Превосходные результаты дает комбинирование методов.
Например, можно набросать черновик и в качестве чистовика создать табл. 1, сгруппировав в ней идеи из черновика.
С другой стороны, имея табл. 1, табл. 2 и т.д., можно использовать метод черновик-чистовик, чтобы выделить сценарии из элементов табл. 1, табл. 2 и т.д.
С третьей стороны, можно создать блок-схему, чтобы нагляднее видеть процессы, описанные в таблицах, и найти новые интересные идеи.
Вобщем бесчисленное множество комбинаций и огромное поле для творчества! Как мы уже говорили, в тестировании нет догм
188
Тестирование Дот Ком. Часть 3
и даже сами основы отрасли знания "Тестирование" постоянно находятся под обстрелом, так что дерзайте и находите именно те приемы и методы, которые будут работать для вас в тех ситуациях, в которых вы будете работать.
Методы отбора тестов
1. Оценка риска (risk estimate).
2. Эквивалентные классы (equivalent classes).
3. Пограничные значения (boundary values).
Общая вещь: методы отбора тестов применяются во время или после генерирования тестов.
1. ОЦЕНКА РИСКА (risk estimate)
Представьте, что вы только что прикупили отель где-нибудь в горах Сьерра-Невада в Северной Калифорнии. У вас нет опыта работы менеджером отеля, но вы чувствуете себя абсолютно уверенным в своей новой роли, так как у вас есть высшее образование в области физики твердого тела и такую фигню, как управление отелем, вы, конечно, осилите на раз.
К вашему отелю ведут три дороги:
• первая соединяет отель и ответвление скоростной магистрали,
• вторая соединяет отель и дорогу, ведущую к горнолыжным курортам,
• третья соединяет отель и небольшую проселочную дорогу. по которой ездят в основном местные жители.
Все три дороги имеют одинаковую протяженность.
10 человек уже приехали и 30 человек должны приехать сегодня.
Всю ночь шел снег, и все три дороги замело так, что ни один джип не проедет ни по одной из них.
У вас есть только одна снегоуборочная машина, и на уборку любой из дорог уйдет полдня. Так что нужно выбирать, с какой из них начать.
Можно подойти к решению этой задачи чисто субъективно.
Нигилистический настрой и практическая методология
189
Абсолютно очевидно,что по дороге номер 3 могут приехать только ваши местные кореша
• для игры в покер (но сегодня не день покера — пятница) или
• на барбекю (но сегодня не суббота).
Значит, дорога 3 остается в снегу.
Абсолютно очевидно,что дорога номер 2 также не является приоритетной в расчистке, так как абсолютно очевидно, что 10 меньше 30.
Таким образом, наш план:
• посадить отельского "жнеца, швеца и на дуде игреца" за руль снегоуборочной машины расчищать роад намбер уан: дорогу к скоростной магистрали;
• вывесить в лобби отеля большой плакат "Дорог на гор закрыт. Не ходи, а то хана" для уже вселившихся;
• накормить уже вселившихся бесплатным завтраком (в качестве извинения).
Запомним, с какой уверенностью мы говорили себе: "Абсолютно очевидно".
Давайте перед тем как реализовывать наш гениальный план, основанный на очевидных вещах, остановимся на минутку у стойки регистрации и поговорим с менеджером отеля, который проработал в нем 20 лет.
Первый вариант разговора
Вопрос:"Что делать, Джеймс?"
Ответ:"Босс, все очень просто. Все, кто уже вселился в отель, приехали играть в снежки, кататься на беговых лыжах или просто дышать свежим воздухом. Я это знаю потому, что переговорил с каждым из них и знаю большинство из них, так как они приезжают каждый год. Поэтому нет никакого смысла в расчистке дороги номер 2,все остаются в отеле или развлекаются в его окрестностях.
Я также знаю, что 16 человек из 30 — это компания, которая выедет к нам рано утром из Рино (я вчера говорил по телефону с одним из них) по этой дороге (показывает на карте), которая пересекается с дорогой номер 3. Соответственно они прибудут к нам по дороге номер 3.
190
Тестирование Дот Ком. Часть 3
Далее, посмотрите на монитор. Где живут 12 из 14 оставшихся клиентов? Они все живут вСан-Франциско и окрестностях. Только что передали по радио, что на единственной скоростной дороге, ведущей из Сан-Франциско, из-за снегопада уже образовались страшные пробки. Кроме того, скорее всего большинство членов сан-францисской команды поедут после работы, т.е. в 4 часа, а значит, будут здесь не раньше 8.
Следовательно, нам нужно сначала расчистить дорогу 3 и после этого заняться дорогой 1.
Кстати, остаются еще двое, едущие из Техаса. Вот их мобильный телефон. Я собираюсь им позвонить, рассказать о ситуации со снегом, наших планах по расчистке и скоординироваться с ними, как им лучше до нас добраться".
Второй вариант разговора
Вопрос:"Что делать, Джеймс?"
Ответ:"Босс, надо сначала расчищать дорогу 2,ведущую к горнолыжным курортам. Все наши постояльцы — это горнолыжники. Кроме того, оставшиеся 30 человек скорее всего сначала заедут на курорт, покатаются там до вечера и вечером поедут к нам — не будут же они терять сегодняшний день, я сам заказывал им пропуска со скидкой на подъемники, а пропуска начинают действовать сегодня".
Третий вариант разговора
Вопрос:"Что делать, Джеймс?"
Ответ:"Босс, нет проблем. Нам нужно расчистить и дорогу 1, и
дорогу 2. Яне знаю, что важнее. Но знаю номер телефона моего приятеля — владельца снегоочистительной компании, он даст нам хорошую цену, и двумя машинами мы сможем к полудню расчистить обе дороги. Ну, потратим немного денег, зато сохраним репутацию отеля, ставящего заботу о клиенте выше всего".
Мораль:
субъективные суждения, основанные на тупосамонадеянном "Абсолютно очевидно", могут элементарно завести нас в ситуацию, когда ресурсы потрачены впустую, так как не учитывают реальности. В то же время выводы, сделанные исходя из достоверной информации, ведут к эффективным решениям даже при нехватке ресурсов.
Нигилистический настрой и практическая методология
191
То, что сделал для нас мистер Джеймс, было оценкой риска. Он смог сделать оценку риска, так как
• владел информациейи
• знал, как этой информацией распорядиться.
Обратно к тестированию ПО.
Наша задача — это
• получить информацию,
• если возможно, узнать мнение человека, владеющего вопросом, и
• оценить риск по каждой из функциональностей, которые предстоит протестировать.
Людьми, которые владеют вопросом, могут быть продюсер, главный бухгалтер, финансовый директор, бизнес-аналитик. Информацию можно получить также из статистики или других источников.
Поверьте, что такой подход даст удивительные результаты.
Допустим, у нас есть небольшой проектик, где нужно протестировать новый (переписанный и оптимизированный) код для уже давно существующих функциональностей:
а) сделки купли-продажи между пользователями внутри Аме
рики;
б) сделки купли-продажи между пользователями в Японии;
в) сделки купли-продажи между пользователями в Японии
и США.
Разложим эти функциональности:
Таблица 1
| Индекс_эл_001 | Индекс_эл_002 | Индекс_эл_003 | Индекс_эл_004 | |
| Продавец | ||||
| Американец | X | |||
| Японец | X | |||
| Покупатель | ||||
| Американец | X | |||
| Японец | X |
192
Тестирование Дот Ком. Часть 3
Таблица 2
| Индекс_эл_001 | Индекс_эл_002 | Индекс_эл_003 | Индекс_эл_004 | |
| Продавец американец —> Покупатель американец | X | |||
| Продавец американец —» Покупатель японец | X | |||
| Продавец японец —> Покупатель американец | X | |||
| Продавец японец —> Покупатель японец | X |
Помните, я говорил, что применение методов генерирования тестов дает вам более глубокое понимание спека? Вот и теперь, делая матричную раскладку, мы увидели, что на самом деле у нас не три, а четыре направления для тестирования. Разложим их на блок-схеме.
Блок-схема по спеку #1123
Постановка мозгов
Есть превосходный профессиональный термин flow (течение, процесс) (будем использовать его в транслите как "флоу"). Флоу — это один или больше сценариев использования или работы ПО. Например, у нас есть флоу Американец -> Американец. В данном конкретном случае на это флоу можно написать множество сценариев (например, с разными суммами оплаты, транзакции между разными штатами и т.д.).
Итак, у нас есть четыре флоу.
Давайте снова поиграем в "Абсолютно очевидно" и решим вопрос о приоритетности каждого флоу. Допустим, что покупаются и продаются запчасти для автомобилей:
Нигилистический настрой и практическая методология
193
а. Скорее всего, самым приоритетным будет флоу Япо
нец —> Американец, так как в США очень много японских
автомобилей, запасные части производятся в Японии и
наш сайт — это очень важный канал для поставок.
б. Ниже идет флоу Американец —> Американец, хотя внут
ренний рынок американских запчастей очень велик, но есть
много других каналов поставок кроме нашего веб-сайта.
в. Далее идет Американец —> Японец, это флоу менее при
оритетное, чем о и б, но более приоритетное, чем г.
г. Самый нижний приоритет у флоу Японец —» Японец, так
как в Японии развита инфраструктура купли-продажи зап
частей и нашим сайтом там почти не пользуются.
Вроде бы все смотрится логично, но до тех пор, пока мы не начнем копать.
Вопрос:Откуда у меня информация, на основании которой я сделал свои выводы? Откуда я знаю, что, например, в случае а (Японец —» Американец) "наш сайт — это очень важный канал для поставок"?
Ответ:Я знаю это, так как где-то (может быть, краешком уха) услышал или прочитал (может быть, в определенном контексте) эту информацию.
А что, если я неправильно понялэту информацию или она, подобно постмодернизму, устарела?
Далее.
Вопрос:Что значит, что "внутренний рынок американских запчастей очень велик"? Насколько он велик? Ответ: ...
Карточным домиком были наши рассуждения. А ведь все казалось таким логичным...
Давайте лучше пойдем к продюсеру, покажем ему нашу блок-схему и попросим совета.
Пришли, показали, попросили.
Продюсер делает пару звонков, и мы идем к бизнес-аналитику. Тот видит нашу блок-схему, поднимает данные по транзакциям за последние два года, и вот что мы имеем.
194
Тестирование Дот Ком. Часть 3
а. Самое большое количество сделок было между японскими
пользователями (Японец —» Японец). Продюсер добавляет,
что продвижение на японском рынке — это главный при
оритет компании, как было сказано на очередном съезде, в
смысле было сказано на последнем собрании.
б. Вторым по приоритетности идет Американец —» Японец.
Вот данные по сделкам. Продюсер добавляет, что недавно
были заключены контракты с крупными американскими
автозаводами о том, что те будут использовать наш веб-сайт
для продаж за рубеж.
в. Третьим будет Американец —> Американец, так как вот
цифры. Продюсер добавляет, что конкурирующие сайты и
другие каналы поставок завоевали местный рынок.
г. Четвертым будет Японец —» Американец, так как вот циф
ры. Продюсер добавляет, что японские компании распре
деляют запасные части через своих авторизованных аме
риканских дилеров, а американские дилеры японских ино
марок используют наш сайт неохотно.
Затем мы попросили дать процент для каждого флоу относительно общей суммы сделок по всем четырем флоу (это было немного больше, чем было нужно, так как я уже знал приоритетность каждого флоу, но, как говорят, "кашу маслом не испортишь" и "куй железо, пока горячо"):
Блок-схема по спеку #1123
Теперь у нас есть данные, соответствующие реальности и основанные
• на информации из объективных источников и
• на мнении компетентных лиц.
У нас есть не просто приоритеты, а приоритеты, подкрепленные цифрами (проценты) и пониманием бизнеса (комментарии продюсера).
Нигилистический настрой и практическая методология
195
И еще мы снова видим, что эти превосходные, проверенные данные снова абсолютно противоречат нашему, казалось бы, незыблемому, но на поверку очень даже "зыблемому" "Абсолютно очевидно".
Что делать, если вдруг есть две функциональности с одинаковым приоритетом? С чего начать? Начните с той, которая более сложная и трудоемкая.
Последний вопрос в отношении оценки риска — это использование полученной информации. Флоу с более высоким приоритетом (который мы отражаем в поле тест-кейса "Приоритет") тестируется
• в первую очередь и
• более тщательно.
Кроме того, в дальнейшем у вас всегда будет аргумент, почему вы тестировали именно это и именно в таком объеме.И этим аргументом будут данные по оценке риска, которые вы использовали как профессионал-тестировщик, ориентированный на счастье пользователя.
2. ЭКВИВАЛЕНТНЫЕ КЛАССЫ (equivalent classes)
Это суперполезная вещь, которой мы немедленно дадим определение:
Дата добавления: 2018-05-02; просмотров: 1267; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!