Inject Agile practices for project health
Записи с метками тестирование
Отчет о выступлении на конференции SQADays-10
5 Декабрь
Я решил не откладывать в долгий ящик написание отчета о прошедшей конференции SQADays-10 и оформить его по горячим следам. Я давно собирался посетить эту конференцию, которая стала просто легендарной для тестировщиков, но все время что-то мешало мне это сделать. На этот раз обстоятельства сложились благоприятно и я решил выступить в качестве докладчика. Поэтому мой отчет будет не только глазами участника, но еще и опытного докладчика. В отчете я буду стараться держаться позитивной стороны, но будет проскакивать местами и конструктивная критика. Поэтому заранее прошу никого не обижаться. Как я писал некоторое время назад, негативная обратная связь несет больше всего информации.
Мы летели на конференцию из Киева с Андреем Дзыней, который тоже собирался выступить с докладом. Аэропорт Домодедово находится недалеко от места проведения, но нам все рекомендовали не рисковать и не ехать на такси. Поэтому, не смотря на достаточно ранний прилет, на место мы прибыли около 11-12 часов. Отель Милан, который принимал у себя конференцию, расположен недалеко от метро и мест в нем хватило на всех иногородних участников. С заселением проблем не возникло и мы, закинув вещи в номер, поспешили на доклады.
Первый день меня очень огорчил в плане докладов. До обеда в секции А было несколько спонсорских докладов и докладов про «космические корабли на просторах Большого Театра» от неизвестных мне зарубежных докладчиков. В секцию В пробиться было очень сложно, люди стояли сидели и повсюду. Сразу стало понятно, что организаторы погорячились с количеством участников. Разместить всех комфортно явно не удавалось. Поэтому поменять место дислокации у меня не получилось.
Наступило время обеда, который принес первое мини-разочарование. Выбор второго ограничивался одним блюдом, которым оказался рис с подливой. Суп тоже был только один. Скудно и не особо вкусно. Но, если учесть, что обед включен в стоимость участия, то с этим можно смириться.
После обеда я отправился на доклад Ромы Юферева, который знаком мне с конференции AgileDays’11. Тогда он покорил меня докладом про психологию работы с программистами. В этот раз Рома выбрал несколько странную тему для тестировщиков. Он рассказывал о том, сколько денег тратится в мире на поддержку программного обеспечения и что стоит внимательнее относиться к логированию ошибок, что поможет группе поддержки быстрее решать проблемы. Также была представлена концепция «карты здоровья» для проекта и участники смогли представить, как она может помочь в анализе и предотвращении проблем. Лично мое мнение – Роме стоит делать доклады по той области, в которой они у него получаются лучше всего. Это People Management. Мы вечером детально обсудили с ним эту тему в кулуарах.
Стоит отметить постоянные перебои с интернетом. Точки постоянно подвисали, иногда пропадали и интернет «тупил». А потом пришло разочарование для участников онлайн трансляции. В Twitter выложили ссылку на бесплатный доступ. Как-то непрофессионально было сделано, хотя сразу было понятно, что нагрузка на интернет будет очень большая.
Следующим докладом в моей персональной программе стал доклад Юли Нечаевой про лидерство в командах и ее реальный опыт в построении продуктивных команд. Юля как обычно подготовила хороший визуальный ряд, хотя я и не являюсь фанатом формата Prezi. Доклад основывается на реальном опыте, что всегда интересно и увлекательно. Да и Юля уже опытный докладчик, поэтому излишние комментарии тут не нужны – нужно смотреть запись выступления.
Кофе-брейк меня убил. 
Пирожки с непонятным содержимым внутри и растворимый кофе (может он был заварной, но по вкусу 100% растворимый).
Следующим был мастер-класс Андрея Дзыни про автоматизацию тестирования мобильных приложений. Андрей много кода демонстрировал в живую, в том числе и на своем телефоне. Я далек от разработки мобильных приложений, но даже мне было интересно послушать чем живет сейчас тестирование в этой индустрии.
В завершение дня я пришел на доклад Натальи Руколь. Наташа – отличный докладчик, но тема доклада была для меня лично набором советов от Капитана Очевидность. Слишком уж в радужных красках описывалась жизнь «правильного» тест-менеджера. Хотелось бы мне познакомиться с парочкой таких. 
После докладов началась торжественная часть, на которой нас ждал небольшой фуршет с легкими закусками и шампанским, выступление скрипачки и «зажигательный» ведущий. Апофеозом этого праздника стало награждение организаторами самих себя. Я был немного в шоке от происходящего. Особенно, когда нашелся однофамилец и теска Александра Орлова, а его отправили восвояси. Как-то выглядело это все странно и наигранно, при этом роль собравшихся участников была неясна. На дискотеку почти никто не остался.
Мы ушли под конец торжественной части и большой компанией засели отдыхать, кушать и пить вкусное пиво в ресторане «Интер». Это еще один большой плюс места дислокации конференции. Наличие хорошего ресторана делает пребывание на конференции более комфортным. Не надо тратить кучу времени на выбор места для «посиделок». А выбор пива и еда там на достаточно неплохом уровне. Хоть и накатывала усталость, но расходиться по номерам совсем не хотелось. Мы заскочили в гости к ребятам из Skype, которые жили с нами на одном этаже, и прообщались с ними до поздней ночи. Надо отдать должное ленте в Twitter – она не утихала даже ночью. 
Утро выдалось непростым. Недосып и отсутствие нормального утреннего кофе дало о себе знать. Мой мастер-класс в программе стоял перед обедом и пришлось приложить немало усилий, чтобы выглядеть бодрым и веселым. Тут хочу отметить пару серьезных недочетов в работе организаторов. Во-первых, микрофоны были ужасными. Радио-микрофон работал с перебоями, а стационарный не позволял далеко отойти и приходилось все время его держать в руках. Ощущения как у певца 70-ых. В 21-ом веке можно было бы сделать петличные или наголовные микрофоны, что на порядок удобнее для докладчика. Во-вторых, размер экрана оставлял желать лучшего. Ведь не у всех хорошее зрение и нет смысла заставлять участников мучиться. О своем докладе говорить много не буду. Скажу только, что ожидал большего интереса от автоматизаторов, возможно по привычке от аудитории в Украине. По приезду я подготовил слайдкаст выступления:
Все демонстрируемые примеры также опубликованы.
После обеда, который мало чем отличался от предыдущего дня, я отправился на круглый стол сообществ тестировщиков. Там царил хаос и неразбериха. Никто не понимал зачем все собрались. Каждый пытался вырвать для себя микрофон и рассказать свою историю. При этом даже «опытные гуру» вели себя точно также. Я отправился на стендовую секцию послушать Сашу Орлова, но сделать это было очень тяжело. Секция была забита народом, а все докладчики выступали без микрофона. Это я бы также отнес к недостаткам организации. Средней мощности колонки бы не помешали.
Следующим докладом я выбрал рассказ Екатерины Жульковой про удаленное тестирование. Этот доклад заставил меня позлиться. Все так славно получалось у докладчицы: они не считают себя командой, работает кто когда хочет, программисты днем работают, а тестировщики ночью тестируют, оценивают задачи как хотят… И главное, все счастливы! Если так все в жизни просто и легко, зачем выдумывается столько процессов и практик? Зачем весь мир сейчас движется в сторону Agile с построением настоящих команд? Окончательно добил комментарий по поводу оценок в проекте от одного из участников: «Оценку может делать только эксперт. Нет эксперта – нет оценки!». Я на некоторое время ощутил себя в другом мире. Брррррр! Неприятное ощущение!
Злой я отправился на доклад Кати Каменевой и, как оказалось, очень правильно сделал. Катя рассказывала про процесс тестирования в их компании, взаимодействие с разработчиками, полезные практики и инструменты. Я бы смело назвал этот процесс отличным примером Agile тестирования. Я лично знаю Катю – она была у нас на конференциях, тренингах и прочих мероприятиях. Для меня этот доклад стал лучшим на конференции. Отличный визуальный ряд, уверенный рассказ про собственный опыт с примерами и реальными историями. И успешный проект, который поднял очередные инвестиции. Особенно классным было то, что доклад «взрывал мозг» большей части аудитории. Twitter лента кипела комментариями. Вопросы после доклада к Кате были провокационные, но лишенные смысла: «можно ли так добиться 100% качества», «а что если вся ваша команда тестировщиков уволится», «а вы не думали взять и все задокументировать»… Катя держалась молодцом и отлично отбивалась от всех нападок. Класс!
На следующий доклад я не пошел и потратил время на убеждение одного знакомого в том, что Continuous Delivery является замечательной практикой, которая стимулирует построение правильного процесса разработки и тестирования с множеством других полезных практик и подходов. Потом снова встретил ребят из Skype и провел мини-презентацию одного из инструментов на основе WebDriver – Thucydides. Еще успел много с кем пообщаться, за что им большое спасибо!
Последним докладом я выбрал мастер-класс от Орлова и Панкратова. Это было очень весело. Мы делали самолетики, разбившись по командам. Наша команда заняла второе место. Потом смотрели живые спектакли от участников конференции на тему неконструктивных команд. Ребята молодцы и придумали классный развлекательный формат. В самом конце они провели аналогию коммуникативных отношений с жизненным циклом дефекта и дали несколько советов участникам. Мастер-класс был веселым, но малоинформативным, хотя кого-то 100% заставил задуматься.
На официальное закрытие я не остался и отправился ужинать все в тот же ресторан «Интер». Нас опять было много. Шутили, пили пиво, знакомились, рассуждали об образовании, тестировании, конференции и прочих общих темах. Было классно, но нужно отправляться домой. Мы вылетали поздно вечером и до полуночи уже были дома.
Подведу итоги. В целом я доволен поездкой. Тестировщики – очень позитивный народ и всегда активно общаются, обсуждают проблемы и подходы. Для меня поездка стала очередным опытом работы совершенно с непривычной аудиторией. А такой опыт сильно развивает. Я записал себе несколько классных идей на будущее, что происходит не так часто. Отметил для себя недостатки организации, которые постараюсь не повторять в своих мероприятиях. Познакомился с новыми интересными людьми и наметил планы на сотрудничество. Спасибо всем, кто участвовал в конференции! В следующем году будем рады принять SQADays-11 в Киеве!
Боремся с бесконечными итерациями
29 Ноябрь
Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.
Команда провела анализ и выделила возможные причины такой ситуации. Первая причина в том, что очень мало времени остается на саму работу в спринте за вычетом всех «процессных» задержек. Вторая заключается в том, что циклы тестирования и разработки «натурально» не совпадают и никто не может аргументировать в чем недостатки данной ситуации.
Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.
Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.
Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.
Но самый главный вопрос – это вопрос понимания цели самих итераций. Итерации нужны для предсказуемости, налаженного ритма выполнения обязательств и слаженной деятельности без помех извне. Если задачи могут легко переноситься на следующую итерацию, то предсказуемость теряется. Никто не знает сколько задач завершит команда в очередной итерации. Ритм тут же теряется тоже, потому что ни у кого нет ощущения законченности выполненной работы и старта новой итерации с чистого листа. Вместо этого тянется тестирование и другие активности из прошлого. Пока все в команде не осознают этого, менять что-то почти бессмысленно.
Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:
- Планируйте ровно на столько, сколько вы можете полностью закончить в итерацию. Не тратьте время на планирование остального. Это и сэкономит вам время и не будет никому давать несбыточных обещаний. Лучше возьмите еще работы, если все закончите в срок. Это будет гораздо приятнее и команде и заказчику, чем в очередной раз получить часть обещанного не готовым.
- Для более плотной командной работы над задачами и инкрементальности внутри итерации установите лимиты на количество задач, которые находятся в прогрессе. Причем жесткие и непоколебимые лимиты. Они будут вас заставлять помогать друг другу, делить большие задачи на маленькие, автоматизировать ручную работу и не распыляться на много задач сразу. Это повысит вашу эффективность.
- Для решения проблем с циклом тестирования внедряйте активно автоматизацию. Причем не просто автоматизацию, а различные вариации TDD (Test Driven Development). Чем больше тестов будет написано до завершения реализации задачи, тем меньше времени уйдет на тестирование. Еще одна практика, которая очень сильно может помочь – Slicing Development. Не разрабатывайте по несколько дней целиком готовую фичу. Вместо этого выкатывайте несколько промежуточных реализаций с урезанной функциональностью и отдавайте на тестирование.
- Ну и последний совет очевиднее всех – проведите ретроспективу и разберитесь в том, что происходит. Если команда или руководство не понимают зачем это все нужно, то все предыдущие усилия будут просто бесполезны. Возможно, в результате разбора окажется, что Scrum в вашем случае совершенно не подходит. Такое тоже бывает. Scrum – не серебряная пуля.
Ну и конечно же не опускайте руки. Из любой ситуации есть выход, его надо только поискать. Удачи этой команде и всем, кто сталкивается с подобными проблемами!
Мой мастер-класс на конференции SQA Days 10
9 Ноябрь
2-3 декабря в Москве прогремит очередная масштабная конференция тестировщиков SQA Days 10. Детальная программа конференции уже подготовлена и опубликована. Участники смогут услышать множество докладов на совершенно разнообразные темы из области тестирования. Я давно хотел выступить на этой конференции и в этом году выкроил время и подготовил мастер-класс на тему «DSL, Page Object и WebDriver – путь к надежным функциональным тестам».
Впервые идея данного мастер-класса была реализована на конференции Selenium Camp. Презентация этого выступления выбилась в лидеры среди всех моих презентаций и была просмотрена более 5000 раз. Это свидетельствует о большом интересе к данной теме. С тех пор в мире Selenium многое изменилось – вышел Selenium 2.0 (aka WebDriver), в котором много подвижек было сделано в сторону применения шаблона Page Object. Я полностью переделал презентацию и примеры с применением новых возможностей, а также расширил список рассматриваемых инструментов. Детальное описание мастер-класса:
«Нестабильность автоматических тестов – актуальная для многих проблема. Вы наверняка сталкивались с ней не раз, если пробовали использовать инструменты, работающие через пользовательский интерфейс. Тесты очень сильно завязаны на структуру страниц, расположение элементов и их атрибуты.
На примере реального приложения будет продемонстрировать, как, используя шаблон Page Object с WebDriver/Selenium, разработать доменный язык (DSL) и использовать его в тестах. Это сделает ваши тесты более надежными, изолированными от технических деталей работы инструмента, а также сильно упростит их поддержку и модификацию.
Концепции и техники, представленные в мастер-классе, вы сможете успешно применить и с другими инструментами автоматизации тестирования.»
Чтобы сделать мастер-класс еще полезнее и интереснее, вы можете заранее задать вопросы или обозначить особенно интересные области. Сразу оговорюсь, что я буду рассказывать о грамотных подходах к написанию тестов с использованием Selenium/WebDriver, а не об особенностях работы самого Selenium/WebDriver. Пишите в комментариях к этому анонсу или в Twitter @xpinjection. Буду рад услышать ваши пожелания!
Отчет о конференции QADnepr Mini Conference
31 Октябрь
В эту субботу 29 октября в Днепропетровске прошла первая конференция QADnepr Mini Conference от сообщества QA Dnepr. Темой была выбрана автоматизация тестирования. Сама конференция задумывалась как небольшое мероприятие на целый день с выступлениями в один поток. Докладчики собрались из разных городов Украины: Киев, Харьков и Днепропетровск. Темы докладов также подобрались совершенно разнообразные – от нагрузочного тестирования до тестирования мобильных приложений.
Меня пригласили выступить задолго до официального анонса и я решил разбавить конференцию взглядом со стороны разработчика. На моем текущем проекте мы уже долгое время работаем без тестировщиков. При этом проект успешно развивается и прошел уже немало публичных релизов. Это стало возможным по большей части благодаря автоматизации тестирования. Но о моем докладе чуть позже. Сначала о самой конференции.
Организаторы выбрали очень классное место проведения – конференц-зал в новеньком офисе компании «Киевстар». Здание находится недалеко от центра и открыто совсем недавно. Конференц-зал идеально подходит для проведения подобных мероприятий на 150-200 человек. Удобная сцена для докладчика, мягкие сиденья для участников, правильная форма зала, которая дает отличный обзор для всех присутствующих – все это делало посещение докладов очень комфортным. Как докладчик я еще могу добавить в копилку плюсов отличный звук и проектор, который не слепил глаза.
Утром я приехал пораньше чтобы выпить кофе и поболтать с коллегами. Просторный холл к тому времени уже был заполнен тестировщиками, общением и хрумканьем печенюшек. Приятно порадовало присутствие фруктов на всех кофе-паузах. Организаторы позаботились об участниках, закупив яблоки и бананы. С кофе вышла небольшая накладочка – хотелось бы «проснуться» от натурального кофе, а не напитка «3 в 1″. Но это уже если сильно придираться. Я повстречал много знакомых из разных городов, среди которых было достаточно много участников моих тренингов. Было очень приятно всех видеть. Такой интерес к конференции говорит о недостатке такого рода мероприятий и о верном выборе организаторов. Ведь иначе люди бы не ехали за сотни километров.
В холле стояли стенды компаний-спонсоров конференции. Они раздавали анкетки, по которым в конце дня должны были разыгрывать призы. Мое внимание привлекла игровая приставка Xbox с установленным к ней Kinect. Любой желающий мог свободно попробовать себя в различных играх. Я давно хочу приобрести себе такую домой и поэтому с радостью принял участие в виртуальном боксерском поединке. Было очень классно. Необычные ощущения. Мне удалось даже одержать победу техническим нокаутом. Рекомендую всем!
Конференция началась вовремя с вступительного слова организаторов. Это их первое подобное мероприятие и они очень волновались. Во время открытия я обнаружил вторую и последнюю проблему – отсутствие Wifi. Я планировал вести трансляцию в Twitter, по крайней мере чтобы дать повод для подколов Леше Солнцеву. Но не судьба.
Перед началом докладов публике были представлены все докладчики. И еще не могу не упомянуть об еще одном приятном новшестве – в пакетах участников были специальные карточки обратной связи докладчикам. Каждый участник мог написать свой отзыв на карточка и отдать ее докладчику, который ему понравился больше всего. Это очень здорово, потому что дает возможность докладчикам сразу же получить обратную связь и увидеть насколько был интересным его доклад. Да и вообще работает как классный мотиватор. Мы не привыкли выражать слова благодарности и делиться позитивными эмоциями в отличии от зарубежных коллег. А это очень важно и здорово помогает докладчикам.
Открыл конференцию своими размышлениями о разработке собственных фреймворков Артем Розуменко. Он рассказал как и зачем разработал в компании свой фреймворк, который успешно используется на различных проектах. Доклад был очень живым и построен на реальном опыте. Да и Артем держался уверенно. Видно опыта у него немало. Он провел участников через все стадии эволюции своего фреймворка, просто и понятно объяснив что побуждало его к изменениям. Думаю доклад понравился многим и был весьма полезен.
После перерыва на сцену вышел Гена Алпаев, который слывет гуру TestComplete. К слову, перерывы были по 15 минут и этого с лихвой хватало на отдых и общение. Здорово когда на следующий доклад приходишь отдохнувшим. Гена рассказал как улучшил свои тесты случайными данными, повысив покрытие и уменьшив вероятность пропустить ошибку в приложении. Это полезный подход, который стоит взять на заметку всем автоматизаторам и разработчикам.
Перез обедом мой коллега по компании Zoral Labs Иван Лысенко поделился советами по поводу анализа результатов нагрузочного тестирования. На мой взгляд доклад был очень классный, ведь организовывать тестирование – это лишь половина дела. Ошибка при анализе его результатов может свести на нет все усилия. Иван на примере показал способы обработки статистической информации и связывания ее с проблемами в приложении. Здорово, что данная тема была затронута, ведь ее освещают не так часто как стоило бы.
На обед организаторы выделили полтора часа и этого времени хватило с лихвой. К сожалению кафе в самом месте проведения не согласилось организовать обеды участникам. Поэтому все разбрелись по кафешкам и торговым центрам, которые были отмечены на карте в пакете участника. Карта – это еще один балл в копилку организаторам.
Мне пришлось выступать после обеда. Это самое сложное время. Не все успевают вернуться, многих после обеда клонит в сон и не все готовы воспринимать информацию. А еще и тема моего доклада была достаточно провокационной – «Жизнь без тестировщиков: миф или реальность?». И это на конференции тестировщиков-автоматизаторов!
Я собирался осветить 3 важных вопроса: зачем обычно нужны в проектах тестировщики, как избавиться от этих нужд, а также в чем состоит действительно полезная и незаменимая функция тестировщиков. Доклад лишь по касательной затрагивал автоматизацию тестирования в разрезе советов и правил для работы команды разработки. Я не знал как воспримут доклад участники. Несколько раз во время выступления я даже ловил себя на мысли, что я пришел не туда и людям неинтересно.
Но оказалось, что многим мой доклад пришелся по вкусу. Было очень много вопросов. На ответы ушли все отведенные на это 10 минут и 15 минут перерыва. Вопросы были разносторонние и интересные. Кто-то поддерживал мои взгляды, кто-то делился опасениями и сомнениями по поводу описанных подходов, кто-то спрашивал о конкретных рекомендациях в своем контексте. Большое спасибо за это общение! Надеюсь вы узнали что-то новое и задумались о возможности улучшить ваши процессы и подходы к работе в проекте. Я получил очень много благодарственных листочков обратной связи, о которых я рассказывал в начале обзора. Причем они продолжали поступать до самого закрытия конференции. Хочу поблагодарить всех за приятные слова и поддержку! Это очень-очень приятно и заряжает положительной энергией.
Пересказывать свой доклад в деталях не буду. Вот презентация (звук добавлю как только организаторы им поделятся):
Следом за мной выступал Александр Качур с докладом про автоматизацию мобильных приложений под Android и MeeGo. Я очень далек от мобильной разработки, поэтому мало что вынес для себя полезного из доклада. Очень жаль, что не заработали видеоролики с демонстрацией написания и запуска тестов. Без них доклад смотрелся немного неполным. Но это была, к сожалению, неожиданная техническая проблема, которую так и не удалось победить. Зато для себя я сделал заметку с идеей очень классного выступления.
Алексей Зозуленко выступил с докладом про распределенный запуск Selenium тестов. Содержание доклада достаточно простое – зачем, как и с помощью чего ускорить запуск ваших тестов. Алексей поделился своими наработками использования Selenium Grid. С этим докладом он уже выступал на нашей конференции Selenium Camp и, надеюсь, дал повод задуматься над ускорением своих тестов всем участникам.
Закрывал конференцию своим выступлением Андрей Дзыня. Он демонстрировал инструмент для автоматизации веб-приложений Watir. Отличительная особенность этого выступления заключалась в большом количестве живых демонстраций. Мне кажется, что это очень правильный формат. Он дает участникам представление об уровне сложности использования инструмента, а также оживляет зал. Мне выпало в этот день еще раз оказаться на сцене во время доклада, но на этот раз в роли ассистента. Я подрабатывал стойкой для микрофона, развязывая руки для работы Андрею. Доклад получился слаженным, живым и практичным. В конце даже затронули тему BDD и активно обсудили ее с участниками в зале. Андрей разыграл две книги в качестве призов тому, кто найдет умышленно допущенные ошибки в его презентации. Книги, к моему удивлению, нашли своих обладателей, что в очередной раз напомнило о профессии собравшихся в зале людей.
Это был последний доклад. После него начался розыгрыш призов. Он принес несколько неожиданностей. Во-первых, Андрей Дзыня умудрился выиграть Amazon Kindle, который он очень хотел. Во-вторых, я прислушался к советам Кэпа Очевидность и заработал много баллов в викторине о компании-спонсоре Apriorit, за что был награжден веб-камерой. Вот такие приятные сюрпризы. Потом все докладчики вышли на сцену вместе с организаторами для прощальных аплодисментов. На этой позитивной нотке закончилась первая конференция сообщества QA Dnepr. Но, по словам организаторов, далеко не последняя. Такие мероприятия очень сильно развивают рынок IT. Поэтому хочу пожелать ребятам успехов в их нелегком труде.
После конференции все желающие отправились на афтепати в один из пивных ресторанов Днепропетровска для неформального общения. Докладчики, участники и организаторы делились мнениями о прошедшей конференции, тестировании и планами на будущее. Мне удалось достаточно вкусно покушать, что на подобных мероприятиях происходит нечасто.
В целом я остался очень доволен посещением этой конференции. Организаторы очень удивили высоким уровнем проведения мероприятия, особенно неожиданным с учетом первой попытки. Отличная программа, слаженные действия всех задействованных лиц, классное помещение и техническое оснащение – это как раз то, чего не хватает многим посещенным мной мероприятиям. Отдельное спасибо за приглашение выступить! Надеюсь, что не в последний раз.
Автоматизировать или нет … мытье посуды?
11 Октябрь
Я недавно вспомнил о своей статье на тему сравнения автоматизации тестирования и мытья посуды и решил дополнить ее еще несколькими сходствами. Мне кажется, что аналогия получилась очень интересная. Теперь я уже «автоматизатор» мытья посуды и могу пересмотреть некоторые взгляды. Итак:
- Автоматизация требует постоянных материальных затрат. В случае мытья посуды это покупка средств для посудомоечной машины, увеличенный расход воды и электроэнергия. В случае тестирования это поддержка тестов в нормальном состоянии, ускорение медленных тестов, выделенные сервера для тестирования, лицензия на инструмент (если он платный) и т.д. Выбирая автоматизацию, вы должны понимать, что постоянные затраты неизбежны.
- Автоматизация спасает в сложные моменты. В случае мытья посуды это необходимость быстрой уборки перед приходом гостей, приготовление романтического ужина (ни у кого нет желания после него мыть посуду), уборка после вечеринки (когда вся посуда была уже задействована и готовить завтрак попросту не в чем). В тестировании это срочная доработка перед релизом, рефакторинг кода приложения или неожиданное желание выкатить версию продукта прямо сегодня. Осознание рабочей автоматизации за спиной придает уверенности.
- Автоматизация не всегда нужна. В случае мытья посуды это жизнь холостяка, который очень редко кушает дома или покупает готовые блюда в магазине, а потом разогревает их дома. Или кто-то без ума от самого процесса мытья посуды. В тестировании это небольшой проект или проект, который развивается очень медленно и у тестировщиков куча времени на ручное тестирование. Или функциональность достаточно проста и может быть проверена в ручном режиме быстро. В этом случае автоматизация может оказаться абсолютно бессмысленной процедурой, которая не оправдает вложенные средства.
- Автоматизацию в принципе можно заменить ручным трудом. В случае мыться посуды это попытки использовать детей или других членов семьи, которым якобы нечего особо делать. В тестировании это попытка использовать грамотного тестировщика для ручного тестирования (мол работы важнее нет) или наем дешевой рабочей силы низкой квалификации. Да, оба варианта возможны и существуют в реальной жизни. Вопрос в том, насколько это влияет на мотивацию и внутреннее состояние исполнителей, а также на финансовую сторону вопроса. И тут нужно быть предельно аккуратным.
- Средство автоматизации следует выбирать под проект. В случае мытья посуды следует тщательно выбирать технику по размеру и качеству, а также средства для мытья. От этого зависит объем вымытой посуды и качество мытья. В случае тестирования важно понимать специфику проекта, используемые технологии, возможности инструмента, простоту в поддержке и модификации тестов. На рынке существует множество платных и бесплатных инструментов. Осуществив выбор, будет уже тяжело поменять его в будущем
- Автоматизация работает гораздо лучше человека. В случае мытья посуды вы никогда не добьетесь такого же качества мытья руками. Например, вы просто физически не можете мыть руками при такой температуре. В случае тестирования вы убираете человеческий фактор и получаете огромный прирост в скорости тестирования. Правильно написанный тест никогда не ошибается и ведет себя одинаково по отношению к приложению, обеспечивая настоящую надежную проверку.
- Не все может быть автоматизировано. В случае мытья посуды вы не можете мыть в машинке изделия из пластика и дерева. В случае тестирования вам недоступны некоторые виды тестирования: usability, exploratory, некоторые части тестирования UI. Всегда останется часть работы, которая должна выполняться вручную. Вопрос какой эта работа будет иметь объем.
Вот такой вот забавный и отнюдь не серьезный сравнительный анализ. Статья служит сразу двум целям – подтолкнуть вас к автоматизации тестирования и покупке посудомоечной машины. Сделайте свою жизнь проще и используйте свое личное время с пользой!
WebDriver, Kanban и риски
7 Октябрь
Помимо множества других мероприятий, осенью мы организуем ряд тренингов. Они пройдут в октябре-ноябре в Киеве.
15 октября запланирован популярный тренинг «Тестирование веб приложений с WebDriver/Selenium». Программа тренинга была полностью переработана после выхода долгожданной версии Selenium 2.0 (aka WebDriver). Из тренинга были выброшены отжившие свое части, все примеры были переписаны с нуля и расширены для демонстрации новых возможностей WebDriver, добавлены некоторые новые инструменты в обзор решений на базе WebDriver/Selenium, описан переход от старой версии на новую и еще много всего интересного. Группа на 15 октября собралась очень быстро, поэтому мы проведем тренинг еще раз 19 ноября. Регистрация открыта и осталось 6 вакантных мест. Торопитесь зарегистрироваться!
22 октября состоится один из самых полезных тренингов «Kanban для управления проектами». Kanban только на первый взгляд выглядит простым подходом для разработки. На самом деле существует очень много тонкостей и полезных практик, которые помогут уберечь вас от ошибок и сделают разработку действительно быстрой и качественной. Тренинг содержит несколько практических упражнений, которые заставляют совершенно по-другому взглянуть на взаимодействие внутри команды и с внешним миром. Участники научатся пользоваться инструментами для анализа и оптимизации процесса разработки в целом. Также будет затронута тема перехода к Kanban с других подходов, благодаря чему каждый сможет сделать осознанный выбор при постановке процесса разработки. Данный тренинг будет полезен разработчикам, лидерам и менеджерам команд для оптимизации работы своей команды. Регистрация продолжается и на данный момент осталось только 4 места.
5 ноября к нам в гости из Харькова приедет Сергей Поволяшко для того, чтобы провести тренинг «Управление рисками в IT проектах». Сергей имеет очень большой опыт работы в IT и имел возможность попробовать себя на разных позициях. Уже около 6 лет он работает на должности CTO в компании TEAM International, поэтому о рисках знает не по наслышке. Сильная теоретическая база Сергея подкреплена сертификациями PMP и ITIL. А на практике свои знания он применяет уже долгое время как опытный менеджер и руководитель. Тренинг далек от сухой теории, в нем много практических упражнений, которые помогают участникам лучше разобраться в теме. В тренинг впервые будет включена игровая симуляция командной работы над рисками, которая позволит участникам проверить себя на практике и понять насколько они освоили материал. Эта симуляция уже проводилась на нескольких Agile конференциях Борисом Вольфсоном (за что ему большое спасибо) и пользовалась большим успехом у участников. Регистрация на тренинг уже открылась и продлится до 1 ноября. Количество мест ограничено.
Также на ноябрь мы готовим один приятный сюрприз для всех любителей и практиков Agile подходов. Подробности вы узнаете очень скоро. Оставайтесь с нами!
Selenium IDE в руках разработчика
5 Октябрь
WebDriver/Selenium на данный момент является самым популярным инструментом для автоматизации тестирования веб-приложений. Он бесплатный, гибкий, работает напрямую через браузер, доступен в разных языках программирования… Но я буду в этой статье рассказывать не об этом. В комплекте инструментов Selenium есть замечательный инструмент, который могут использовать не только тестировщики, но вообще кто угодно. Речь идет о Selenium IDE.
Изначально Selenium IDE задумывалась как среда для записи тестов и их отладки с последующим переносом в Selenium Core (царствие ему небесное) или в Selenium RC (ныне WebDriver). Но это далеко не все возможности, которые доступны на данный момент. Ведь разработчики редко пишут функциональные тесты, а значит использовать IDE по прямому назначению не всегда имеет смысл. Тем не менее, я считаю этот плагин к Firefox одним из самых полезных. Ведь он помогает мне экономить кучу времени. Поэтому на проводимых мной тренингах уделяю ему достаточно времени, чтобы донести полезность данного инструмента до участников.
Я приведу лишь несколько возможных способов использовать Selenium IDE не для тестирования:
- Автоматизация длинных скучных сценариев по работе с веб-приложениями. Если вы часто ходите на одни и те же сайты, выполняя похожие операции, то логичнее всего их автоматизировать. Например, вы переводите задачу на ревью или производите поиск товаров в определенной категории на сайте интернет-магазина.
- Запись новой идеи, найденной вами на чужом сайте. Вместо подробной инструкции по прохождению сценария запишите его с помощью Selenium IDE. Это сбережет ваше время и время ваших коллег.
- Автоматизация поздравлений в социальных сетях. Все ваши друзья будут получать поздравления с праздниками, а вы будете тратить на это очень мало времени.
Список таких примеров можно продолжать и дальше. Некоторые наивно полагают, что Selenium IDE не развивается. Напротив, в последнее время она претерпела множество позитивных изменений: переход на архитектуру плагинов, гибкие настройки выбора локаторов, множество вспомогательных инструментов и расширений. На данный момент при должной конфигурации у вас под рукой реальная среда для автоматизации операций над веб-приложением.
Я расскажу о достаточно свежем расширении, которое считаю наиболее полезным именно для разработчиков. Предположим вы записали много различных интересных сценариев и хотите их использовать. Вы открываете Selenium IDE, выбираете пункт меню Open или Open Test Suite (зависит от способа хранения сценариев), долго и упорно лазите по папочкам чтобы найти свои сценарии, потом они загружаются и вы их запускаете. Как-то чересчур сложно все получается. Для упрощения работы с постоянно используемыми сценариями служит плагин Favorites. Вы можете пометить любой test suite как «любимый», после чего он появляется в выпадающем меню быстрой загрузки (показано на картинке выше). Вы выбираете его и он загружается автоматически. А если выбрать его, удерживая клавишу Ctrl, то он сразу же запустится. Это экономит кучу времени.
Пользуйтесь на здоровье и экономьте ваше время, автоматизируя однотипные повторяющиеся операции.
Должен ли заказчик платить за модульные тесты?
28 Сентябрь
Вопрос о том, а должны ли заказчики платить за модульные тесты и как им их продать, я слышу очень часто. Последний раз мы обсуждали его на тренинге «QA в Agile» в Днепропетровске. Вопрос очень интересный и существует немало мнений на этот счет. Я попытаюсь изложить свое в этой статье.
Начну с того, что уже некоторое время прослеживается очень положительная тенденция. Большинство разработчиков в Украине пишет модульные тесты или хотя бы хочет их писать. Я говорю об Украине, потому что в России дела обстоят на порядок хуже. Это действительно очень классная тенденция, которая говорит о заботе о качестве кода со стороны самих разработчиков. Разработчики начинают осознавать пользу от модульных тестов и использовать их в своей работе добровольно. Таким образом, тесты становятся неотъемлемой частью работы разработчика, без которой ему работается не так комфортно и не так быстро (по крайней мере в долгосрочной перспективе).
Теперь давайте разберемся кто за что должен платить. Выполнение задачи раскладывается на множество составляющих: обсуждение требований, дизайн сессия, модульные тесты (надеюсь, что с использованием TDD), реализация функциональности, рефакторинг решения, интеграция в общий код, прогон всех тестов, проверка задачи вручную, обновление документации (если она есть в каком-либо виде), закрытие задачи в task tracking системе (или на доске задач). Это далеко не полный список для некоторых команд и проектов. Заметьте как много тут активностей. И теперь давайте выкатим этот список заказчику (возможно с оценками по времени для каждого пункта), чтобы выяснить за что он должен платить. Если у него будет выбор, то он выберет один пункт – реализация функциональности. Остальное ему неважно, поэтому он и не хочет за это платить. Ведь вы сами дали ему выбор.
Нужно изменить подход. Не выкатывайте заказчику детали вашей работы (по крайней мере в контексте разговоров об оплате). Вы делаете задачи по устоявшемуся для вас процессу, который позволяет делать их быстро и качественно. И редактировать данный процесс вам нет смысла. Заказчик может его принять либо отказаться, но частичный прием может сделать только хуже, причем всем участникам. Почему? Все дело в мотивации. Я уже писал о том, что нас на самом деле мотивирует. В данном случае работа по устоявшейся и «правильной» схеме дает нам возможность делать работу на приемлемом для нас уровне качества. Это доставляет нам удовлетворение проделанной работой и радость за ее результаты. Что нас и мотивирует. Никто не любит работать с бешеной спешке, пытаться выковырять причину бага и исправить ее в коде без тестов, часами пытаться понять кусок кода без малейшей возможности его изменить (потому что неизвестно, к чему это приведет). Поэтому цикл работы над задачей определяется командой и ее членами. И он не должен приводить к демотивации.
Что же делать, если заказчик или остальная команда противостоит внедрению модульных тестов? Такие случаи тоже бывают. Для вас это отличный шанс поднять свой уровень. Ведь вам нужно преодолеть серьезную преграду. А открытый конфликт и правильная борьба (не руганью и силой) заставляют вас делать очень серьезный анализ, преподносить результаты с выгодных сторон, искать правильные аргументы, разобраться в проблематике досконально. Это здорово и дает очень хороший опыт.
Если же по истечение какого-то времени у вас не осталось сил и вы все перепробовали, то просто проверьте свой мотивационный список. Выпишите все факторы, которые мотивируют вас для дальнейшей работы в команде или компании. Добавьте туда демотивирующие факторы. Каждому из них проставьте вес. Посчитайте сумму. Если сумма получилась отрицательная, то задумайтесь о разговоре с менеджером или смене работы. Жизнь одна и не стоит тратить ее на ту работу, которая делает вас несчастным!
Перенос тренинга «QA в Agile», встреча Kiev ALT.NET и другие новости
16 Сентябрь
Начнем с неприятных новостей. По техническим причинам нам пришлось перенести тренинг «QA в Agile» на неделю вперед. Он состоится 24 сентября в Днепропетровске. Приносим извинения всем, кому доставили неудобства данным переносом. Желающие принять участие в тренинге могут регистрироваться. Регистрация продлится до четверга 22 сентября.
Наш «Клуб анонимных разработчиков» начинает сотрудничать с другими сообществами разработчиков. Коллеги из Kiev ALT.NET приглашают всех членов клуба принять участие в очередной встрече 23 сентября в Киеве. Эта встреча будет посвящена NoSql решениям. В программе анонсировано 3 доклада и афтепати, где все смогут в непринужденной атмосфере пообщаться на разные интересные темы. Приходите, будет классно!
Мы выбираем тему для следующей встречи клуба и ищем желающих подготовить выступление. Не стесняйтесь обращаться со своими предложениями. Это отличная возможность попробовать себя в качестве докладчика и лучше разобраться в какой-то теме. Как говорится, лучше всего можно понять что-то, если учишь этому других.
29 октября в Днепропетровске состоится конференция QADnepr Mini Conference. Я подал заявку на выступление с темой «Жизнь без тестировщиков: миф или реальность?». Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но тестировщик – это скорее роль, чем конкретный человек. И эта роль может быть распределена между всеми членами команды. Также необходима полная автоматизация тестирования на всех уровнях, что и позволяет заменить работу тестировщиков, а именно их работу по «проверке» работы приложения. Это дает возможность работать без тестировщиков или высвобождает время тестировщика для действительно важных дел (тестирование методом свободного поиска, помощь в критическом анализе требований, помощь в составлении приемочных тестов и т.д.). При этом качество продукта остается на высоком уровне. Для построения такого процесса качество должно стать целью всей команды: разработчиков, заказчиков, аналитиков и прочих. Вот тогда и начинается магия…
Модульные тесты могут быть документацией
15 Сентябрь
Модульные тесты имеют много полезных свойств: они позволяют запустить маленькую часть кода и убедиться в его работоспособности, они помогают осуществлять рефакторинг, служат «страховочной» сетью для любых изменений в коде и т.д. Существует противоречивое мнение, что модульные тесты могут являться документацией к модулю, классу, методу или просто части кода. Одни с ним соглашаются, другие твердят, что тесты невозможно читать и тяжело понять какая функциональность скрыта в самом коде. Я разделяю мнение обеих сторон. Если не уделять внимания тестам и писать их по принципу «для галочки», то использовать их в качестве документации крайне сложно. Если же заранее вкладывать документирование кода в задачу модульных тестов, то это вполне реальная цель.
Эта статья будет не о том, как нужно писать тесты. Речь пойдет о именовании тестов. Примеры я буду приводить на Java, так как это мой «родной» язык (после русского и белорусского). Большая часть модульных тестов пишется с использованием JUnit или TestNG. Эти инструменты уже не накладывают на разработчика правил именования тестовых методов (в прошлом JUnit требовал, чтобы тесты начинались с префикса ‘test’). Достаточно лишь пометить метод тестового класса соответствующей аннотацией @Test. И это здорово, потому что вы можете выбирать любое имя, которое вам удобно.
Этой возможностью можно и нужно пользоваться. Название тестового метода должно отражать суть тестируемой функциональности. Например «if no signal groups with required type return empty set» может быть записано как «ifNoSignalGroupsWithRequiredTypeReturnEmptySet». Вроде бы все логично, но воспринимать такое имя не так просто как кажется. Все дело в разделителях, к которым мы привыкли при чтении текста. К сожалению нельзя использовать пробелы в имени метода. Можно использовать другие разделители, например ‘_’. Приведенный выше пример превращается в «if_No_Signal_Groups_With_Required_Type_Return_Empty_Set». Это уже лучше. Но есть еще одна проблема. Документацию хотелось бы видеть в более удобном формате, к примеру в виде списка возможностей.
И тут вам на помощь приходит IDE. Я обнаружил замечательный инструмент под названием TestDox (стыд мне и позор, что я обнаружил его только сейчас). Он решает все описанные выше проблемы и позволяет создавать, изменять и просматривать все тесты в виде обычного текста. Данный инструмент работает в виде плагина к IDE и может быть использован с разными языками программирования. Ниже приводится пару скриншотов его работы с комментариями:
Вы можете видеть все сценарии на обычном английском языке и переходить от описания к тесту или к описанию из теста. С этой же панели есть возможность создать новый тест. Панель сделана плавающей для того, чтобы скриншот был более крупным.
Вы можете редактировать любой тест и описание автоматически преобразуется в имя тестового метода. При таком подходе вы можете не задумываться над удобочитаемостью названия метода и писать реальное описание функциональности.
У данного инструмента есть еще настройки, но их изучение оставлю вам в качестве домашнего задания. Пишите свои тесты так, чтобы они приносили максимум прибыли в будущем. С помощью описанного инструмента ваши модульные тесты могут быть настоящей документацией, не хуже комментариев.
