Прошло уже много лет с тех пор, как Agile пришел в нашу жизнь. Этот переход многим дался нелегко. Всем членам команды пришлось учиться работать заново. Ведь работать приходилось в более динамичных и гибких условиях. Никто не остался незамеченным: бизнес аналитики, программисты, дизайнеры. Даже заказчиков заставили быть Product Owners и тесно взаимодействовать с командой. Сама разработка стала быстрее в разы, ведь теперь основной целью стал один из принципов “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. В таком ускоренном режиме вопрос тестирования стал ребром.
Давайте возьмем пример среднего Agile проекта. Работа идет по методологии Scrum, 4 разработчика, Scrum-мастер, Product Owner и тестировщик. Планирование, двухнедельные итерации, демонстрация результатов в конце каждой итерации. При этом, с инженерной стороны есть система сборок и набор тестов. Разработчики пишут модульные и интеграционные тесты, но до UI у них дела нет, мотивируя это тем, что тесты хрупкие и не дают быстрого результата.
Зачастую так продолжается до возникновения первых проблем. Самая типичная проблема – это поставка новой версии системы с дефектами. Когда клиент обнаруживает эти дефекты, команда задумывается, каким образом можно повысить качество продукта перед поставкой. Можно предположить несколько вариантов:
Для многих программистов может показаться очевидным первый вариант. Несомненно, качество конечного продукта будет повышаться, но риск пропустить ошибку останется. Попытки добиться 100% автоматизации тестирования закончится тем, что на написание тестов будет уходить слишком много времени разработки. Несложно догадаться, как команда решит избавиться от этой проблемы. В конечном итоге, все будут склонны к найму инженера, который будет заниматься тестированием продукта.
Примечание: На самом деле первый вариант и является правильным ответом, но мне кажется, что современные разработчики еще не научились поставлять код без дефектов. А получится это только тогда, когда программисты будут знать о тестировании не меньше самих тестировщиков! Замечательное виденье будущего тестирования описал Джеймс Виттакер в серии одноименных публикаций. Ознакомиться с переводом статьи можно по ссылке.
Второй вариант – привлечь клиента к тестированию выполненных задач. Это возможно для небольшого сегмента программного обеспечения – в тех проектах, где цена ошибки невысока и сама ошибка легко исправима. Время клиента стоит дорого, потому для него рациональнее нанять тестировщика, чтобы тот помог программистам в тестировании конечного продукта.
Все сводится к третьему варианту, когда принято решение привлечь к команде инженера по тестированию.
Здесь тоже не все так гладко. Большинство тестировщиков привыкли работать в традиционной среде, где тестирование – это отдельный этап и должен быть тщательно спланирован. На практике это выглядит следующим образом:
Применяя классический подход тестирования к Agile проекту, мы получаем мини-водопад внутри итерации и те самые проблемы, которые возникали и раньше:
В конечном счете, все сводится к тому, что тестировщик не справляется с объёмом задач, перед ним стоящим. Решить эту проблему команда пытается путем найма еще одного тестировщика, а затем еще одного. Но основная проблема остается нерешенной – это поддержка тестовой документации. В которую, зачастую, никто кроме самих тестировщиков не смотрит.
Мы зашли в тупик. Что делать в таком случае? Переходить на чеклисты, ментальные карты или внедрить еще какую-то практику?
Давайте для начала дадим ответы на несколько вопросов. Что самое интересное для тестировщика? Что приносит кайф в его работе? Да, именно – это сам процесс тестирования! Это процесс проверки, конфигурации, исследования приложения на ошибки.
Но не стоит забывать и об оптимизации расходов. Как при меньшем количестве тестировщиков добиться хорошего тестового покрытия? Как тестировать, когда времени между выпусками новой версии продукта очень мало?
Первая идея – это заниматься автоматизацией. Очень много воды утекло на эту тему, потому лучше вынести эту дискуссию в отдельную статью.
Вторая идея – научить тестировщиков работать больше. Использовать сильные стороны каждого тестировщика для достижения продуктивной работы всей команды. Оптимизировать процесс тестирования с использованием подходов, которые будут применимы в нужном контексте проекта.
Software Testing 2.0 – это не панацея и не открытие Америки. Это попытка систематизировать и направить развитие нового подхода в тестировании программного обеспечения, который позволит командам и тестировщикам в частности получить быстрые ответы на вопросы:
Это и многое другое я буду описывать в дальнейших публикациях на тему Software Testing 2.0. Мы будем говорить о разных моментах и историях из реальных проектов.
Следите за новостями в вашем городе, если хотите послушать эту информацию из первых уст. Жители Киева и Днепропетровска первыми смогут посетить серию докладов и тренингов на тему Software Testing 2.0 и смежным тематикам.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Последние две недели были сопряжены с большим количеством поездок в разные места, поэтому много чего было перечитано и пересмотрено. Представляю вашему вниманию очередной выпуск накопившегося “чтива”:
И порция полезного видео для просмотра:
Читайте и набирайтесь новых знаний!
В эту субботу, 9 июня, состоялась третья по счету бесплатная онлайн конференция IT Brunch. В этот раз она называлась “Учимся на чужих ошибках”. Тема выбрана не случайно. Ведь больше всего в IT мы делаем именно ошибок, к нашему большому сожалению. Причем, ошибок на всех этапах разработки программных продуктов – планировании, проектировании, выборе технологий, работе с заказчиком, тестировании и т.д. Наша индустрия славится количеством проваленных проектов, но при этом мы все равно не учимся на чужих ошибках и допускаем их снова в очередном проекте. А ведь гораздо лучше слушать про ошибки других людей, учиться на них и не допускать их в своей практике.
Я выступал с докладом “Коварный tracer bullet development”, в котором поведал историю одного проекта, где мы решили попробовать новый для нас подход к разработке – Tracer Bullet Development. Пересказывать содержание доклада не буду, вот слайдкаст выступления:
Есть еще видео вариант:
От участников поступило множество вопросов и я хотел бы еще раз ответить на них в этом обзоре. Если вы не успели задать свой вопрос или он у вас появился после прослушивания доклада, то поделитесь им в комментариях и я постараюсь ответить.
Вопрос: Как вышли из проблемы заглушек?
Ответ: Через некоторое время от заглушек отказались. Чем больше становилось логики, тем тяжелее было поддерживать заглушки в актуальном состоянии. На это тратилось слишком много усилий.
Вопрос: А писали ли тесты на функционал с заглушками? И не сложно было их рефакторить?
Ответ: В этом была одна из идей – можно писать тесты на заглушки, а потом прозрачно использовать их для интеграционного тестирования реальных сервисов. Сейчас я понимаю, что надо было больше времени уделить провайдерам данных, чтобы сами тесты вообще не пришлось менять. А так нужно было делать достаточно много изменений, чтобы они заработали с реальными сервисами.
Вопрос: А как насчёт жизни без тестировщиков? Ошибка или нет? 😉
Ответ: Нет, это не ошибка. Я считаю, что каждой команде было бы полезно поработать без тестировщиков, чтобы приучить себя выпускать продукт нормального качества, а не рассчитывать на тестирование. Многие технические вещи начинают делаться разработчиками, когда они понимают, что тестировать кроме них некому. Они стараются сделать это как можно проще и быстрее, автоматизируя свою работу. А заказчик начинает брать на себя больше ответственности за приемку функциональности. В общем, одни плюсы. 😉
Вопрос: Как убедить заказчика в “правильности” идеи небольших функциональных команд?
Ответ: Нужно показать ему преимущества: меньше времени тратится на коммуникацию, команды работают практически независимо, можно более гибко подходить к выбору функциональности для реализации, меньше риски в случае проблем с одной из команд и т.д. Рекомендую взглянуть также на методологию FDD (Feature Driven Development).
Вопрос: Как вышли к общей ответсвенности за продукт?
Ответ: Когда команда отвечает целиком за разработку функциональности, а не только части ее, которая скрыта за интерфейсом, то ответственность повышается. Некого обвинить, в конце итерации нужно показать результат.
Вопрос: Николай, получается использание заглушек оправдано на начальных этапах развития проекта? Когда на их поддержку не выделяется много ресурсов, а их использование позволяет полноценно вести разработку всех модулей?
Ответ: Именно так. Как только сервис начинает становиться сложнее, надо переключаться на реальную реализацию, иначе будет много времени тратиться на поддержку.
Вопрос: Как быть если есть много маленьких проектов?
Ответ: Небольшие функциональные команды работают замечательно и в этом случае. Делается конвейер задач, каждая из которых представляет собой законченную функцию системы. Команда берет ее на реализацию и делает. Управлять этим можно с помощью Kanban (как пример).
Все не было времени отчитаться о моем выступлении на конференции AgileBaseCamp Crew Drill. Это была для меня уже третья крупная конференция в мае (да, я уже немного задолбался ходить по конференциям). В Харькове 25-25 мая мы представили от XP Injection целых 4 доклада. Начну я со своих впечатлений:
– Ненавижу поезда, но в этот раз поездку скрасило распитие пива с Сашей Белецким и Сергеем Калинцом под беседы о различных поездках и путешествиях. Спасибо им за отличную компанию!
– Утренним завтраком очень порадовало IT Cafe. Это заведение работает круглосуточно и предлагает все, что нужно айтишнику: розетки, wifi, вкусный кофе и неплохую еду. Нам бы в Киев такое заведение – пользовалось бы большим спросом.
– Мне выпала возможность переночевать в новеньком 5-звездочном отеле Premier Palace с отличным сервисом, большими номерами, СПА и бассейном. Я был удивлен подобному уровню в Украине. В отеле можно было реально ощутить себя за границей. Я смог рано утром оставить вещи и отправиться завтракать.
– Порадовало небольшое число участников конференции. От этого она получилась какой-то уютной и домашней, wifi работал стабильно и кофе с круассанами хватало на всех.
– Увидел много знакомых лиц из разных городов Украины, с некоторыми развиртуализировался. Общение – это одно из преимуществ конференций.
– Не было раздаточных материалов, только программа конференции, поэтому конференция прошла под статусом “зеленой”. 🙂
– Неплохие залы с удобными мягкими стульями, хороший звук и микрофоны. А вот проекторы явно были не готовы к такой нагрузке – под вечер картинка начала моргать. Они просто не предназначены для беспрерывной работы.
– Еда на обеде заставила вспомнить студенческие годы – пюрешка, курица в панировке и свекла. Зато всем хватило.
– Самым ярким впечатлением стало after-party. На него собралось очень много людей (по моим личным ощущениям около 50 человек). Вкусное пиво, хорошая шумная компания, интересные обсуждения и споры – что еще нужно для классного завершения дня?
– Я принял участие в конкурсе по скоростному выпиванию пива, заняв почетное второе место с результатом 12 секунд. Это было реально сложно после трех бокалов пива и большого стейка. Жду видеозапись, чтобы поработать над ошибками. 😉
– Пивом вечер не закончился и уже небольшой компанией мы “сражались” с отрядом “зеленых мексиканцев”. Разошлись уже поздно ночью. Еще раз порадовался за выбор отеля – до него было 2 минуты пешком.
– “Зеленые мексиканцы” дали знать о себе утром, поэтому выбраться на второй день конференции получилось только к обеду. По дороге заехал в офис компании TeamDev, где еще раз выступил со своим докладом Continuous Delivery. Спасибо ребятам за гостеприимство – буду рад приехать еще.
– Второй день закончился очень быстро и мы уже маленькой компанией снова отправились в паб на after-party. Снова получилось очень здорово – столько интересных идей, историй из личного опыта, обсуждений всего и вся. Но только гораздо спокойнее чем в первый день. 🙂
– Узнал как можно забавно “проучить” разработчиков, которые не лочат свой компьютер, отлучаясь с рабочего места. Много фантазировали на эту тему и придумали очень крутые решения. 🙂
– На обратной дороге мы с Серегой ехали в одном вагоне с Артемом Сердюком. Долго спорили на темы стартапов и профессионализма, успешности проектов и возможности их развития на голом энтузиазме. Было интересно.
Что мне запомнилось из докладов? Очень порадовал своими выступлениями Тим Евграшин. Он провел воркшоп на тему применения Kanban. Это была интересная игровая симуляция, в ходе которой участники на себе испытали минусы некоторых традиционных подходов и увидели как Kanban может помочь в решении реальных проблем. Практично и весело! Второе выступление было посвящено методикам оценок в Agile. Тим на практике продемонстрировал преимущества групповых относительных оценок. Причем, слушатели активно участвовали в докладе, что помогало лучше понять идею доклада.
Дима Ефименко сделал экскурс в военную историю и осветил успешные подходы в армии разных стран и эпох. Было интересно узнать что-то новое из далеких от IT областей. Сергей Калинец разложил по полочкам что и как не работает у людей в реальной жизни при применении TDD. Для меня не ново, но очень полезно для большинства разработчиков. Анатолий Колесник поделился своим опытом проведения собеседований – ярко, увлеченно и полезно. Все мы когда-то проходили собеседование и не последний раз, поэтому этот доклад будет полезен всем. Кирилл Климов рассказал о еще одном подходе к оценкам в Agile проектах, доступно и лаконично. Доклад был небольшой, но полезный.
Во второй день мне запомнились доклады Нади Земсковой, Антона Зотина и Артема Сердюка. Надя поделилась своим большим опытом работы в распределенных командах. В такой среде можно допустить много ошибок, которые не позволят работать нормально ни одной стороне. Если вы собираетесь работать в подобном проекте, обязательно посмотрите этот доклад. Антон рассказал об успешном опыте применения Scrum в одном из своих проектов. Яркие слайды, живой доклад и простые действенные идеи – вот чем мне понравился этот доклад. Артем поднял очень интересную тему разных типов заказчиков и команд. Если цели команды и заказчика расходятся, то успеха не жди. Артем убедился в этом на собственном опыте. На нашем рынке аутсорсинга проблема стоит особенно остро, потому что многие берутся за проекты, заведомо им не приносящие удовлетворения от работы, а потом из-за недостаточного профессионализма страдают обе стороны. В общем, тема очень интересная для дискуссий и споров.
Я на конференции выступил с докладом “Continuous Delivery”. Пересказывать содержание не хочу, для этого есть слайдкаст:
Поездкой я остался доволен. Спасибо организаторам и всем участникам за интересное и плодотворное общение!
