Выступление Алексея Петрова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Все мы люди, и всем нам свойственно ошибаться, даже тестировщикам, которые эти самые ошибки в силу профессии и призваны искать. И тут, к сожалению, как в старинной поговорке про “в чужом глазе соринку видим, а в своем собственном бревна не замечаем”, мы, тестировщики, часто можем найти множество ошибок в работе наших коллег, а вот в собственной работе их не замечаем или попросту не хотим замечать.
Мой доклад посвящен как раз таким ошибкам в работе специалистов по тестированию, опыт показал, что их можно типизировать и обособить, сформулировав симптомы, причины возникновения и потенциальные угрозы, более того я расскажу, как эти “болезни” вылечить!
Например, вот лишь парочка классических болезней тестировщиков:
“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов. “Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем. “Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки. А таких болезней куда больше, о наиболее распространенных из них я вам и расскажу, выписав вдобавок рецепты для их лечения.
Работа вовсю кипит и мы решили рассказать, на каких принципах будет строиться новый учебный курс, чем он будет отличаться от наших предыдущих тренингов и от того, что предлагают другие учебные центры.
1. Selenium во главе угла
Достаточно часто можно встретить “тренинги по Selenium”, программа которых содержит всё, что пришло в голову автору тренинга -- основы программирования, XML, SQL, JUnit, Maven, Jenkins, Git, ну и немного про Selenium.
Это, конечно, выглядит привлекательно -- на одном тренинге выучить сразу всё. Но в итоге получается в точности наоборот -- ни одна из тем не покрывается достаточно полно.
В нашем новом тренинге главным будет Selenium.
Это не означает, что смежные темы совсем не будут рассматриваться. Целое занятие будет посвящено настройке инфраструктуры. Говоря о поиске элементов, нельзя обойти стороной XPath и CSS. При обсуждении способов запуска тестов попутно поговорим про Docker. Разговор о шаблоне проектирования PageObject и его альтернативах тесно связан с вопросом о том, как вообще строить архитектуру тестов.
Но про Selenium мы расскажем всё и с подробностями, а всё остальное -- по касательной, со ссылками для дальнейшего самостоятельного изучения.
2. Полнота материала
Ни на каком другом тренинге и ни в одной книге Вы не найдёте более полной информации о Selenium 3.0.
Если найдёте -- мы Вам дадим скидку 50% на этот учебный курс :)
3. Мультиязычность
Основные принципы и приёмы использования Selenium, рассматриваемые в тренинге, будут сопровождаться примерами на пяти языках, которые “официально” поддерживаются разработчиками Selenium: Java, C#, Python, Ruby, JavaScript.
Selenium это языковонезависимый стандарт, описывающий набор команд для управления браузером. Реализации этого стандарта для разных языков программирования похожи друг на друга, и это неудивительно -- они реализуют один и тот же набор команд.
Вместе с тем, особенности каждого языка, его стиль, накладывают отпечаток на реализацию Selenium для этого языка. Поэтому в тренинге будут специальные модули, посвящённые именно таким особенностям.
Даже если какой-то язык для вас “неродной” -- мы всё равно рекомендуем смотреть “чужие” модули. Может быть после этого вы решите сменить язык :)
4. Selenide, Protractor, PageObjects и другие модные темы
Отдельное занятие будет посвящено разнообразным надстройкам над Selenium.
Их много, они решают разные задачи, некоторые из них более популярны, другие не так известны, но ничуть не хуже.
Каждая надстройка добавляет что-то к функциональности Selenium, поэтому их удобно рассматривать не как самостоятельные инструменты, а именно в сравнении с Selenium -- чем именно каждая из них отличается от общего “базиса”.
Уже можно забронировать место на тренинге, тем более, что набор в первую группу ограничен. А при оплате до 30 сентября действует специальная льготная цена.
Для тех, кто проходил у нас следующие тренинги: Разработка тестов на языках Java/Python/C# с использованием Selenium, Все секреты и тайны Selenium действует 30% скидка (не суммируется с другими скидками). Для получения скидки при регистрации уточните на каком тренинге Вы были.
На прошлой неделе был опрос про использование инструментария для работы с тест-кейсами.
Более 150 человек приняли участие в опросе и сейчас мы подводим итоги.
Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.
Когда я только начинал работать в компании, разрабатывающей ПО, я столкнулся с крашем приложения. Попытавшись воспроизвести краш, повторив шаги, которые привели к нему в первый раз, я потерпел неудачу. Я сделал скриншот, сохранил лог ошибок и спросил коллег, известна ли им эта проблема. Они ответили, что это "невоспроизводимый баг", который всем им хорошо знаком – каждый хоть раз да сталкивался с ним. После обеда я трудился над этим багом несколько часов, и в конце концов вынужден был признать свое поражение – баг не воспроизводился. Команда прочитала мантру, часто используемую в таких ситуациях – "Не можем воспроизвести – не можем исправить". Без стабильных шагов воспроизведения мое сообщение о баге было гласом вопиющего в пустыне.
Когда выяснилось, что этот плавающий невоспроизводимый баг вызывает проблемы у наших пользователей, команда решила разобраться в нем. Когда я поймал его повторно, я объединился с программистом и наблюдал за тем, как он пытается разъяснить проблему. Первое, что я заметил – его совершенно не интересовали шаги, которые привели к падению. Он рассматривал приложение в целом, представляя себе систему и взаимодействия внутри нее. Я попросил его рассказать, о чем он думает, показать, какая информация из трейсов привлекла его внимание, и что именно он сделал с кодом, чтобы собрать больше информации о баге, когда он появится вновь.
В итоге мы наконец смогли найти стабильные шаги воспроизведения, но не посредством интерфейса. На уровне интерфейса баг воспроизводился не всегда, и на убеждение команды в том, что мы локализовали проблему, ушло некоторое время. Мы потратили его на поиск доказательств, мы слушали свою интуицию и проверяли различные теории. Когда мы почувствовали, что абсолютно уверены – мы презентовали нашу находку коллегам. Нам разрешили исправить баг, и позднее мы были очень рады узнать, что пользователи больше не сталкиваются с этой спорадической проблемой, которая мешает им жить.
Так называемые "невоспроизводимые" баги всегда тревожили меня – особенно выражавшиеся в падениях, повреждении данных, и утечках памяти. Проблема, "плавающая" на тест-стенде, зачастую отлично воспроизводится у пользователя.
Когда я только начинал свою карьеру в тестировании, я копался в невоспроизводимых багах в свободное от релизов время. Благодаря удаче и упрямству я выяснил, что зачастую они вполне воспроизводимы. С тех пор я оттачиваю свое мастерство, пытаясь найти шаги воспроизведения для "невоспроизводимых" серьезных багов.
DevOps - это не только модное слово, которое сейчас на слуху. DevOps - это подход к работе, помогающий активно взаимодействовать командам программистов, тестировщиков и админов, которые чаще всего изолированы друг от друга.
Какие проблемы решает DevOps? Чем это отличается от привычных ролей в сфере IT?
Давайте послушаем тех участников конференции SQA Days 19, кто уже на практике применил данную методологию и может поделиться результатами. Ниже вы сможете найти видео их выступлений.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Наверное, вы часто слышали разговоры о некоем особом "образе мыслей" тестировщика.
Скажите, вы никогда не задавались вопросом, что люди понимают под этим выражением? Я вот задаюсь им каждый раз, и каждый раз слегка напрягаюсь и думаю, правильно ли я понял собеседника.
Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”
В опросе приняли участие 170 человек.
Ниже представлена диаграмма частоты использования инструментов по результатам этого опроса. На диаграмме представлены только те инструменты, который получили больше одного голоса (все инструменты в порядке убывания голосов представлены в конце статьи).
Чаще всего респонденты нашего опроса используют Jira, на втором месте по популярности - Redmine, а на третьем - MS TFS.
Теперь посмотрим на основные причины выбора той или иной системы.
Этот вопрос очень часто звучал в учебном чате первого потока тренинга Натальи Руколь Комплексная система подготовки тестировщиков по программе ISTQB FL. И хотя с каждым днём всё больше выпускников рассказывают об успешной сдаче экзамена, вопрос не утратил актуальности. Ведь все знают, что в заданиях экзамена ISTQB FL встречаются и опечатки, и пропущенные запятые, а иногда и два одинаковых ответа!
Главная дискуссия разгорелась по поводу вопроса о граничных значениях для заданного диапазона. Рассмотрим вопрос с таким же подвохом схематично, на примере обычного слова:
“Какие буквы входят в слово Каша?”
К Ш А
ш К
А а К к Ш ш
а ш а к р
Вся группа была уверена, что это просто ошибочный вопрос!
Но нет, в этом задании нет ошибок, а вот ловушек очень много! Важно внимательно прочитать каждое слово в нем!
Если вопрос будет звучать так: “Где указаны все буквы, которые есть в слове Каша?” - правильным ответом будет вариант 3.
Если так: “Не учитывая регистр, где буквы идут в том порядке, как и в слове Каша?” - правильным ответом будет 1.
А если его сформулировать так, как написано выше: “Какие буквы входят в слово Каша?” - то правильный ответ, конечно, 2.
Именно благодаря тому, что мы очень подробно разбираем вопросы на занятиях (а домашние задания на все вебинары - это пачки тестов на изученную тему), после сдачи экзамена ISTQB FL участники пишут нам подобные сообщения:
“Большинство вопросов с подковыркой, но спасибо Наташе и Юлии за то, что дали правильный вектор! Так как я сразу все подковырки распознавала и вспоминала: "А, а нам говорили, что будет такой вопрос)))". В общем, я его победила, чему рада)))“
Вот так поделилась с нами своим успехом выпускница тренинга Надежда.
За прошедший с окончания курса месяц 23 наших выпускника уже сдали экзамен ISTQB FL и получили сертификаты. Поздравляем с новой ступенькой на трудовом пути! Молодцы, ребята, так держать!
Поэтому, если вы планируете получить сертификат “ISTQB FL”, но никак не решаетесь записаться на сдачу экзамена, мы предлагаем вам прямо сейчас принять участие в тренинге Натальи Руколь Комплексная система подготовки тестировщиков по программе ISTQB FL. За время обучения мы разберем все тонкости, потренируемся отвечать на самые заковыристые вопросы и дружно будем делиться успехами! Неважно, на каком языке вы планируете сдавать экзамен, на русском или на английском, курс обеспечит подготовку к обоим вариантам.
Всем выпускникам данного тренинга предоставляется скидка 10 евро при оплате экзамена ISTQB FL!
Если у вас остались вопросы по этому тренингу - почитайте наше ЧАВО.
Из моего рассказа на подкасте Testing In the Pub многие знают, как меня ценят на моей работе. Меня всегда приглашают на kick off-встречи, на которых мы говорим о том, что мы создаем и почему, и команды просят меня составить ментальные карты для тестирования.
Однако так я работала не всегда. Всегда важно понимать, что изменения могут зависеть лично от вас. На моем нынешнем месте работы изменения произошли еще до того, как я сюда пришла, поэтому дам несколько советов, основываясь на своем опыте на предыдущей работе, где я была первым и единственным тестировщиком.
Раньше я работала в компании, которая выпускала вполне успешный продукт, уже вышедший на окупаемость, но отдела тестирования у них не было. Когда я спросила, а как же они тестируют, они ответили, что у них нет тестировщиков – продакт-оунеры и заинтересованные лица тестируют самостоятельно, плюс имеется большой набор фронт-энд автотестов.
Они все-таки решили нанять меня, а потом – целую команду тестировщиков. О том, как это произошло и чему я научилась, я и хочу рассказать.
Выступление Александра Хози на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Не все начинающие тестировщики попадают в компанию с большим количеством классных тестировщиков-менторов. Поэтому некоторым из нас волею судеб пришлось начинать свой рост в тестировании с «обезьянок». И не всегда получается перерости этот этап, изжить «обезьянку», которая поселилась внутри вас.
В своем докладе я расскажу вам о том, как и почему появляются такие «обезьянки» и что можно с этим сделать.
Вот некоторые из них:
отсутствующий (или некомпетентный) наставник;
слаборазвитые процессы разработки и тестирования внутри компании;
вытекающее из слабости процессов: «Ну потестируй что-нибудь, ты же QA»;
отсутствие «вопросительности»
непонимание цели тестирования;
тестирование используется как вход в IT;
в профессию пришли за деньгами;
карма/другое :)
Также расскажу личную историю тестировщика-обезьянки: как я боролся с обезьянкой внутри меня :) как боролся с публичным мнением: «Тестировщик мобильных приложений – обезьянка». Кстати, иногда даже стоит давать обезьянке волю. Мы разберемся с ситуациями, когда это приносит пользу, и что я использую для этого.
Месяц назад мы анонсировали начало работы над новым тренингом по инструменту Selenium 3.0: 
Автор: Ким Нап (Kim Knup)