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

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

На форуме тестировщиков и в блогах часто появляются вопросы: с чего начинать тестировщику, который только-только выбрал свою стезю?

С одной стороны, сейчас много курсов в этой области, которые проводятся на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы. Если вы ещё не знаете, в каком направлении развиваться, какие области интересны, какие знания хочется получать – то о каких курсах идёт речь? А комплексного ВУЗовского образования для тестировщиков в СНГ пока что нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти направление для развития и понять, «что и как надо изучать для быстрого старта?».

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

Итак, 7 шагов от чайника к тестировщику.

В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (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 минут» Пьера Фрейни, и пошел читать.

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

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

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