пятница, 29 июня 2012 г.

Тренинг Exploratory Testing в Киеве


Exploratory Testing is not a technique. It's a way of thinking about testing!
Каждый участник моего нового тренинга, который прошел 16 июня в Киеве, понял смысл этой фразы по-настоящему. Я переживал, что столько материала не уместить в однодневный тренинг, но все удалось!


Группа собралась довольно таки интересная, были тестировщики, автоматизаторы и тест менеджеры. Мы начали говорить о проблемах в разных процессах разработки, дискутировали на тему Waterfall и Agile, смоделировали итерацию проекта в разрезе тестирования, определили требуемые тестовые артефакты. Все это помогло нам выявить очевидные проблемы тестирования. Но перед тем как приступить к практике, мы разобрались, что на самом деле есть Exploratory Testing, а что есть не более как неправильной трактовкой этого термина. Даже книга Джеймса Виттакера, не осталась без внимания, которая так же не соответствует на 100% концепции ET.

Очень много времени было уделено тестовым сессиям. Участники смогли отработать навыки, как в исследовательском, так и парном тестировании. В формате Testing Dojo мы тестировали приложения с разными условиями. В одиночку, в парах, молча, в стиле ping-pong. В конце каждой сессии проводили разбор полетов - Debrief, чтобы обсудить насущные проблемы и найти им решение.

Поговорили о таких методах как: туры, эвристики, soap opera, функциональная карта, end-2-end.

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

Практика создания отчетов плавно подвела нас к Session и Threads Based Test Management. Мы рассмотрели, как основатели этих подходов справляются с управлением процесса тестирования. В итоге мы собрали этот пазл на примере Agile проекта.

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

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




Отчет о тренинге одного из участников http://www.akhozya.com/2012/06/exploratory-testing.html

Отзывы участников:
Впечатления положительные. Незамутненный долгой работой в QA мозг получил много вкусной пищи и узнал о большом количестве направлений в которых стоит развиваться. Динамично проведенное мероприятие в ходе которого невозможно было заскучать. Усталость после ночной дороги сказывалась, но стиль проведения и интересная тема не давали отвлечься на эту мелочь. Впечатления позитивные, буду следить за новостями о будущих тренингах.
Отличный тренинг! ОЧЕНЬ много полезной информации. Возможно, даже многовато для 8 часов. Тренеру стоит подумать о двухдневном тренинге или о Q&A сессии/вебинаре после тренинга. Второй день, наверное, даже лучше подойдет – осмыслить полученные знания в первый день, аккумулировать полученные знания во второй день и дать жару к завершению тренинга. 
Эксплоратори тестинг подход я открыла для себя где-то около двух лет назад и примерно год в команде использую SBTM. Но, тем не менее, оставалось ощущение, что упущено что-то важное. Знания о самом подходе как бы оставались не упорядоченными.Касательно материалов тренинга возможно для меня не было чего-то кардинально нового, но стиль подачи этой информации бесподобен. Потому как чувствуется проделанная огромная подготовительная работа и полное понимание Андреем той темы, о которой он говорит. Моими главными ожиданиями от тренинга было по возможности упорядочить свои знания о эксплоратори подходе и углубить свое понимание этого подхода. Ожидания оправдались на все 100%! В результате домой поехала с кучей новых идей и огромным желанием их воплощать в жизнь, чтобы улучшать продукты, над которыми работает моя команда и делать сами процессы разработки более интересными и эффективными. Андрей, успехов Вам! 
Спасибо за тренинг. Когда читала анонс, подумала: «Вот оно! Это же наша ситуация!»  В ходе тренинга получила много полезной информации, советов из личного опыта. Очень понравились практические задания. Андрей показал несколько хороших практик и инструментов. В целом, получен БОЛЬШОЙ багаж новых знаний и навыков. Еще раз спасибо
Андрей, огромное спасибо за тренинг! Для меня он был очень актуален. Много нужной и полезной информации. Отдельное спасибо за практику. Это наилучший способ чётко и доступно дать человеку понять и прочувствовать нюансы и быстро превратить полученную информацию в навык. Это было великолепно =) Спасибо

P.S. Следите за анонсами тренинга в вашем городе

вторник, 19 июня 2012 г.

Достигайте ваших целей


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

Известно ведь, что мозг человека делится на два полушария. Левое, более рациональное, над которым преобладает расчетливый и пошаговый властелин. Не стоит путать с бюрократом, об этом типаже мы как-то поговорим.
Вторая же половина отвечает за наше творчество. Это наши эмоции, спонтанные решения, хотелки, да и в целом все действия, которые не поддаются логике, т.е. левому полушарию.
Так вот, зная эту истину, нужно как-то жить в балансе, чтобы удовлетворять потребностям обоих частей.


Рассмотрим на примере целеполагания. Представьте, что вы очень чего-то хотите: достичь определенного статуса, изменить мир, получить нужные вам результаты. Это цель, желание, которые в большинстве случаев не поддаются логике. Теперь, когда правое полушарие закончило свою работу, вам нужно каким-то образом воплотить это в жизнь. Лежа на печи не получишь калачи. Поэтому, чтобы достичь ваших целей, нужно активизировать логический участок вашего мозга.

Каким образом? Я не хочу показаться капитаном, говорящим очевидные вещи, но самый главный совет - дробите на части. Существует несколько известных мне подходов: "ешьте слона частями" и GTD (what is the next action). Я более двух лет живу и работаю по методологии Дэвида Аллена, потому цель дроблю на под-цели (если возможно, даже на проекты, которые в свою очередь состоят из конкретных задач, таких как поехать, написать, позвонить, поговорить, погуглить и т.д.). Имея список конкретных действий, уже намного проще поделить участок работ, запланировать их на определенные дни или на месяц вперед. Что-то можно делегировать друзьям, семье, подчиненным. Но для близких лучше использовать слово "попросить". Это не меняет сути, но звучит не так обидно.

Очень важно на этапе выполнения задач не сбиться с дороги к своей цели. Иногда, конечно, жизненные приоритеты могут измениться. В этом случае решать вам, стоит ли дальше добивать поставленные цели или бросить их на пол пути. Единственным советом, которым могу поделиться в этой ситуации - проводите осмотры (ежедневно, ежемесячно и т.д.). Каждый из осмотров должен проводиться на разных уровнях сознания, зонах ответственности. Это поможет отвлечься от ежедневной рутины и помечтать, подумать о жизни, абстрагироваться, дать волю вашему творческому "Я".
Заметьте, как мы должны идти к цели. Итеративно, шаг за шагом, достигая все новых побед. При этом не забывать оглядываться  назад, чтобы оставаться в седле.

Достигайте ваших целей, развивайтесь и не забывайте использовать всю силу вашего "Я".

С уважением,
Андрей Дзыня

четверг, 14 июня 2012 г.

Тестировщики Vs Программисты: Конфликт или взаимодействие?



По приглашению организаторов online конференции -  IT Brunch, подготовил интересный доклад на вечную тему конфликта между тестировщиками и программистами. Так как тема конференции была "Учимся на чужих ошибках", я отобрал 7 самых интересных ошибок, которые допустил в командной разработке ПО.

Ниже можно посмотреть слайды и послушать сам доклад.
 

Ответы на вопросы: 
Как бороться с проблемой когда "ты QA - тебе и надо". PM так же относится. Такие проблемы обычно и заваливали проект. PS я QA :)
Нужно начинать с малого. Напишите один тест, установите Continuous Integration сервер, запускайте UI тесты на нем. Покажите команде, что от этого есть толк. Поговорить с программистами и попросите их подключить несколько unit-тестов, автоматизировать сборку продукта. Основная цель - добиться рабочего Continuous Integration процесса!
Кто занимается созданием подобных полиси и кто принимает решения о их принятии?
Не старайтесь загонять людей в рамки полиси. На уровне компании хорошо. Но на самом низком уровне работы, дайте людям самим организовать свой процесс. Он не может быть под копирку. Люди - не роботы.
Я правильно поняла, что: нельзя оплачивать овертаймы - это расслабляет и демотивирует команду
Я бы не сказал, что нельзя. Лучше не допускать ситуацию на проекте к тому, чтобы были овертаймы!
Можно конкретный пример по поводу какого таска тестировщик мог знать что это 8 стори поинтов а не 3 - на моей практике не приходилось встречать ситуацию где тестировщик настолько может "шарить" в объёме тасков по имплементации
Я попытался обширно ответить на этот вопрос в записи. Если у вас еще остались уточняющие вопросы, свяжитесь со мной!
Автоматизация тестирования: для таких задач скорее должны быть тестировщики, специализирующиеся на автоматизации - программисту обычно этим неохота заниматься и давать ему такие таски не оптимально. У вас другой опыт?
Я с этого начинал. Скажу по правде, изначально не видишь проблем. Есть тесты, ты их автоматизируешь. Но спустя время понимаешь, что занимаешься только тем, что исправляешь эти тесты. И времени на тестирование и написание новые катастрофически не хватает. Более рационально поручить автоматизацию на всю команду и научить тестировщиков и программистов взаимодействовать друг с другом для достижения максимального тестового покрытия.
После разъассайнивания обязанностей руководством высшего звена,в отдел тестирования назначили-QA Team Lead Deputy, до этого был назначен Team Lead Deputy программистов,которому новый QA не нравится. Размер палок в колеса растет.Как исправить ситуацию? Спасибо
На мой взгляд в команде не должно быть должности QA Team Lead, тогда тестировщики и  начинают конфликтовать с разработчиками. Пытайтесь избегать Quality Police Mentality. Сделайте одну команду разработки, в которой будут несколько тестировщиков, не делайте тестировщиков отдельной командой. В команде могут быть крутые и некрутые тестировщики и в зависимости от скилов они выполняют разные задачи. Так же практикуйте парное и exploratory тестирование, чтобы делиться опытом.
У нас программисты УПОРНО не хотят запускать код который пишут.Упорно не хотят писать юниттесты. Причина - Вы тестировщики, вам за тестирование платят. Как изменить ситуацию? что посоветуете?
Оговорите с программистами критерии приемки задач на тестирование. Опишите это в Definition of Done. Но перед этим конечно же нужно, чтобы они поняли зачем все это. Для этого нужно посчитать сколько времени уходит у тестировщика на то, чтобы проверить задачу и вернуть ее обратно программисту на доработку. В итоге получится, что дешевле программисту перепроверить позитивный сценарий, что задача работает, нежели потом 10 раз вносить изменения.
Если разработчики будут заниматься ручным тестированием фич друг друга это может увеличить стоимость разработки и замедлить саму разработку
 Верно подметили, я переслушал запись и словил себя на том, что не до конца донес мысль. Просить программистов тестировать нужно только тогда, когда с тестированием завал и тестировщики не успевают протестировать задачи. Очень хороший индикатор завала это "Limiting Work in Poregress" в теории Lean Development.
Бывают ли у Вас ситуации что один и тотже баг появляется через билд? Что посоветуете чтобы защититься от таких проблем?
Бывают и очень часто. Напишите тест, который будет находить этот баг и запускайте на ряду с остальными тестами.
Автоматизация и программисты + аджайл = не согласен! 
Ваше право. Но помните, unit тесты тоже автоматизация, точно так же как и UI тесты.
Что делать, если программисты даже пишут тесты, но совершенно игнорируют результаты прогонов? Ошибки копятся и копятся..
Нужна договоренность внутри команды. Мы решили это при помощи магической копилки!
Как отслеживаете кто профейлил?
Современные системы сборок могу показать после чьего комита упали тесты. Вся команда получит письмо с указанием виновника. 

понедельник, 11 июня 2012 г.

Testing Dojo №2: Как это было?

Вторые обучающие соревнования для тестировщиков - Testing Dojo состоялись в Киеве!

Компания Ciklum любезно согласилась принять нас на вершине своего элегантного офиса в бизнес центре Horizon Park.

Целью второй встречи было в деталях разобраться, что такое Exploratory Testing и отработать этот подход на практике.



Начали мы вовремя!

Я сделал небольшую презентацию, где повторил еще раз, что такое Exploratory Testing.
Simultaneously... 
  • learning about the software
  • designing the tests
  • executing the tests
  • using feedback from the last test to inform next

Exploratory Testing это не техника! Это подход, который может быть применен к любой из техник. Чтобы продемонстрировать один из примеров использования этого подхода я провел небольшую демонстрацию, как использовать инструменты по построению ментальных карт во время Exploraty Testing сессии.

Через 5 минут на экране остался всего 1 слайд, и пошел обратный отсчет на 30 минут.


Тестировщики получили тестовое приложение и за работу!



   



На флипчарте красовался список баллов, за каждую найденную багу.



Закончилась первая сессия, и мы перешли к этапу Debrief, то есть обсуждению вопросов и проблем, которые возникали на этапе тестирования. Мы разобрали типичные ошибки и нашли пути их решения.

После 5 минут на чай-кофе, все вернулись по местам.

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


В конце каждой сессии обязательно делать Debrief, чтобы обсудить насущные проблемы и найти им решение.

Третий этап был короче на 15 минут. Целью его было составить качественный отчет, по  найденным багам.
Когда все было готово, мы приступили к оценке результатов. Так как команд было 15, время было ограничено до 1 минуты на команду.

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





Это решение было ключевым за весь вечер! Я впервые увидел ситуацию, когда тестировщики как одна великая семья делились багами, обсуждали их причины, делили фишками, которые им помогли в работе!

Это был действительно обмен опытом, у людей горели глаза. Каждый открыл для себя что-то новое в тот вечер! 

Самые активные участники получили в подарок крутые футболки от организаторов предстоящей конференции Ukrainian Testing Days.







Спасибо всем, кто пришел! Вы сделали неоценимый вклад в свой профессиональный рост.
Exploratory Testing очень глубокий и философский подход, нельзя сказать, что все смогли овладеть им за 2 часа. Нужно еще многому учиться и практиковаться, чтобы научиться безошибочно трактовать эту методику.

Если хотите глубже разобраться в том, что такое Exploratory Testing - приходите на мой тренинг, который организовывается при поддержке коллег Xp Injection.

Следите за анонсами следующего Testing Dojo на сайте qaskills.com.ua

До новых встреч!

понедельник, 4 июня 2012 г.

Жаркий май и горячее лето



Месяц май выдался интересным. Все началось с поездки в отпуск. Это время дало шанс задуматься обо всем, на что раньше не хватало времени. Говоря конкретнее, я смог задать себе следующие вопросы:
  • доволен ли ты своей жизнью?
  • какие у тебя цели?
  • действительно ли эти цели твои?
  • чего ты вообще хочешь от жизни?
  • что сейчас мешает достичь того что ты хочешь?
  • как ты можешь изменить мир? 
Система, которую я создал для поддержки задач, помогала мне жить ничего не забывая, иметь гибкий план и контролировать выполнение задач. Если голова не перегружена информацией, ты справляешься со всеми важными делами, а что не помещается в голову - значит не важно. В тот момент, когда ты чувствуешь, что что-то пошло не так - сделай шаг назад проанализируй! После этого у тебя есть шанс пойти вперед и сделать все по-другому.

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

Я проанализировал свои активности и понял - нужно что-то менять. Первое решение, которое было для меня не легким - стал уход из проекта automated-testing.info и закрытие проекта lifedriver.com.ua.
При этом все договоренности по действующим под-проектам остаются в силе и я доведу их без потери качества!

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

Также, ко мне пришло понимание того, как построить идеальную модель тестирования на Гибких проектах. Это одно из самых узких мест, о котором умалчивает вся литература. Даже книга Agile Testing не дает однозначный ответ о том, как нужно разделять труд тестировщика и какое место Exploratory тестирования в современной разработке. Мне не терпелось поделиться этой идеей со всеми, кто меня окружал. Найдя поддержку на проектах в компании Lohika Systems, мы начали внедрение этого подхода.

Тема Exploratory тестирования обрела огромный интерес в Agile проектах, но многие не правильно трактуют принципы этого подхода, называя это лишь "тестированием по чек-листу". Это не просто тестирование, это еще и обучение и тест дизайн одновременно. Эта тема меня настолько задела, что я решил всерьез заняться развитием Exploratory тестирования на Украине.

В рамках этой идеи, при помощи партнера XP Injection мы запускаем тренинг, который полностью изменит ваше мышление как тестировщика. Заставит под новым углом посмотреть на тестирование в Agile и на Exploratory Testing в принципе. Сейчас мы набираем группы в Киеве и Днепропетровске. Поэтому, если вас заинтересовала эта идея, стоит поспешить на регистрацию тренинга, который увеличит вашу эффективность как тестировщика и заставит по-новому взглянуть на ежедневную работу. Ведь, тестирование это круто, это то - что заставляет нас гордиться этой профессией!

Также, по просьбе друзей и знакомых я решился провести очень мощный тренинг по Selenium. Тренинг действительно сильный, и поможет вам не только разобраться в этом инструменте, но и покажет успешные истории в применении Selenium на Гибких проектах. Программа 2-х дневного тренинга обещает быть интересной! Дата тренинга еще не определена, так как группа только набирается. Есть шанс записаться по скидочной цене.

В конце мая мы запустили новый проект - Первая всеукраинская конференция Ukrainian Testing Days. Цель конференции - объединить все сообщества тестировщиков Украины. Дополнительную информацию читайте на официальном сайте конференции!

30 мая мне выпала возможность выступить с докладом перед одесситами на QA Tech Talk. У меня было достаточно времени, чтобы донести участникам информацию о том, как быстро развернуть инфраструктуру для написания UI тестов под Web приложения. Фото встречи есть на Facebook.

Уже в начале лета мне удалось посетить тренинг по стартапам от Алексея Мася. Тренинг очень сильный и дополнил мою картину понимания бизнеса, дал ответ на вопрос - как начать свой бизнес с нуля, даже в тех случаях, когда у тебя нет идей или возможностей.

Лето обещает быть еще жарче. Впереди поездки по Украине с презентацией конференции Ukrainian Testing Days и модели Software Testing 2.0. За этим будущее, друзья!

Ближайшие планы: