Тестирование дот ком
Логический закон исключенного третьего гласит, что любая вещь — это либо А, либо не-А. Третьего не дано, т.е. если у вас есть часы «Брегет» за номером 5, то любая вещь в этом мире будет либо вашими часами «Брегет» за номером 5, либо чем-то другим.
Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов «Брегет» за номером 5 и говорить «баг» при появлении любого предмета, отличного от них.
Нетрудно догадаться, что такие предметы, как пакет кефира, будильник «Слава», буклет с предвыборными обещаниями кандидата в президенты Н. будут для нас багами.
Далее. Рассмотрим, что объединяет следующие ситуации.
- Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии.
- Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.
- Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
- Ожидаемый результат — девушка умеет готовить.
Фактический результат — утро без завтрака. - Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии. - Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.
Определение бага
Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.
Функциональные баги и баги спека
Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.
и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.
Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили «рабочее» название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: «Освободить подонка».
В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — «баг в спецификации» (spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
Кстати, вот две релевантные политически важные вещи:
- Как правило, работа в стартапе — это уникальный опыт, когда тяжелый труд сочетается с радостью созидания, расслабленной обстановкой (я, например, уже многие годы хожу на работу в шортах) и окружающими вас милыми, веселыми людьми. Но бывают нештатные ситуации (например, работа не сделана в срок или сделана не качественно), и, когда дело дойдет до выяснения «кто виноват» и «что с ним сделать», многие из ваших коллег перестанут быть милыми, веселыми людьми и активно начнут вешать собак друг на друга. Так вот, чтобы одну из этих собак не повесили на вас, посылайте емейлы, сохраняйте их и ответы на них и при случае пересылайте их заинтересованным сторонам. Пригодятся те емейлы в дальнейшем — хорошо, не пригодятся — еще лучше, тем более что каши они не просят, а сидят себе тихо и малодушно в своих фолдерах и ничего не ждут от этой жизни.
- Каждый должен заниматься своим делом и отвечать за свой участок работы. В случае если спек сделан некачественно, то лучше поднять тревогу с рассылкой емейлов, чем делать допущения относительно того, как должно работать ваше ПО.
Перед завершением темы об ожидаемом и фактическом результатах рассмотрим примеры других источников ожидаемого результата, кроме спеков.
ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: «Не только пиво-раки мы ели и лакали». Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.
ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)
Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл к [email protected] с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно называется не багом, а 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»).
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:
- Мы узнаем (или уже знаем) ожидаемый результат;
- Мы узнаем (или уже знаем) фактический результат;
- Мы сравниваем пункт 1 и пункт 2.
Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в случае несовпадения фактического и ожидаемого мы будем с улыбкой мудреца смотреть на дилетантов, хлюпающих носами на московском ветру, и тихо, но веско (как дон Карлеоне) говорить: «Та-а-к, еще один баг».
Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргументации явился тот факт, что и те и другие имеют физическую оболочку (тело/железо) и неосязаемое составляющее, управляющее ею (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов.
Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Тестирование DOT COM. Роман Савин
«Тестирование Дот Ком» — это первая книга, которую рекомендуют прочитать начинающему тестировщику. Выпущенная в 2007 году, данная книга стала библией в мире русскоязычного тестирования.
Цель книги — подготовить человека с нуля до получения работы в качестве тестировщика в российской или западной интернет-компании. Книга также будет интересна всем, кто хочет узнать больше о кухне стартапов и процессе разработки ПО.
Что такое Баг?
Логический закон исключенного третьего гласит, что любая вещь — это либо А, либо не-А. Третьего не дано, т.е. если у вас есть часы «Брегет» за номером 5, то любая вещь в этом мире будет либо вашими часами «Брегет» за номером 5, либо чем-то другим.
Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов «Брегет» за номером 5 и говорить «баг» при появлении любого предмета, отличного от них.
Нетрудно догадаться, что такие предметы, как пакет кефира, будильник «Слава», буклет с предвыборными обещаниями кандидата в президенты Н. будут для нас багами.
Далее. Рассмотрим, что объединяет следующие ситуации.
- Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии.
- Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.
- Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
- Ожидаемый результат — девушка умеет готовить.
Фактический результат — утро без завтрака. - Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии. - Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:
- Мы узнаем (или уже знаем) ожидаемый результат;
- Мы узнаем (или уже знаем) фактический результат;
- Мы сравниваем пункт 1 и пункт 2.
Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в случае несовпадения фактического и ожидаемого мы будем с улыбкой мудреца смотреть на дилетантов, хлюпающих носами на московском ветру, и тихо, но веско (как дон Карлеоне) говорить: «Та-а-к, еще один баг».
Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргументации явился тот факт, что и те и другие имеют физическую оболочку (тело/железо) и неосязаемое составляющее, управляющее ею (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов.
Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Определение бага
Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.
Тестирование дот ком
Что пишут в блогах
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
- Testing Like It Was 1980
- Boa Constrictor is doing Hacktoberfest 2021!
- Contributing to Open Source – Getting Started
- Full circle of Test Automation
- Five for Friday – October 1, 2021
- “The waves of Agile” listed on the AgileAlliance site
- Pursuing an ADHD Diagnosis after 15+ Years
- The Six Things Facilitator Can Do To Improve Ensembling Session
- No, Really, What Is Automation?
- An Inspired Evening
Разделы портала
Про инструменты
Этот курс лекций создан для тех, кто хочет обучиться тестированию, получить работу тестировщика в российской или западной интернет-компании, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов.
Книга целиком базируется на личном опыте освоения — с нуля — профессии тестировщика и многолетней работы автора в этом качестве в интернет-компаниях США.
Одна из причин, побудивших автора написать эту книгу, —«осознание собственного бессилия в поисках сиюминутного практического смысла при чтении классических сочинений по теории тестирования. », в особенности когда ты в поисках работы и время дорого. «Наиболее эффективный подход для тренинга тестировщиков — дать им практический инструментарий, поставить в нужную сторону мозги — и в бой. »
Эта книга и есть тот самый практический инструментарий. Здесь вы найдете проработанную структуру, профессиональное изложение темы, множество примеров и советов, а также «. легион того, о чем вам напрямую не напишут и не скажут, но что может быть не менее важно для выживания в софтверной компании, чем профессиональные знания».
Но это не все. Особенность книги в том, как излагается материал. Роман Савин отказался от традиционных канонов написания учебных пособий и превратил книгу в живую непринужденную беседу, насыщенную шуткой и иронией, не чуждую отступлений и даже воспоминаний, которые тем не менее встроены в контекст и работают на предмет как иллюстрационный материал.
Читать книгу интересно и весело. Убедитесь в этом сами.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
- Спецификация.
- Спецификация.
- Спецификация.
- Спецификация.
- Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.
Спецификация на первой— четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:
- мать родная, а также
- друг,
- товарищ и
- брат.
Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается «спек». Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).
Пример
В общем все просто:
Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессионном тестировании.
Три условия жизни и процветания бага
Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:
- Известен фактический результат;
- Известен ожидаемый результат;
- Известно, что результат из пункта 1 не равен результату из пункта 2.
Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом «баг». Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значения, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма.
Примеры багов из жизни:
- Бутерброд падает маслом вниз.
- Подхалимы и говоруны имеют намного больше шансов на повышение, чем скромные честные труженики.
- Несоответствие миловидной внешности и змеиной сущности.
- Попугай воспроизводит на людях худшее из словарного запаса хозяина.
- Автомобили российского производства.
- Кот Бегемот в фильме В. Бортко «Мастер и Маргарита».
ВВЕДЕНИЕ
Основа бэкграунда тестировщика — это логика,
здравый смысл и жизненный опыт. Народная мудрость
Дорогие друзья, я написал эти лекции по практике тестирования, чтобы просто и задушевно рассказать вам основные вещи, которые понадобятся для успешного старта и не менее успешной работы в интернет-компании в качестве тестировщика.
Я также уверен, что тихие вечера, проведенные за чтением моего скромного труда, откроют много полезного любому человеку, имеющему отношение к процессу создания программного обеспечения (ПО), так как качество, как тишина в кинозале, — дело общее.
Отдельной группой благодарных читателей, несомненно, выступят профессиональные рекрутеры, нанимающие народ для ударного труда в интернет-компаниях.
Кроме того, я надеюсь, что материал будет просто интересен всем, кто пользуется Интернетом и желает узнать, как работают интернет-компании.
Приведя десятки примеров, я попытался максимально проиллюстрировать материал, так, чтобы даже сугубо технические детали были понятны самому широкому кругу читателей.
Моя цель — не показать, что я знаю материал (как это делается при защите диплома), а помочь ВАМ узнать материал, и иллюстрации (текстовые и графические) — это лучшее вспомогательное средство, для того чтобы легче понять и усвоить смысл сказанного и оставить в памяти якорь ассоциации между иллюстрацией и проиллюстрированной мыслью.
Помимо просьб друзей, требований жены и намечающегося кризиса среднего возраста на подвиг меня толкнуло то, что в начале своей работы не раз и не два я пытался осилить классические сочинения по теории тестирования, но каждый раз осознание собственного бессилия в поисках сиюминутного практического смысла не давало мне дочитать очередной фолиант.
Безработная девушка Маша П. захотела стать бухгалтером. Она приходит на соответствующие курсы, но вместо прикладных, оплачиваемых знаний по назначению счетов и инструкций МНС ей преподают теорию макроэкономики и историю бухгалтерии. Маша думает, что она не сможет осилить бухгалтерию, и бросает курсы. В итоге Родина теряет потенциально блестящего бухгалтера и обретает реально радикального члена компартии.
Кроме того, есть политические нюансы работы; распространенные ошибки менеджмента; продюсеры, программисты и релиз-инженеры, работу которых нужно понимать изнутри, — в общем легион того, о чем вам напрямую не напишут и не скажут, но что может быть не менее важно для выживания в софтверной компании, чем профессиональные знания.
Будучи человеком честным и в некоторой степени благородным, признаюсь, что позаимствую классическое начало книг о тестировании, заключающееся в трусливом: «Не используйте знания из этой книги, если речь идет о тестировании критического ПО».
Итак, я свидетельствую, что все, о чем я расскажу, действительно работает, и работает именно так в крупнейших западных интернет-компаниях; я также свидетельствую, что все, о чем я расскажу, в силу объективных причин не может на 100 процентов гарантировать ПО от наличия проблем.
Поэтому сразу предупреждаю: эта книга не предназначена для тех, кто собирается тестировать критическое ПО, связанное, например, с мониторингом работы сердечной мышцы, или ПО для поражения точечных целей в странах с большими запасами нефти. Серьезно, если речь идет о жизни людей, лучше скормите эту книгу своему попугаю-жако (о попугаях позже).
Два важных момента:
- В отличие от деятельности юридической, деятельность тестировочная (для коммерческих проектов) не регулируется нормативными актами или другими формальными источниками.
Поэтому нет обязательных для исполнения правил о том, как эффективно протестировать ПО, какие документы нужно создать и в какой форме они должны быть.
Никто не возьмет вас за горло из-за того, что ваш тест-план не соответствует букве некого закона, пролоббированного некой продажной шкурой из не менее продажной фракции в интересах всем хорошо известной финансово-промышленной группы N.
В цехе тестировщиков ничто не является догмой (nothing is set in stone) и построение добротной системы поиска и превентирования ошибок в ПО полностью отдается на откуп профессионализму, добросовестности и творчеству тех, кто работает в конкретной интернет-компании.
Поэтому многие вещи, о которых пойдет речь (подходы, документы, процессы, даже названия), с одной стороны, имеют огромное количество вариаций в существующих интернет-компаниях и, с другой — могут практически использоваться в предложенной форме или, еще лучше, быть подогнанными вами под ту компанию, в которой вы работаете или, несомненно, будете работать в ближайшем будущем. - «То, что русскому хорошо, — для немца смерть». По аналогии: подходы к тестированию, степень формализации процессов и используемые документы, которые эффективно работают в крупных устоявшихся интернет компаниях, могут быть неприемлемы для интернет-стартапов (startup — молодая, амбициозная, многообещающая компания, живущая, как правило, короткую, но яркую жизнь), и наоборот.
Исходя из того что подавляющее большинство интернет-компаний — это стартапы, говорить будем о том, как эффективно провести тестирование и организовать процессы по улучшению качества именно в стартапах с прицелом на то, чтобы заложить фундамент департамента качества (QA department) для крупной устоявшейся интернет-компании, стать которой мечтает каждый стартап.
Вопрос дня: Что самое главное в нашем деле?
Ответ дня: РЕЗУЛЬТАТ!
Человек может быть прекрасным семьянином, увлекаться фотографией и превосходно петь арию «Libiamo Amor» из «Травиаты», но единственная и неповторимая прелесть его как тестировщика — это РЕЗУЛЬТАТ.
К вопросу о постановке мозгов и попугаях:
перед покупкой своего попугая-жако Василия я прочитал кучу литературы, но лишь одна мысль позволила мне осознать самое главное (в смысле домашних попугаев): «У вас есть хобби, друзья и работа. У вашего попугая есть только вы».
Так вот по аналогии:
Вы можете быть наделены множеством самых прекрасных и вечных добродетелей. Но в вашей работе тестировщика есть единственный смысл — РЕЗУЛЬТАТ.
Каков же этот РЕЗУЛЬТАТ (пишу «РЕЗУЛЬТАТ» заглавными буквами в последний раз)?
результатом работы тестировщика является счастье конечного пользователя (сказать «удовлетворение клиента» как-то язык не поворачивается). Причем «счастье» не в глобальном его значении, а та его часть, которая связана с качеством вашего продукта.
Например, некто Виктор Буянов бродит по Интернету в поисках диска с московским концертом Билли Джоела. Вот он наконец находит то, что искал, заполняет все необходимые формы и нажимает кнопку «Купить».
Если на следующей странице будет написано: «Дорогой Виктор, мы получили ваш заказ, ждите посылку» и через неделю почтальон принесет сам диск, то честь и хвала вам как тестировщикам.
Если же на следующей странице красуется «500 — Internal Server Error» (внутренняя ошибка сервера номер 500). и тишина, то пишите объяснительные.
Я дам вам знания, с которыми можно пройти интервью, получить интересную работу и начать новую жизнь, но кроме прикладных моментов следует твердо знать, что тестировщикам бoльшую часть заработной платы платят за честность, так как именно нашему брату оказано доверие сказать «Поехали». И даже абсолютно далекий от тестирования господин Буянов косвенно подтвердил своим выбором мои слова (дальше поются строчки из припева песни Билли Джоела «Честность» («Honesty»)):
Honesty is hardly ever heard.
And mostly what I need from you.
(Честность — это 50% + 1 единица того, что я жду от тебя.)
Многие термины будут написаны по-английски с немедленным русским переводом и наоборот. Знание родной терминологии поможет работе в инофирме.
Пользуясь случаем, хочу поблагодарить (в алфавитном порядке):
Алекса Хатилова (Yahoo!) за превосходные лекции, многочасовые консультации по телефону и демонстрацию силы аналогий и примеров из жизни и Никиту Тулинова (Sun Microsystems), который принял меня, как брата, и наставил на путь истинный.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
- Спецификация.
- Спецификация.
- Спецификация.
- Спецификация.
- Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.
Спецификация на первой— четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:
- мать родная, а также
- друг,
- товарищ и
- брат.
Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается «спек». Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).
Пример
В общем все просто:
Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессионном тестировании.
Три условия жизни и процветания бага
Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:
- Известен фактический результат;
- Известен ожидаемый результат;
- Известно, что результат из пункта 1 не равен результату из пункта 2.
Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом «баг». Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значения, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма.
Примеры багов из жизни:
- Бутерброд падает маслом вниз.
- Подхалимы и говоруны имеют намного больше шансов на повышение, чем скромные честные труженики.
- Несоответствие миловидной внешности и змеиной сущности.
- Попугай воспроизводит на людях худшее из словарного запаса хозяина.
- Автомобили российского производства.
- Кот Бегемот в фильме В. Бортко «Мастер и Маргарита».
Функциональные баги и баги спека
Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.
и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.
Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили «рабочее» название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: «Освободить подонка».
В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — «баг в спецификации» (spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
Кстати, вот две релевантные политически важные вещи:
- Как правило, работа в стартапе — это уникальный опыт, когда тяжелый труд сочетается с радостью созидания, расслабленной обстановкой (я, например, уже многие годы хожу на работу в шортах) и окружающими вас милыми, веселыми людьми. Но бывают нештатные ситуации (например, работа не сделана в срок или сделана не качественно), и, когда дело дойдет до выяснения «кто виноват» и «что с ним сделать», многие из ваших коллег перестанут быть милыми, веселыми людьми и активно начнут вешать собак друг на друга. Так вот, чтобы одну из этих собак не повесили на вас, посылайте емейлы, сохраняйте их и ответы на них и при случае пересылайте их заинтересованным сторонам. Пригодятся те емейлы в дальнейшем — хорошо, не пригодятся — еще лучше, тем более что каши они не просят, а сидят себе тихо и малодушно в своих фолдерах и ничего не ждут от этой жизни.
- Каждый должен заниматься своим делом и отвечать за свой участок работы. В случае если спек сделан некачественно, то лучше поднять тревогу с рассылкой емейлов, чем делать допущения относительно того, как должно работать ваше ПО.
Перед завершением темы об ожидаемом и фактическом результатах рассмотрим примеры других источников ожидаемого результата, кроме спеков.
ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: «Не только пиво-раки мы ели и лакали». Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.
ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)
Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл к [email protected] с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно называется не багом, а 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»).
Читайте также: