книга тестирование дот ком или пособие по жестокому обращению с багами в интернет стартапах
Часть I
Что такое Баг?
Логический закон исключенного третьего гласит, что любая вещь — это либо А, либо не-А. Третьего не дано, т.е. если у вас есть часы «Брегет» за номером 5, то любая вещь в этом мире будет либо вашими часами «Брегет» за номером 5, либо чем-то другим.
Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов «Брегет» за номером 5 и говорить «баг» при появлении любого предмета, отличного от них.
Нетрудно догадаться, что такие предметы, как пакет кефира, будильник «Слава», буклет с предвыборными обещаниями кандидата в президенты Н. будут для нас багами.
Далее. Рассмотрим, что объединяет следующие ситуации.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
Определение бага
Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.
Три условия жизни и процветания бага
Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:
Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом «баг». Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значения, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма.
Примеры багов из жизни:
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:
Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в случае несовпадения фактического и ожидаемого мы будем с улыбкой мудреца смотреть на дилетантов, хлюпающих носами на московском ветру, и тихо, но веско (как дон Карлеоне) говорить: «Та-а-к, еще один баг».
Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргументации явился тот факт, что и те и другие имеют физическую оболочку (тело/железо) и неосязаемое составляющее, управляющее ею (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов.
Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
Спецификация на первой— четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:
Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается «спек». Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).
Пример
Пункт 19.а спека #8724 «О регистрации нового пользователя» устанавливает: «Поле «Имя» должно быть обязательным. Страница с ошибкой должна быть показана, если пользователь посылает регистрационную форму без заполнения указанного поля».
В общем все просто:
Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессионном тестировании.
Функциональные баги и баги спека
Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.
Если вы внимательно читали пункт 19.а, то не могли не заметить (шутка), что непонятно, какое должно быть сообщение об ошибке (error message), т.е. фактически решение отдано на откуп про-граммисту и он может предусмотреть, что при соответствующей ситуации код выдаст:
и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.
Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили «рабочее» название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: «Освободить подонка».
В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — «баг в спецификации» (spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
Кстати, вот две релевантные политически важные вещи:
Перед завершением темы об ожидаемом и фактическом результатах рассмотрим примеры других источников ожидаемого результата, кроме спеков.
ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: «Не только пиво-раки мы ели и лакали». Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.
ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)
Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл к producers@testshop.rs с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно называется не багом, а Feature Request («запрос об улучшении» — пока остановимся на таком переводе).
ОБЩЕНИЕ
Даже самый лучший спек может вызвать необходимость в уточнениях. А что, если спека нет вообще? Наш ответ: общение. Советуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хорошо, а две лучше.
УСТОЯВШИЕСЯ СТАНДАРТЫ
Как правило, после регистрации, пользователь должен получить е-мейл с подтверждением. Если спек не упоминает о таком е-мейле, вы можете потребовать дополнить его на основании сложившейся практики.
СТАТИСТИЧЕСКИЕ ДАННЫЕ
Было установлено, что средний пользователь теряет терпение, если web page (веб-страница) не загружается в течение 5 секунд. Эти данные можно использовать, проводя performance testing (тестирование скорости работы всей системы либо ее компонента). Как говорят американцы: «Your user is just one click away from your competitor» («Ваш пользователь находится на расстоянии в один клик от вашего конкурента»). Успех вашего проекта — это счастливые пользователи. Превышение 5 секунд — это превращение веб-сайта в зал ожиданий, в котором вряд ли кто захочет находиться.
АВТОРИТЕТНОЕ МНЕНИЕ
Это может быть, например, мнение вашего начальника.
Отметим, что баг (bug) буквально переводится как «жук» или «букашка».
Теперь, как я и обещал, немного истории.
Согласно фольклору, баги вошли в лексикон компьютерщиков после случая, происшедшего в Гарвардском университете в 1947 г. После того как на реле прадедушки ПК Маркa II присел отдохнуть мотылек, один из контактов слегка коротнуло и весь 15тонный агрегат со скрежетом остановился. Инженеры проявили милосердие и извлекли мотылька, после чего аккуратно зафиксировали его скотчем в журнале испытаний с комментарием «Первый фактический случай найденного жука» («First actual case of bug being found»).
Читать онлайн «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах»
Автор Роман Савин
Роман Савин
teстирование
или П о с о б и е по жестокому
обращению с б а г а м и
в интернет-стартапах
Одна из причин, побудивших автора напи-
сать эту книгу, — «осознание собственного
бессилия в поисках сиюминутного практи-
ческого смысла при чтении классических
сочинений по теории тестирования. », в
особенности когда ты в поисках работы и
время дорого. «Наиболее эффективный
подход для тренинга тестировщиков — дать
им практический инструментарий, поставить
в нужную сторону мозги — и в бой. »
Эта книга и есть тот самый практический
инструментарий. Здесь вы найдете прорабо-
танную структуру, профессиональное изло-
жение темы, множество примеров и советов,
а также «. легион того, о чем вам напрямую
не напишут и не скажут, но что может быть не
менее важно для выживания в софтверной
компании, чем профессиональные знания».
Но это не все. Особенность книги в том,
как излагается материал. Роман Савин отка-
зался от традиционных канонов написания
учебных пособий и превратил книгу в живую
непринужденную беседу, насыщенную шут-
кой и иронией, не чуждую отступлений и да-
же воспоминаний, которые тем не менее
встроены в контекст и работают на предмет
как иллюстрационный материал.
Читать книгу интересно и весело. Убеди-
Роман Савин
tестирование
или Пособие по жестокому
обращению с багами
в интернет-стартапах
ИЗДАТЕЛЬСТВО «ДЕЛО» • МОСКВА • 2007
УДК 004. 415. 53 ББК
32. 973. 2-018. 2я7 С13
Савин Р.
С13 Тестирование Дот Ком, или Пособие по жестокому обра-
щению с багами в интернет-стартапах. — М. : Дело, 2007. —
ISBN 978-5-7749-0460-0
Этот курс лекций создан для тех, кто хочет обучиться тестированию, получить работу тестировщика в российской или западной интернет-ком-
пании, понять, как вести себя в корпоративном окружении, и добиться
профессионального и личностного роста. Он будет интересен и участни-
кам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим
понять кухню интернет-стартапов.
Книга целиком базируется на личном опыте освоения — с нуля —
профессии тестировщика и многолетней работы автора в этом качестве в
УДК 004. 415. 53 ББК
32. 973. 2-018. 2я7
ISBN 978-5-7749-0460-0
СОДЕРЖАНИЕ
Ч а с т ь 1
ОПРЕДЕЛЕНИЕ БАГА 18
ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА 18
ЧТО ТАКОЕ ТЕСТИРОВАНИЕ 19
ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА 20
ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА 21
ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED 25
ЦЕЛЬ ТЕСТИРОВАНИЯ 25
ЧЕРНАЯ МАГИЯ И ЕЕ НЕМЕДЛЕННОЕ РАЗОБЛАЧЕНИЕ 25
Разоблачение концепции о 100%-м тестировании ПО
Разоблачение концепции о количестве багов,
найденных до релиза
ИДЕЯ О СТАТИСТИКЕ ДЛЯ ПОСТРЕЛИЗНЫХ БАГОВ 29
ТЕСТИРОВАНИЕ ИОЛ (Quality Assurance) 32
ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ 35
ЧТО ТАКОЕ ТЕСТ-КЕЙС 35
СТРУКТУРА ТЕСТ-КЕЙСА. 37
ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА (test case result) 39
ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА 39
ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ 43
ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА 44
СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ
В ОДНОМ ТЕСТ-КЕЙСЕ? 47
ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ 50
СОСТОЯНИЯ ТЕСТ-КЕЙСА 62
А НАПОСЛЕДОК Я СКАЖУ 63
ЦИКЛ РАЗРАБОТКИ ПО 67
Документ о требованиях маркетинга (MRD)
РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ СПЕКА 71
Разница между идеей и дизайном
Борьба с неверными толкованиями спека
Документ о внутреннем дизайне кода
Личная версия сайта программиста
Причины появление багов кода
Меры по оздоровлению кода и превентированию багов
Концепция стоимости бага
Три основных занятия программиста
Необходимость замораживания кода
Виды багов кода Хранение
документации в CVS Обсуждение тест-
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ 104
Определение, виды и версии релизов
Действующие лица Создаем
БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО 122
Ч а с т ь 2
ЦИКЛ ТЕСТИРОВАНИЯ ПО 131
ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ 133
Что такое функциональность Источники
знания о функциональности Эксплоринг
ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ 135
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ 136
КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ 139
ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ 142
Черный ящик (black box testing)
Белый ящик (white box testing)
Серый ящик (grey box testing)
ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ 151
Функциональное тестирование (functional testing) Тестирование интерфейса пользователя (UI testing) Тестирование локализации (localization testing)
Тестирование скорости и надежности
(load/stress/performance testing) Тестирование
безопасности (security testing) Тестирование опыта
пользователя (usability testing) Тестирование
совместимости (compatibility testing)
ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ 157
Альфа-тестировщик (alpha tester)
Бета-тестировщик (beta tester)
ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ 157
До передачи пользователю — альфа-тестирование
Тест приемки (smoke test, sanity test или confidence test)
Тестирование новых фунщиональностей
(new feature testing) Регрессивное
тестирование (regression testing) Тест сдачи
(acceptance of certification test)
После передачи пользователю — бета-тестирование
ПО КРИТЕРИЮ «ПОЗИТИВНОСТИ» СЦЕНАРИЕВ 158
Позитивное тестирование (positive testing)
Негативное тестирование (negative testing)
ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ
Компонентное тестирование (component testing)
Интеграционное тестирование (integration testing) Системное (или энд-ту-энд) тестирование (system or end-to-end testing)
ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ 166
Ручное тестирование (manual testing)
Автоматизированное тестирование (automated testing) Смешанное/полуавтоматизированное тестирование
(semi automated testing)
ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ 169
Тестирование по документации (formal/documented
testing) Эд Хок тестирование (Ad
Ч а с т ь 3
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И ПРАКТИЧЕСКАЯ
МЕТОДОЛОГИЯ 173
МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА 174
МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ : 178
Черновик—Чистовик (dirty list — white list) Матричная раскладка (matrices) Блок-схемы
МЕТОДЫ ОТБОРА ТЕСТОВ 188
Оценка риска (risk estimate) Эквивалентные
классы (equivalent classes) Пограничные
значения (boundary values)
ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ 205
ЧТО ТАКОЕ СИСТЕМА ТРЭКИНГА БАГОВ 205
Bug number (номер бага) Summary
(краткое описание) Description and
steps to reproduce
(описание и шаги для воспроизведения проблемы)
Слинкованная картинка (linked image)
Однострочное текстовое поле (textbox)
Многострочное текстовое поле (text entry area)
Поле пароля (password field)
Ниспадающее меню (pull down menu)
Радио кнопка (radio button)
Submitted by (автор бага)
Date submitted (дата и время рождения бага)
Assigned to (держатель бага)
Assigned by (имя передавшего баг)
Verifier (имя того, кто должен проверить ремонт) Component (компонент)
Found on (где был найден баг)
Version found (версия, в которой был найден баг) Build found (билд, в котором был найден баг) Version fixed (версия с починенным кодом)
Build fixed (билд с починенным кодом)
Severity (серьезность бага)
Priority (приоритет бага)
Notify list (список для оповещения)
Change history (история изменений)
Not assigned (не приписан)
Fix in progress (баг ремонтируется)
Fixed (баг отремонтирован)
Build in progress (билд на тест машину в процессе) Verify (проведи регрессивное тестирование)
Fix is verified (ремонт был успешен)
Verification failed (ремонт был неуспешен)
Can’t reproduce (не могу воспроизвести)
3rd party bug (не наш баг)
No longer applicable (поезд ушел)
ПРОЦЕСС ТРЭКИНГА БАГОВ 245
Концептуальное рассмотрение процесса
Процесс и атрибуты Конкретный пример
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 1:
ТЕСТИРОВАНИЕ НОВЫХ ФИЧА (new feature testing) 257
ТЕСТ-СМЕТА (test estimation) 259
КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ (entry/exit criteria) 265
ТЕСТ-ПЛАН (test plan) 266
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 2:
РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ (regression testing) 271
ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО
РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ 277
Приоретизация тест-комплектов и тест-кейсов
Оптимизация тест-комплектов Найм новых
тестировщиков Автоматизация регрессивного
Ч а с т ь 4
КАК УСТРОИТЬСЯ НА ПЕРВУЮ РАБОТУ 285
МЕНТАЛЬНЫЙ НАСТРОЙ 285
ЭТАПЫ ПОИСКА ПЕРВОЙ РАБОТЫ ТЕСТИРОВЩИКОМ 287
Работа с агентством по трудоустройству
Компания по рекламе себя
Нюансы живого интервью
Список типичных вопросов и правильных ответов
ИСТОРИЯ ОБ ОЛЕ И ДЖОРДЖЕ 306
Моим любимым Маме и Марине посвящается, чьи любовь и вера — самое драгоценное,
что я получил от жизни.
ВВЕДЕНИЕ
Основа бэкграунда тестировщика —
это логика, здравый смысл и жизненный опыт.
я написал эти лекции по практике тестирования, чтобы просто и
задушевно рассказать вам основные вещи, которые понадобятся
для успешного старта и не менее успешной работы в интер-
нет-компании в качестве тестировщика.
Я также уверен, что тихие вечера, проведенные за чтением моего
скромного труда, откроют много полезного любому человеку, имею-
щему отношение к процессу создания программного обеспече-
ния (ПО), так как качество, как тишина в кинозале, — дело общее.
Отдельной группой благодарных читателей, несомненно, выступят
ного труда в интернет-компаниях.
Кроме того, я надеюсь, что материал будет просто интересен всем, кто пользуется Интернетом и желает узнать, как работают интер-
Приведя десятки примеров, я попытался максимально проил-
люстрировать материал, так, чтобы даже сугубо технические
детали были понятны самому широкому кругу читателей.
Моя цель — не показать, что я знаю материал (как это делает-
ся при защите диплома), а помочь ВАМ узнать материал, и ил-
люстрации (текстовые и графические) — это лучшее вспомога-
тельное средство, для того чтобы
• легче понять и усвоить смысл сказанного и
• оставить в памяти якорь ассоциации между иллюстра-
цией и проиллюстрированной мыслью.
Помимо просьб друзей, требований жены и намечающегося кри-
зиса среднего возраста на подвиг меня толкнуло то, что в начале
своей работы не раз и не два я пытался осилить классические со-
чинения по теории тестирования, но каждый раз осознание соб-
ственного бессилия в поисках сиюминутного практического
смысла не давало мне дочитать очередной фолиант.
Пример
Безработная девушка Маша П. захотела стать бухгалтером. Она приходит
на соответствующие курсы, но вместо прикладных, оплачиваемых знаний
по назначению счетов и инструкций МНС ей преподают теорию макроэко-
номики и историю бухгалтерии. Маша думает, что она не сможет осилить
бухгалтерию, и бросает курсы. В итоге Родина теряет потенциально бле-
стящего бухгалтера и обретает реально радикального члена компартии.
Я преклоняюсь перед предметом «история». О пользе Теории (с
большой буквы «Т») и говорить не приходится, но, как я убедился
на своем многолетнем опыте работы и преподавания, наиболее
эффективный подход к тренингу тестировщиков заключается
в том, чтобы дать им практический инструментарий, напра-
вить мозги в нужную сторону — и в бой, а теоретические мета-
ния тридцатилетней давности можно почитать на досуге, после
того как устроился на работу.
• политические нюансы работы;
• распространенные ошибки менеджмента;
• продюсеры, программисты и релиз-инженеры, работу ко-
Часть I
Что такое Баг?
Логический закон исключенного третьего гласит, что любая вещь — это либо А, либо не-А. Третьего не дано, т.е. если у вас есть часы «Брегет» за номером 5, то любая вещь в этом мире будет либо вашими часами «Брегет» за номером 5, либо чем-то другим.
Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов «Брегет» за номером 5 и говорить «баг» при появлении любого предмета, отличного от них.
Нетрудно догадаться, что такие предметы, как пакет кефира, будильник «Слава», буклет с предвыборными обещаниями кандидата в президенты Н. будут для нас багами.
Далее. Рассмотрим, что объединяет следующие ситуации.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
Определение бага
Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.
Три условия жизни и процветания бага
Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:
Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом «баг». Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значения, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма.
Примеры багов из жизни:
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:
Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в случае несовпадения фактического и ожидаемого мы будем с улыбкой мудреца смотреть на дилетантов, хлюпающих носами на московском ветру, и тихо, но веско (как дон Карлеоне) говорить: «Та-а-к, еще один баг».
Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргументации явился тот факт, что и те и другие имеют физическую оболочку (тело/железо) и неосязаемое составляющее, управляющее ею (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов.
Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
Спецификация на первой— четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:
Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается «спек». Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).
Пример
Пункт 19.а спека #8724 «О регистрации нового пользователя» устанавливает: «Поле «Имя» должно быть обязательным. Страница с ошибкой должна быть показана, если пользователь посылает регистрационную форму без заполнения указанного поля».
В общем все просто:
Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессионном тестировании.
Функциональные баги и баги спека
Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.
Если вы внимательно читали пункт 19.а, то не могли не заметить (шутка), что непонятно, какое должно быть сообщение об ошибке (error message), т.е. фактически решение отдано на откуп про-граммисту и он может предусмотреть, что при соответствующей ситуации код выдаст:
и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.
Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили «рабочее» название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: «Освободить подонка».
В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — «баг в спецификации» (spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
Кстати, вот две релевантные политически важные вещи:
Перед завершением темы об ожидаемом и фактическом результатах рассмотрим примеры других источников ожидаемого результата, кроме спеков.
ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: «Не только пиво-раки мы ели и лакали». Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.
ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)
Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл к producers@testshop.rs с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно называется не багом, а Feature Request («запрос об улучшении» — пока остановимся на таком переводе).
ОБЩЕНИЕ
Даже самый лучший спек может вызвать необходимость в уточнениях. А что, если спека нет вообще? Наш ответ: общение. Советуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хорошо, а две лучше.
УСТОЯВШИЕСЯ СТАНДАРТЫ
Как правило, после регистрации, пользователь должен получить е-мейл с подтверждением. Если спек не упоминает о таком е-мейле, вы можете потребовать дополнить его на основании сложившейся практики.
СТАТИСТИЧЕСКИЕ ДАННЫЕ
Было установлено, что средний пользователь теряет терпение, если web page (веб-страница) не загружается в течение 5 секунд. Эти данные можно использовать, проводя performance testing (тестирование скорости работы всей системы либо ее компонента). Как говорят американцы: «Your user is just one click away from your competitor» («Ваш пользователь находится на расстоянии в один клик от вашего конкурента»). Успех вашего проекта — это счастливые пользователи. Превышение 5 секунд — это превращение веб-сайта в зал ожиданий, в котором вряд ли кто захочет находиться.
АВТОРИТЕТНОЕ МНЕНИЕ
Это может быть, например, мнение вашего начальника.
Отметим, что баг (bug) буквально переводится как «жук» или «букашка».
Теперь, как я и обещал, немного истории.
Согласно фольклору, баги вошли в лексикон компьютерщиков после случая, происшедшего в Гарвардском университете в 1947 г. После того как на реле прадедушки ПК Маркa II присел отдохнуть мотылек, один из контактов слегка коротнуло и весь 15тонный агрегат со скрежетом остановился. Инженеры проявили милосердие и извлекли мотылька, после чего аккуратно зафиксировали его скотчем в журнале испытаний с комментарием «Первый фактический случай найденного жука» («First actual case of bug being found»).