фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
часть заработной платы платят за честность, так как именно нашему брату оказано доверие сказать "Поехали". И даже абсо- лютно далекий от тестирования господин Буянов косвенно под- твердил своим выбором мои слова (дальше поются строчки из припева песни Билли Джоела "Честность" ("Honesty")): Honesty is hardly ever heard. And mostly what I need from you. (Честность — это 50% + 1 единица того, что я жду от тебя.) Перевожу тему. Будет дано множество примеров того, что мы работаем на некий онлайн-стартап www.testshop.rs (rs — это не глобальный домен, как com или ru, а мои инициалы). Многие термины будут написаны по-английски с немедленным русским переводом и наоборот. Знание родной терминологии по- может работе в инофирме. Пользуясь случаем, хочу поблагодарить (в алфавитном порядке): Алекса Хатилова (Yahoo!) за превосходные лекции, многочасо- вые консультации по телефону и демонстрацию силы аналогий и примеров из жизни и Никиту Тулинова (Sun Microsystems), который принял меня, как брата, и наставил на путь истинный. Итак, в путь. Если что, пишите на qatest@gmail.com. ЧАСТЬ 1 • ЧТО ТАКОЕ БАГ • ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED • ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ • ЦИКЛ РАЗРАБОТКИ ПО ЧТО ТАКОЕ БАГ • ОПРЕДЕЛЕНИЕ БАГА • ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА • ЧТО ТАКОЕ ТЕСТИРОВАНИЕ • ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА • ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА огический закон исключенного третьего гласит, что любая вещь — это либо а, либо не-а. Третьего не дано, т.е. если у вас есть часы "Брегет" за номером 5, то любая вещь в этом мире будет либо вашими часами "Брегет" за номером 5, либо чем-то другим. Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по од- ному предмету. Задача проста — ожидать появления ваших часов "Брегет" за номером 5 и говорить "баг" при появлении любого предмета, отличного от них. Нетрудно догадаться, что такие предметы, как • пакет кефира; • будильник "Слава"; • буклет с предвыборными обещаниями кандидата в прези- денты Н., будут для нас багами. Далее. Рассмотрим, что объединяет следующие ситуации. 17 Л 18 Тестирование Дот Ком. Часть 1 1. Девушка рекламирует себя как хорошую, на все руки хо- зяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии. 2. Вы купили книгу по интернет-тестированию, а в ней рас- сказывается о приготовлении яичницы. 3. Девушка из пункта 1 прочитала книгу из пункта 2, но яич- ница пересолена. Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожи- даемого. Разбор ситуаций. 1. Ожидаемый результат -— девушка умеет готовить. Фактический результат — утро без завтрака. 2. Ожидаемый результат — знания по тестированию. Фактический результат — знания по кулинарии. 3. Ожидаемый результат — яичница будет приготовлена. Фактический результат — еще одно утро без завтрака. Определение бага Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result). В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого. Три условия жизни и процветания бага Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий: 1. Известен фактический результат; 2. Известен ожидаемый результат; 3. Известно, что результат из пункта 1 не равен результату из пункта 2. Что такое баг 19 Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом "баг". Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значе- ния, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма. Примеры багов из жизни: 1. Бутерброд падает маслом вниз. 2. Подхалимы и говоруны имеют намного больше шансов на повыше- ние, чем скромные честные труженики. 3. Несоответствие миловидной внешности и змеиной сущности. 4. Попугай воспроизводит на людях худшее из словарного запаса хо- зяина. 5. Автомобили российского производства. 6. Кот Бегемот в фильме В. Бортко "Мастер и Маргарита". Идем дальше. Что такое тестирование Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом: 1. Мы узнаем (или уже знаем) ожидаемый результат; 2. Мы узнаем (или уже знаем) фактический результат; 3. Мы сравниваем пункт 1 и пункт 2. Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществ- ляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в слу- чае несовпадения фактического и ожидаемого мы будем с улыб- кой мудреца смотреть на дилетантов, хлюпающих носами на мо- сковском ветру, и тихо, но веско (как дон Карлеоне) говорить: "Та-а-к, еще один баг". Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргу- ментации явился тот факт, что и те и другие имеют физическую обо- лочку (тело/железо) и неосязаемое составляющее, управляющее ею 20 Тестирование Дот Ком. Часть 1 (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов... Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать. С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет. Сложнее дело обстоит с ожидаемым результатом. Источники ожидаемого результата Основными источниками ожидаемого результата являются: 1. Спецификация. 2. Спецификация. 3. Спецификация. 4. Спецификация. 5. Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др. Спецификация на первой—четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это: • мать родная, а также • Друг, • товарищ и • брат. Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста. Спецификация — это инструмент, с помощью которого вы смо- жете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass). Итак, что же это за зверь? Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало. В большинстве случаев баг — это отклонение от специфика- ции (я говорю о компаниях, в которых спеки в принципе сущест- вуют и ими пользуются). Что такое баг 21 Пример Пункт 19.а спека #8724 "О регистрации нового пользователя" устанав- ливает: «Поле "Имя" должно быть обязательным. Страница с ошибкой должна быть показана, если пользователь посылает регистрационную форму без заполнения указанного поля». В общем все просто: • тестировщик идет на страничку с регистрационной формой; • кликаетлинк "Регистрация"; • заполняет все обязательные поля, кроме поля "Имя"; • нажимает на кнопку "Зарегистрироваться". Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug). Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессивном тести- ровании. .. Функциональные баги и баги спека Допустим, что ошибка не была показана и мы имеем классиче- ский случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека. Если вы внимательно читали пункт 19.а, то не могли не заметить (шутка), что непонятно, какое должно быть сообщение об ошибке (error message), т.е. фактически решение отдано на откуп про- граммисту и он может предусмотреть, что при соответствующей ситуации код выдаст: • НЕинформативное сообщение "Ошибка" и оставит пользо вателя ломать голову над тем, что он сделал неправильно, либо • информативное сообщение «Пожалуйста, введите ваше имя и нажмите кнопку "Регистрация"» и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки. Кстати, несколько лет назад был случай, когда программисты в специ- альном ПО, разработанном для американских тюрем, оставили "рабо- чее" название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: "Освобо- дить подонка". 22 Тестирование Дот Ком. Часть 1 В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — "баг в спецификации" (spec bug). Кстати, вот варианты развития ситуации с проблемным спеком: а. Скорее всего программист все же напишет информативное сооб щение об ошибке. Ваше дело послать е-мейл продюсеру (продю сером в интернет-компании называют товарища, создающего спеки), чтобы тот внес текст, уже написанный программистом, в пункт 19. а. б. Если программист написал нечто противоречащее здравому смыслу или стандарту, принятому в вашей компании, рапортуйте баг. в. Может случиться так, что вы не заметили проблемы в спеке и не заме тили, как программист написал сообщение об ошибке, противореча щее здравому смыслу или стандарту, принятому в вашей компании. Кстати, вот две релевантные политически важные вещи: 1. Как правило, работа в стартапе — это уникальный опыт, когда тяже- лый труд сочетается с радостью созидания, расслабленной обста- новкой (я, например, уже многие годы хожу на работу в шортах) и окружающими вас милыми, веселыми людьми. Но бывают нештат- ные ситуации (например, работа не сделана в срок или сделана не- качественно), и, когда дело дойдет до выяснения "кто виноват" и "что с ним сделать", многие из ваших коллег перестанут быть ми- лыми, веселыми людьми и активно начнут вешать собак друг на друга. Так вот, чтобы одну из этих собак не повесили на вас, посы- лайте е-мейлы, сохраняйте их и ответы на них и при случае пересы- лайте их заинтересованным сторонам. Пригодятся те е-мейлы в дальнейшем — хорошо, не пригодятся — еще лучше, тем более что каши они не просят, а сидят себе тихо и малодушно в своих фолде- рах и ничего не ждут от этой жизни. 2. Каждый должен заниматься своим делом и отвечать за свой участок работы. В случае если спек сделан некачественно, то лучше под- нять тревогу с рассылкой е-мейлов, чем делать допущения относи- тельно того, как должно работать ваше ПО. Перед завершением темы об ожидаемом и фактическом результа- тах рассмотрим примеры других источников ожидаемого резуль- тата, кроме спеков. 1. ЖИЗНЕННЫЙ ОПЫТ Как справедливо отметил Борис Слуцкий: "Не только пиво-раки мы ели и лакали". Мы также учились и работали, любили и нена- видели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот Что такое баг 23 опыт настолько полезен в нашем черном деле, что для демонстра- ции уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом. 2. ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук "ошибок трудных") Это один из наших главных союзников, порой даже и при нали- чии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек гово- рит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл ж producers@testshop.rs с предложением о включении в спек функциональности, позво- ляющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно назы- вается не багом, a Feature Request ("запрос об улучшении" — пока остановимся на таком переводе). 3. ОБЩЕНИЕ Даже самый лучший спек может вызвать необходимость в уточ- нениях. А что, если спека нет вообще? Наш ответ: общение. Со- ветуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хо- рошо, а две лучше. 4. УСТОЯВШИЕСЯ СТАНДАРТЫ Как правило, после регистрации, пользователь должен получить е-мейл с подтверждением. Если спек не упоминает о таком е-мейле, вы можете потребовать дополнить его на основании сложившей- ся практики. 5. СТАТИСТИЧЕСКИЕ ДАННЫЕ Было установлено, что средний пользователь теряет терпение, если web page (веб-страница) не загружается в течение 5 секунд. Эти данные можно использовать, проводя performance testing (тестирование скорости работы всей системы либо ее компонента). Как говорят американцы: "Your user is just one click away from your 24 Тестирование Дот Ком. Часть 1 competitor" ("Ваш пользователь находится на расстоянии в один клик от вашего конкурента"). Успех вашего проекта — это счастли- вые пользователи. Превышение 5 секунд — это превращение веб- сайта в зал ожиданий, в котором вряд ли кто захочет находиться. 6. АВТОРИТЕТНОЕ МНЕНИЕ Это может быть, например, мнение вашего начальника. 7. ДР. Другие. Отметим, что баг (bug) буквально переводится как "жук" или "букашка". Теперь, как я и обещал, немного истории. Согласно фольклору, баги вошли в лексикон компьютерщиков после случая, происшедшего в Гарвардском университете в 1947 г. После то- го как на реле прадедушки ПК Марка II присел отдохнуть мотылек, один из контактов слегка коротнуло и весь 15-тонный агрегат со скрежетом остановился. Инженеры проявили милосердие и извлекли мотылька, после чего аккуратно зафиксировали его скотчем в журнале испытаний с комментарием "Первый фактический случай найденного жука" ("First actual case of bug being found"). Итак, Краткое подведение итогов 1. Баг — это отклонение фактического результата от ожидаемого. 2. Главный источник ожидаемого результата в интернет-компании — это спецификация. 3. Спецификации сами не без греха, и в этом случае, как и в случае полного их отсутствия, у нас есть здравый смысл, устоявшиеся стандарты, опыт работы, статистика, авторитетное мнение и др. Задания для самопроверки 1. Ищите баги в чем угодно, введите это слово в свой лексикон и расписывайте самые яркие из них на листе бумаги по схеме: Ожидаемый результат/Фактический результат. 2. Подумайте, какие еще источники ожидаемого результата могут быть в работе тестировщика. 3. Побродите по Интернету, порегистрируйтесь (www.yahoo.com, www.hotmail.com и т.д.) и составьте список обязательных полей (required fields) на регистрационных формах. ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED • ЦЕЛЬ ТЕСТИРОВАНИЯ • ЧЕРНАЯ МАГИЯ И ЕЕ НЕМЕДЛЕННОЕ РАЗОБЛАЧЕНИЕ • ИДЕЯ О СТАТИСТИКЕ ДЛЯ ПОСТРЕЛИЗНЫХ БАГОВ • ТЕСТИРОВАНИЕ И QA (Quality Assurance) ез рассусоливаний и теоретизирования я прямо скажу, для чего все это нужно. Цель тестирования Цель тестирования — это нахождение багов до того, как их найдут пользователи. Другими словами, вклад тестировщика в счастье пользовате- ля — это приоритет в нахождении багов. Пусть в мире, где история искажена, ценности поруганы, а исти- ны ненадежны, слова, сказанные выше, будут скалой, в прочно- сти которой вы будете постоянно убеждаться. А теперь: Черная магия и ее немедленное разоблачение Есть две концепции, о которых необходимо знать, потому что они распространены и вредят как тестировщикам в частности, так и компании в целом. 25 Б Цель тестирования Decoded 27 ПЕРВАЯ КОНЦЕПЦИЯ: цель тестирования — это 100%-я про- верка ПО. РАЗОБЛАЧЕНИЕ ПЕРВОЙ КОНЦЕПЦИИ Вот вам код, написанный на языке программирования Python (здесь и далее номер является номером строки для удобства ссы- лок и не принадлежит к коду, за знаком # следует комментарий для данной строки): 1. user input = raw_input ("What is your totem animal?") # "Введите название вашего тотемного животного". 2. if user_ input == "frog": # ЕСЛИ пользователь ввел "лягушка", 3. print "You probably like green color" # вывести на экран "Вероятно, вам нравится зеленый цвет". 4. elif user_input == "owl": # ЕСЛИ пользователь ввел "сова", 5. print "You probably like grey color" # вывести на экран "Вероятно, вам нравится серый цвет". 6. elif user_input == "bear ": # ЕСЛИ пользователь ввел "медведь", 7. print "You probably like brown color" # вывести на экран "Вероятно, вам нравится коричневый цвет". 8. elif user_input == "": # ЕСЛИ пользователь не ввел никаких данных, 9. print "Probably, you don't know what is your totem animal" # вывести на экран "Вероятно, вы не знаете свое тотемное животное". Это маленькая, симпатичная и на первый взгляд никчемная про- грамма послужит нам для того, чтобы мы увидели 4 условия (conditions), одно из которых заработает, если мы ее запустим. Если условие верно, например, пользователь ввел "frog", то, как за преступлением — наказание (в идеальном случае), наступает последствие — выполнение условия (конечно, если код работает) — вывод на экран текста "You probably like green color". Ежу понятно, что для тестирования нам нужно проверить все 4 условия. 1. Ввести "frog". 2. Ввести "owl". 3. Ввести "bear". 4. Ничего не вводить, а просто равнодушно нажать Enter. |