Мы рады сообщить, что 25-26 сентября запланировали проведение одного из лучших наших тренингов на тему тестирования – Exploratory Testing. В современном мире разработки цикл поставки продукта становятся все меньше и времени на полное ручное регрессионное тестирования по тестовым сценариям попросту не хватает. Exploratory Testing позволяет более прагматично подойти к процессу тестирования и тратить время тестировщиков с гораздо большей пользой.
Тренинг проводит Андрей Дзыня, который имеет большой опыт в тестировании не только в отечественных компаниях, но и в зарубежных. На данный момент Андрей работает в известной компании Spotify, поэтому тренинг покрывает особенности как продуктовых так и аутсорсинговых компаний. В программе тренинга много практики, поэтому участники смогут отлично усвоить теоретический материал под чутким руководством опытного тренера (Андрей обучает тестировщиков вот уже почти 5 лет).
Регистрация на тренинг уже открыта. Стоимость с обедом составляет 6000 гривен. Поспешите занять себе место, тренинг проводится достаточно редко и в этом году такой возможности больше не представится!
Мы давненько не проводили никаких публичных мероприятий для тестировщиков. А тут появилась возможность поставить тренинг “Exploratory Testing” и мы решили, что ее нельзя упускать. Ведь наш основной тренер по направлению тестирования Андрей Дзыня переехал работать в Швецию и теперь трудится в известной компании Spotify. Благодаря этому факту, у участников есть возможность узнать, как тестирование устроено в большой продуктовой компании, какая роль отводится исследовательскому тестированию, как взаимодействуют тестировщики с разработчиками.
Андрей обновил программу тренинга, сделав ее еще полезнее и интереснее. На мой взгляд, исследовательское тестирование должно быть чуть ли не основной работой тестировщика в правильной команде. Но, к сожалению, многие даже не представляют что это такое. Данный тренинг поможет систематизировать знания, попробовать на практике различные техники и подходы, а также получить ответы на практические вопросы. Тренинг пройдет 3-4 октября, регистрация уже открыта и в группе осталось только 6 мест. Торопитесь занять место!
Меня давно волнует один и тот же вопрос: почему для многих слово тестировщик ассоциируется с временной профессией или той, где можно просто хорошо заработать и при этом знать минимум?
Изначально я был уверен, что это зависит не от самого человека, а от окружения, в котором он работает. Но спустя время я понял еще одну причину. Проблема не в том, что процесс поставлен не должным образом, а в том, что профессия тестировщика недооценивается. У многих людей бытует мнение, что тестирование – это обезьяний труд и научить быть тестировщиком можно каждого. Лично я с этим не согласен. Ведь аналогично можно сказать о программировании, бизнес анализе, менеджменте и любой другой профессии. Все зависит от того, насколько качественно этот труд будет выполняться.
Требования к хорошему тестировщику достаточно высоки. Он должен быть осознанным в технологиях как программист, уметь структурировать документацию как бизнес аналитик и еще при всем этом быть экспертом в тестировании ПО. Если вы еще считаете, что это очень легко, то посмотрите весь цикл видео материалов от Cem Kaner. Я сейчас не говорю об автоматизации или тест менеджменте, я говорю о тестировании как о непрерывном исследовании продукта для поиска несоответствий, потенциальных улучшений и уязвимостей.
Умные менеджеры решили защитить свои проекты от так называемых “monkey-тестировщиков”, изменив название позиции на гордое «Инженер по обеспечению качества» (QA Engineer). Нельзя сказать, что намерения были плохими. Наверное, это было сделано с целью хоть каким-то образом мотивировать тестировщиков на развитие и поднятие их авторитета в глазах программистов. Правда, одно понимание было упущено. Обеспечение качества – это не работа отдельно взятых людей, это обязанности всей команды, к тому же не только разработчиков и тестировщиков.
Чтобы быть хорошим тестировщиком нужно отвечать за свои решения. Помните, мы в ответе за то, что протестировали! И нужно принимать это. Хватит скрываться за тест планами и тест кейсами, оправдываясь, что такого сценария не было в твоем списке. Если ты специалист, то проведи анализ, выбери подходящую технику, выполни тестовую сессию, расскажи о результатах и проблемах, которые волнуют или остались не протестированы. Сделай так, чтобы другие видели результат твоей работы. Сделай так, чтобы ты был ценным игроком в команде. Экспериментируй с минимально-необходимой документацией для того, чтобы спланировать тестирование и предоставить отчетность. Прочти, осознай и примени Heuristic Test Strategy Model, Exploratory Testing и Session Based Test Management. Вдумайся в основные пункты Agile манифеста, прочти еще раз постулаты Context Driven School, повтори Craftsmanship манифест.
Работа тестировщика требует активной позиции. Чтобы быть профессионалом, нужно постоянно находиться в движении, непрерывно развиваться и всегда уметь задавать неудобные вопросы. Лишь свободный человек может обладать всеми этими качествами. Когда у вас есть эта свобода, вы сможете максимально спроецировать свои навыки и умения на решение поставленной проблемы в нужном направлении, чтобы принести максимальную пользу проекту! Речь идет не о менеджерах или тим лидах, а о тестировщиках. О тех специалистах, которые: анализируют, тестируют, находят проблемы, генерируют идеи, обучаются продукту и умеют фокусироваться над решаемой задачей отведенный для этого промежуток времени.
Гордитесь и любите свою профессию – будьте настоящим тестировщиком!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
После перерыва в несколько месяцев мы возобновляем проведение тренинга “Exploratory Testing”. Ближайший пройдет в Киеве 15-16 февраля. Тренинг теперь проходит в новом двухдневном формате, что дает участникам возможность больше времени уделить практическим заданиям и опробовать полученные знания на практике. Тренинг проводит опытный тренер и тестировщик Андрей Дзыня.
Цели предстоящего тренинга:
Вы можете ознакомиться с детальной программой тренинга и зарегистрироваться. Стоимость участия 2000 гривен (обед включен). Группа ограничена 15 участниками.
Эта статья – вольный пересказ статей Майкла Болтона на тему, что не является исследовательским тестированием.
Зачастую, люди, которые ленятся разобраться с принципами, которые заложены в подход исследовательского тестирования, попадают под разного рода сомнения. В этой статье мы детально разберемся в самых частых заблуждениях относительно исследовательского тестирования.
Что не так с этой трактовкой? Давайте представим как происходит процесс тестирования по так называемому “туру”. Любимый пример Джеймса Виттакера (автора книги Exploratory Software Testing):
Вы турист, летите на самолете в Лондон, чтобы отправиться за покупками. Вы читаете карту и отмечаете места, в которых хотели бы побывать, при этом рассчитываете маршрут и время, чтобы успеть в каждый магазин. По прилету в Лондон вы начинаете следовать намеченному плану. Вы заходите в каждый магазин, следуя своему маршруту. Выбираете вещи, некоторые покупаете, некоторые нет. Также находите бракованные вещи и показываете их менеджерам магазина. И так далее пока не дойдете до последнего магазина, или пока у вас не закончатся деньги.
Давайте спроецируем это пример на тестирование. Что получается? У нас есть набор чекпоинтов, быть может чеклист end-2-end набор тестов, который указывает нам на порядок выполнения действий. Не нужно долго думать, чтобы ответить на вопрос “На что похоже такое тестирование?”. Конечно же – это скриптовый подход к тестированию.
Каким должен выглядеть процесс, чтобы он был похож на исследование? В первую очередь нам нужна цель. Говоря о Лондоне, целью может быть – купить красивое пальто или зонт. А где, в каком магазине и в какое время – не важно! Главное – результат. Что использовать для этого – дело сугубо индивидуальное. Кто-то может составить план, кто-то может доехать до центральной улицы и спрашивать у прохожих дорогу к ближайшему магазину одежды, а кто – банально зайти в первый попавшийся магазин и купить первое попавшееся на глаза. У каждого тестировщика свой стиль тестирования. И это правильно! Главное – это достижение цели, конечного результата. В этом разрезе, тестировщик более похож не на туриста, а на исследователя, который ищет пути решения поставленной проблемы.
Бред, вранье и полная чушь! Одно из самых частых заблуждений относительно исследовательского тестирования. Чаще все встречается у неграмотных Agile тестировщиков. Как вы можете заниматься исследованием лишь один раз в неделю? А чем же вы тогда занимались остальное время – тестировали? Нет, тогда вы не тестировали – вы проверяли на соответствие (checking). Исследовательское тестирование – всеохватывающий процесс, это подход к тестированию, а не одна из доступных техник. В пример этого заблуждения можно принести всем известные Agile квадраты.
Очень глупо было размещать Exploratory Testing в квадрате Q3. Почему? Давайте подумаем, можем ли мы делать исследования на этапе написания unit-тестов? Можем. Разработчики тоже могут исследовать код приложения, чтобы написать больше тестов. Проведение code review тоже можно отнести к исследованиям. Тоже самое касается остальных типов тестов. Например, вы можете записать в режиме исследования скрипт для нагрузочного тестирования, используя BadBoy. И запускать его при помощи JMeter с разными типами нагрузок. Кому интересно детальное опровержение этой матрицы – посмотрите выступление Элизабет Хендриксон на последней конференции CAST.
Если вы когда-то услышите эту фразу – смело ругайте этого человека. Какие инструменты можно применять для проведения исследовательского тестирования? Да любые! Это и скриншоттеры, и рекордеры, и логгеры. Используя автоматизированные скрипты можно подставлять разные массивы данных и тем самым заниматься исследованием системы автоматически, конфигурируя текстовые или xml-файлы. Тот же Selenium IDE и прочие record-and-play инструменты могут облегчить работу тестировщику во время проведения тестовой сессии.
Еще одно из часто упоминаемых заблуждений. Быстрые проверки или, как их еще принято называть, quick tests могут проводиться как в исследовательском, так и скриптовом режимах. Для примера скриптового подхода, вы можете описать набор smoke или sanity тест кейсов для вашего приложения и тестировать по ним. В исследовательском тестировании же можно использовать мнемоники и туры для проведения быстрого тестирования. Но обратите внимание, что не все туры бывают быстрыми, и не все быстрые проверки – это туры. Полный список – на сайте Майкла Болтона.
Напоследок – самое сладкое заблуждение, которое полно необоснованных убеждений. Все тестировщики, по долгу службы, привыкли к стандартному течению обстоятельств. Читаем требования, пишем тест кейсы, ждем пока разработчики что-то напишут и уже по этим тест кейсам приступаем к тестированию. Я не говорю, что тестирование по тест-кейсам это плохо. Напротив, в некоторых контекстах без них никуда: медицинское, авиа, банковское ПО. Но везде должен быть разумный предел того, что документировать, а что – нет. Самый ценный совет, который можно здесь дать – “Документируйте только то, что нужно”. Узнайте у членов вашей команды, менеджеров – какие документы им нужны, чтобы контролировать выполнение ваших обязанностей без постороннего вмешательства? Подумайте сами, какие документы вам необходимы для проведения тестирования. Но всегда держите в голове – “Keep it simple”. Кстати, то же самое имелось ввиду в Agile манифесте “Working software over comprehensive documentation”. Тестировщику нужно заниматься тестированием, а не администрированием процесса, точно так же как программисту – написанием кода, а не спецификаций. Но везде должен быть баланс. Если для поддержания рабочего процесса необходим документ – лучше его написать. В исследовательском подходе к тестированию документировать можно что угодно и сколько угодно. Главное договориться о том, что должно попасть в отчет тестовой сессии и какие сценарий следует формализовать.
Будьте готовы принять вызов и отстоять точку зрения о правильном исследовательском тестировании. Приводите примеры из своих контекстов. Задавайте вопросы и критикуйте, ведь этих пяти примеров может быть недостаточно, чтобы полностью ответить на вопрос “Что не есть Exploratory Testing?”
Хотите научится применять этот подход на практике? 26-27 октября в Киеве будет проходить тренинг “Exploratory Testing”. На множестве практических заданий под руководством опытного тренера вы освоите исследовательское тестирование и сможете применять его в своей работе.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Прошло уже 5 тренингов по Exploratory Testing, практически во всех IT городах Украины. Мы получили много полезных отзывов от наших участников:
Андрей, огромное спасибо за тренинг!
Для меня он был очень актуален. Много нужной и полезной информации.
Отдельное спасибо за практику. Это наилучший способ чётко и доступно дать человеку понять и прочувствовать нюансы и быстро превратить полученную информацию в навык.
Это было великолепно =) Спасибо
Отличный тренинг! ОЧЕНЬ много полезной информации. Возможно, даже многовато для 8 часов
Тренеру стоит подумать о двухдневном тренинге или о Q&A сессии/вебинаре после тренинга.
Второй день, наверное, даже лучше подойдет – осмыслить полученные знания в первый день, аккумулировать полученные знания во второй день и дать жару к завершению тренинга
Тренінг вартує втрачених часу та коштів. Однозначно) Андрій добрий лектор та вчитель, який вміє тримати увагу аудиторії . Великим плюсом є те, що після початкового опитуванні рівня володіння питанням інформація подавалася згідно того рівня – що дуже допомогло поставити свої крапочки над «і». Навіть не соромно було задавати дурні питання)) Приєднуюся до побажання розділити тренінг на 2 дні – оскільки після обіду справді важко зберігати темп. Велика увага була приділена практичним заняттям – що дуже радує, оскільки при бажанні літературу знайти завжди можна. Також окреме дякую за післятренінгові матеріали, які допомагають освіжити набуті знання та зберігати наведений Андрієм порядок в мізках
Оцінка: вел дан!
Самым распространенным пожеланием была просьба расширить тренинг и проводить второй день, так как материала для этого достаточно и участникам хотелось еще больше попрактиковаться и послушать интересные кейсы из живых проектов.
Мы не заставили ждать долго и решили расширить программу тренинга на 2 дня.
Что это даст? Какие плюсы получат участники нового формата?
Мы запланировали провести тренинг в новом формате в Киеве 26-27 октября. Рекомендуем не пропустить и зарегистрироваться, так как размер группы остается прежним – 15 человек.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Вторая статья из цикла «Один день в жизни тестировщика». В предыдущей статье мы говорили о планировании. В этом примере мы рассмотрим, чем занимается тестировщик в самый разгар итерации.
Контекст:
Первый день второй недели. После утреннего митинга, обсуждения прошедших активностей и планов на текущий день все усаживаются на рабочие места. Тестировщики проводят между собой Debrief, чтобы определить, кто какую задачу берет на себя.
После согласования, оба приступают к тестированию своих User Story.
Первый тестировщик приступил к работе, используя Acceptance Test как отправную точку для проведения тестирования. Он использовал этот сценарий как некий маршрут для прохождения по новым частям системы, но при этом не забывал смотреть «по сторонам». В один момент он столкнулся с непредвиденным поведением системы, что ввело его в ступор.
Все 5 попыток повторить действия не увенчались успехом. Напористость тестировщика не позволила ему оставить эту проблему и он позвал второго тестировщика, с просьбой помочь разобраться в проблеме. Спустя минуту, коллега подвинул стул и внимательно выслушал ситуацию. Ребята решили сделать небольшой анализ проблемы и составить некий план, по которому нужно будет найти пути воспроизведения ошибки
Первый тестировщик принялся за тестирование. В это же время второй следил за действиями первого, пытаясь найти новые идеи. Первый тестировщик открыл файл настроек, где изменил параметры пересчета цены. Затем открыл UI часть системы, залогинился, добавил новый товар в систему, зашел под аккаунтом обычного пользователя и совершил две покупки. Проверка оказалась успешной – проблема не была найдена.
«А что если теперь изменить настройки module2 с указанием аналогичных значений и проверить операцию суммирования еще раз с новым созданным товаром?» – предложил второй тестировщик.
Решили осуществить проверку, но опять-таки получили успешный результат. Проверка платежной системы заняла 10 минут, но им все таки удалось найти ошибку и stacktrace в файле логов, где должны собираться все совершенные платежи. Первый тестировщик просто не посмотрел в этот файл, когда тестировал в одиночку, соответственно не смог выявить, на каком шаге возникла ошибка.
С этим сообщением оба тестировщика обратились к программисту, который отвечал за реализацию этой задачи. Программист откликнулся и попросил дать ему stacktrace, чтобы понять причину ошибки. Спустя несколько минут, покопавшись в коде, программист сказал, что в логике не учтена ситуация совершения платежа пользователем с негативным балансом на счету. Также он отметил, что должна быть добавлена валидация на эту ошибка и написан интеграционный тест, который сможет верифицировать эту логику.
Тестировщики спросили: “Сколько времени займет, чтобы исправить это?”
«По оптимистическим оценкам – 30-50 минут» – ответил программист.
Недолго думая, единогласно приняли решение, что нужно завести баг и добавить это задачей в колонку TODO этого спринта и связать с тестируемой задачей.
В чем мораль этой истории?
Работая в паре, можно выявить ошибку значительно быстрее, чем пытаться разобраться самому. Узнав у разработчика дополнительные детали, можно описать дефект таким образом, чтобы больше не возникало уточняющих вопросов.
Какие ошибки допустил первый тестировщик в своей работе?
Он тестировал невнимательно, случайным способом, соответственно не смог сказать, в чем именно заключалась найденная проблема.
Как он смог быть решить эту проблему самостоятельно за 5 минут?
Использовать заметки в момент выполнения тестовой сессии в виде чеклистов, интеллект-карт или инструментов для записи экрана. Это поможет пересмотреть результаты и понять, какие шаги спровоцировали проблему.
Дайте свое виденье разрешения проблемы. Как в будущем избежать потерю времени?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
