Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
ЧАСТЬ 3 ПОДГОТОВКА К ТЕСТИРОВАНИЮ • НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И ПРАКТИЧЕСКАЯ МЕТОДОЛОГИЯ ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ • ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ • ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 1: ТЕСТИРОВАНИЕ НОВЫХ ФИЧА (New Feature Testing) • ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 2: РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ (Regression Testing) ПОДГОТОВКА К ТЕСТИРОВАНИЮ НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И ПРАКТИЧЕСКАЯ МЕТОДОЛОГИЯ • МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА • МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ • МЕТОДЫ ОТБОРА ТЕСТОВ П одготовка к тестированию с точки зрения тестировщика включает: 1. Написание новых тест-кейсов и/или 2. Изменение существующих тест-кейсов и/или 3. Удаление существующих тест-кейсов. Иногда требуется создание/модификация тест-тулов, но об этом мы здесь говорить не будем, так как фактически тест-тулы — это чистой воды программирование, облегчающее исполнение тест-кейсов. Кстати, дни начала и завершения ПОДГОТОВКИ к тестированию указаны в расписании тестирования (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 se- lection 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 Набросок элементов Индекс И н д ек с_ эл _ 0 0 1 И н д ек с_ эл _ 0 0 2 И н д ек с_ эл _ 0 0 3 И н д ек с_ эл _ 0 0 4 И н д ек с_ эл _ 0 0 5 И н д ек с _ эл _ 0 0 б И н д ек с_ эл _ 0 0 7 И н д ек с _ эл _ 0 0 8 И н д ек с_ эл _ 0 0 9 И н д ек с_ эл _ 0 1 0 Индекс введен? да 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 Комбинация элементов Индекс И н д ек с_ эл _ 0 0 1 И н д ек с_ эл _ 0 0 2 И н д ек с_ эл _ 0 0 3 И н д ек с_ эл _ 0 0 4 И н д ек с_ эл _ 0 0 5 И н д ек с_ эл _ 0 0 б И н д ек с_ эл _ 0 0 7 И н д ек с_ эл _ 0 0 8 Позитивные тесты индекс действителен, 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. Черноящичное тестирование веб-проекта — это манипуляции с одной или больше веб-страниц, зависимых друг от друга, |