Под катом мой спич на конференции Fun ConfeT&QA на тему «Баг не воспроизводится… Что делать?!»

Вы нашли баг — но не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести.
Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально.
Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его.
Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли.
Знакомо? Наверняка.
Что делать в таких ситуациях?
Писать в баг-трекер или не писать?
А был ли баг вообще? Поверят ли вам?
Сколько времени потратить на попытки воспроизвести хитрый баг?
Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.

Недавно я публиковал обзорный доклад "Selenium: от инструмента к стандарту", в котором я рассказал о том, как развивался инструмент Selenium. Конечно он и дальше будет эволюционировать и в него будут добавляться новые возможности.

Но есть некоторые «фичи», которых в Selenium нет и скорее всего не будет. Среди них: загрузка файлов с сервера, работа с сайтами, требующими авторизации, проверка кодов ответа на HTTP-запросы. Их не планируется добавлять в Selenium, потому что более правильным способом их реализации является использование вспомогательного прокси-сервера, работающего в связке с Selenium. Наиболее подходящим для этой цели является BrowserMobProxy, который в своё время «отпочковался» от Selenium и стал самостоятельным продуктом.

Под катом ещё один доклад с конференции ConfeT&QA, в котором рассказывается о том, как при помощи связки Selenium и BrowserMobProxy реализовать вышеупомянутые «фичи». Ссылка на проект с кодом примеров на гитхабе прилагается.

Инструмент Selenium медленно, но неуклонно продолжает развиваться, постепенно превращаясь в стандарт автоматизации веб-приложений и даже проникая в область автоматизации мобильных приложений (в том числе нативных и гибридных).

Осенью 2013 года я дважды на конференциях (сначала SECR, потом ConfeT&QA) рассказывал о том, как происходило развитие инструмента Selenium и каково текущее состояние дел. Предлагаю вашему вниманию запись, сделанную на второй из упомянутых конференций.

Эта статья является продолжением более общей статьи «Что такое Selenium?», в которой объясняется, какое положение занимает Selenium WebDriver среди других инструментов автоматизации веб-приложений.

Здесь я постараюсь рассказать более подробно о том, что такое Selenium WebDriver, и почему его бессмысленно сравнивать с TestComplete, QuickTest Pro и другими инструментами автоматизации тестирования. И дело не только в том, что Selenium WebDriver бесплатный и открытый – его столь же бессмысленно сравнивать с другими бесплатными инструментами, такими как Sahi или Robot Framework.

Почему?

Потому что Selenium WebDriver – это не инструмент для автоматизации тестирования.

А что же это такое?

На этот вопрос можно дать несколько разных ответов, сначала я дам короткие ответы, а потом – более подробные.

Кроме того, я объясню, почему Selenium WebDriver имеет такой убогий и неудобный в использовании интерфейс (набор команд), почему он не генерирует красивые отчёты и почему несмотря на всё это он настолько популярен :)

На всякий случай оговорюсь, что хотя в этой статье речь идёт про WebDriver, многие аргументы справедливы и в отношении Selenium RC, но я не буду ничего говорить специально про эту устаревшую версию, потому что её место – на свалке истории.

Время от времени мне приходится распутывать терминологические хитросплетения, связанные с употреблением словосочетаний, в которых встречается слово Selenium – Selenium 2.0, Selenium IDE, Selenium RC, Selenium WebDriver, Selenium Server, Selenium Grid.

Путаница возникает во многом из-за того, что нигде нет чёткого описания всех этих терминов на одной страничке, и я постараюсь восполнить этот информационный пробел.

Наконец-то мы завершили и опубликовали перевод на русский язык документации по инструменту Selenium, пожалуй, наиболее популярному в последнее время инструменту автоматизации тестов для веб-приложений.

Русская версия в определенном смысле даже лучше, чем оригинальная, потому что в нее включены дополнительные главы, скомпилированные из статей в Selenium Wiki, которые заполняют «белые пятна», имеющиеся в официальном руководстве пользователя.

Мы надеемся, что теперь, благодаря преодолению языкового барьера, число поклонников Selenium будет расти ещё быстрее, и мы будем рады видеть Вас в наших рядах!

(Под катом — благодарности спонсорам и участникам проекта по переводу)

Завершилась первая на просторах бывшего СНГ онлайн-конференция тестировщиков ConfeT&QA. Опубликован официальный анонс о закрытии конференции, там же можно найти ссылки на отзывы в блогах и в твиттере. Лучшие докладчики и самые активные участники получили призы.

Подведя итоги конференции, мы решили немного порадовать тех, кто не смог на неё попасть — представляем вашему вниманию запись выступления Натальи Руколь, которое было признано лучшим по результам опроса участников конференции.

Что успеет обычный тестировщик за 20 минут?

Выпить две чашки кофе? Съесть коробку конфет? Найти еще один баг?

Теперь за 20 минут можно получить новые знания в области тестирования ПО, узнать ответы на давно мучившие вас вопросы и увидеть простые решения сложных задач.

Встречайте: ConfeT&QA Online 2011 — международная конференция по тестированию ПО прямо у вас дома или в вашем офисе!
ConfeT&QA Online 2011 — это

• 15 мотивационных докладов продолжительностью по 20 минут на самые актуальные темы в области тестирования
• вопросы и ответы в прямом эфире
• обсуждения в закрытом форуме и офлайн-версии докладов
• реальные примеры, мегабайты кода и дополнительных материалов
• дискуссии, холивары, создание и развенчивание мифов
• 5 дней подряд, с 17 по 21 октября 2011 года, с 17 до 19 часов (по московскому времени)
• и вам даже не придется вставать с дивана!

Специально для тех, кто не смог попасть на конференцию SQA Days 9, которая проходила 22-23 апреля 2011 года в Казани, или не сумел посетить какой-то из докладов, который очень хотел послушать, или не успел задать докладчикам свой вопрос, высказать возражения, дополнить своими идеями или опытом — конференция продолжается в онлайне!

Онлайн-продолжение — это:

• доступ к материалам конференции (аудио, видеозаписи, слайдкасты),
• возможность общения с докладчиками в онлайне,
• ценные призы и подарки от IT-CONF, портала тестировщиков Software-Testing.Ru, и других партнеров SQA Days.

Как это будет проходить:

В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: «тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом» (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).

За это тестирование методом свободного поиска часто подвергается критике — как можно отказаться от планов, а как же управляемость, контроль и учёт? И вообще, если не будет планов, тогда каждый будет делать кто во что горазд, что-то будет протестировано несколько раз, что-то вообще не будет протестировано, люди не будут знать, что им делать.

Но в действительности сторонники тестирования методом свободного поиска вовсе не призывают к анархии. Напротив, огромное количество статей Джеймса Баха посвящено планированию.

Кажущееся противоречие разрешается очень просто

На тренингах по тестированию методом свободного поиска, которые я провожу время от времени, каждый раз возникает обсуждение вопроса о том, нужно ли делать описания тестов, а если нужно, то насколько подробные. Я обычно даю достаточно радикальный совет — если есть возможность, не пишите вовсе, либо, если очень надо, то пишите, но как можно меньше. Записывайте не сценарии, а идеи, в результате получается сплошная экономия — сначала тратится меньше времени на написание, а потом тратится меньше времени на переписывание.

Но экономия времени при написании — это ещё не всё. Едва ли не более важным фактором является то, что в многословных описаниях теряется смысл, который туда пытался заложить тест-дизайнер. Поэтому опытному тестировщику работать с короткими описаниями проще, чем с подробными длинными сценариями. И сегодня я хочу представить вашему вниманию перевод небольшой заметки Роба Лэмберта (Rob Lambert), в которой он описывает эксперимент объясняющий этот феномен.

Less Is More, или Меньше слов — больше смысла.

Как стремящийся к совершенству писатель и неплохой специалист по коммуникациям, я трачу немало времени на изучение того, как можно повысить эффективность коммуникаций. И одна из самых лучших техник — избавление от тех элементов, которые игнорируются читателями или слушателями.

В письменной речи это означает удаление слов, предложений или даже целых кусков текста, которые, как вам кажется, или как вы знаете, будут проигнорированы. Конечно, здесь много субъективности. Я тоже не знаю наверняка, что можно выбросить, а что следует оставить, но тем не менее, подвергаю свои тексты жёсткому саморедактированию.

Если вы пользуетесь твиттером, вы представляете, как это происходит. Иногда приходится немало потрудиться, чтобы суметь выразить свою мысль, используя всего 140 символов, но зато результат получается впечатляющим. Это очень полезная практика, потому что краткость, как известно — сестра таланта.

Большинство моих текстов становятся существенно короче после того, как проходят этап «ужимания», хотя, если постараться, там можно найти ещё немало «ваты».

Однако сейчас я хочу поговорить о том, как эта идея может быть использована для повышения качества тестов.

Предыдущая заметка содержала перечень советов тестировщикам, как положительным образом влиять на программистов.

А вот рекомендации относительно того, как тестировщики могут оказывать позитивное влияние на менеджеров.

• Оказывайте проекту сервис, а не будьте помехой. Вы поставляете информацию, а не насаждаете процессы.
• Предоставьте менеджерам информацию, которая им требуется для принятия решений, а затем позвольте им принять эти решения.
• Полностью осознавайте, что они принимают не технические, а бизнес-решения.
• Помните, что продукт не обязательно должен соответствовать вашему стандарту качества.
• Ни менеджер разработки, ни кто-либо другой не обременен должностной обязанностью делать вас счастливым. Возможно, часть их работы — помочь вам работать более эффективно. Помогите им разобраться, как это сделать. В частности, обратите внимание на тот факт, что…

Недавно в комментариях в очередной раз попалась мне на глаза легенда про Чёрную Команду, рассказанная Томом ДеМарко в свой книге «Человеческий фактор». Книга замечательная, а легенда дурацкая. Так и хочется пожелать, чтобы ДеМарко всю жизнь пришлось работать с такими тестировщиками!

Давно уже прошли времена, когда тестирование было каторгой, куда ссылались неугодные или нерадивые разработчики. Давно наступили времена мирного взаимовыгодного сосуществования. Но некоторые программисты, прочитав книжку умного дядьки начинают бояться злобных тестировщиков. А начитавшиеся менеджеры и того хуже — начинают (о, ужас!) культивировать и внедрять.

Чтобы как-то компенсировать этот негатив, я решил опубликовать несколько отрывков из статей Майкла Болтона, в которых пропагандируется в точности противоположный стиль взаимоотношений с коллегами по команде. Сегодня — первый отрывок.

Итак, хотите знать, как положительным образом влиять на программистов?

• Скажите программистам, что ваша главная цель – помочь им хорошо выглядеть, а затем начните в это верить. Ваша работа – не стыдить, не обвинять и не выступать в роли зла. Я не думаю, что мы имеем право даже в шутку говорить об этом, поскольку это не смешно.
• Вы всегда являетесь носителем плохих новостей. Отдавайте себе в этом отчет, и доставляйте плохие новости с сочувствием и сдержанностью.
• Вы тоже можете ошибаться. Относитесь скептически к своим собственным выводам.

Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил быстро научиться вкусно готовить. Нашел книгу «Гурман за 60 минут» Пьера Фрейни, и пошел читать.

Выяснилось, что мистер Фрейни описывал не технику, а свою философию приготовления еды.

Каждый рецепт начинался с такого захватывающего вступления, что меня больше увлекали истории мистера Фрейни и его знания о блюде, чем готовка. Прочитав всего лишь несколько страниц, я уже выучил массу новых вещей. А вскоре я даже начал распознавать некоторые шаблоны.

Эти истории научили меня намного большему, чем сами рецепты. Рецепты уделяли основное внимание технике, а истории учили навыкам и заставляли меня думать.

17-18 ноября Майкл Болтон проведёт в Санкт-Петербурге двухдневный тренинг «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software и ведёт замечательный блог о тестировании http://www.developsense.com/blog.shtml.

В 2003-2005 годах он совместно с Джеймсом Бахом разработал тренинг Rapid Software Testing, в основу которого легли основные концепции школы контекстно-ориентированного тестирования. С тех пор Майкл Болтон объездил с этим тренингом весь мир — Канада, США, Бразилия, Франция, Германия, Индия, Сингапур, Испания, Швеция, Турция. Первый раз в России этот тренинг Майкл Болтон прочитал весной этого года в Москве (дебриф). По многочисленным просьбам Майкл принял решение провести еще один тренинг в Санкт-Петербурге.

«Младших тестировщиков производительности» не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности. (с) Скотт Барбер (aka The Perf Guy)

В тестировании компьютерных программ есть «общедоступная» область функционального тестирования, куда доступ открыт всем желающим, и есть целый ряд областей с достаточно высоким «порогом входа», и тестирование производительности находится в их числе.
Для этого вида тестирования требуется хорошее владение оружием, его голыми руками не возьмёшь. Во-первых, нужно само оружие — тестирование производительности обязательно требует умения пользоваться специальными инструментами. Во-вторых, нужно тщательно изучить соперника — необходимо хорошее понимание протоколов взаимодействия тестируемой программы с внешним миром и её внутренней физической и логической архитектуры. Ну и конечно же нужно владеть приёмами — знать какую нагрузку и как подать на тестируемое приложение, и на что смотреть, чтобы выявить проблемы с производительностью.

18 февраля начнется новый онлайн-тренинг, продолжительностью 6 занятий «Тестирование производительности», автор и ведущий Алексей Баранцев.

11-12 марта Майкл Болтон проведёт в Москве двухдневный тренинг «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software и ведёт замечательный блог о тестировании http://www.developsense.com/blog.shtml.

В 2003-2005 годах он совместно с Джеймсом Бахом разработал тренинг Rapid Software Testing, в основу которого легли основные концепции школы контекстно-ориентированного тестирования. С тех пор Майкл Болтон объездил с этим тренингом весь мир — Канада, США, Бразилия, Франция, Германия, Индия, Сингапур, Испания, Швеция, Турция. И вот впервые этот тренинг проводится в России!

Продолжение перевода серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.

В переводе мы собрали все заметки серии в одну статью, состоящую из восьми частей (в данном посте представлены последние четыре части):

1. «Тестсорсинг»
2. Виртуализация
3. Информация
4. Перемещение тестирования к началу
5. Визуализация
6. Культура тестирования
7. Тестировщики в роли дизайнеров
8. Тестирование после релиза

Совместными усилиями участников Клуба тестировщиков мы сделали перевод серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.

В переводе мы собрали все заметки серии в одну статью, состоящую из восьми частей:

1. «Тестсорсинг»
2. Виртуализация
3. Информация
4. Перемещение тестирования к началу
5. Визуализация
6. Культура тестирования
7. Тестировщики в роли дизайнеров
8. Тестирование после релиза

Однако все восемь частей в один хабратопик не поместились, поэтому ищите под катом первые четыре, а чуть позже появится топик с оставшимися четырьмя частями.

Итак, перед вами – будущее тестирования.

Полгода назад мы запустили проект Панбагон — коллективный блог, предназначенный для коллекционирования багов и их обсуждения. Как я писал в опубликованном на хабре анонсе, у меня нет цели сделать ни публичный баг-трекер, ни доску позора. Мне хотелось создать некий инкубатор, где из мусора могли бы формироваться идеи, которые могли бы оказаться полезны для поиска багов, аналогичным описанным в Панбагоне. Поэтому я призывал не только описывать сам баг, но и излагать мысли, которые возникли у вас по этому поводу.

Однако мне периодически задают сакраментальный вопрос, вынесенный в заголовок — зачем изучать чужие ошибки? Поэтому я решил объяснить, почему я считаю это крайне полезным занятием для тестировщиков.

Однако начну несколько издалека — с рассказа про огненные сморчки.