Моя презентация на SQA Days 2011 в Казани.

Презентация

View more presentations from Tatiana Zinchenko

Звука все жду и жду, чтобы сделать слайдкаст. Но неизвестно дождусь ли ))) Поэтому решила выложить слайды и текст выступления (для тех, кто на выступлении присутствовал, будет видно, что он примерно на процентов 30 отличается от того, что был). 

У кого-то из очень умных тестировщиков современности - уже не помню у кого точно, память-то девичья - услышала приятную фразу: “Почти все современные методологии разработки созданы программистами и для программистов. Они получают удовольствие и для них это работает”.

За качество цитаты не отвечаю. Опять же - давно это было. Но вот, например, программирование в парах - это круто. А парное тестирование? Где оно работает? Как оно работает и работает ли вообще? И действительно же - программисты оптимизируют свой процесс, а нам - тестировщикам - приходится следовать за их курсом. Ведь мы - одна команда, мы делаем одну систему, удовлетворяем одного заказчика, следовательно, и процесс у нас один на всех.

Но если разработчикам легче войти в процесс, то о “ловцах багов” задумываются реже. Например, в Agile-методологии можно работать вообще без тестировщиков. Теоретически.

За свою не такую уж и долгую карьеру тестировщика мне посчастливилось ощутить на себе прелести уже нескольких методологий. И очень хочу поделиться своим опытом в том, как все же подстроиться под методологию так, чтобы тестировщиков слушали и слышали, и в то же время не скатиться в печальное противостояние “мы” и “они”.

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

Итак.

“Тестирование в Agile: испытание методологией” - дело № 24-05.

Действие происходит на просторах Agile.

Досье:

Agile - не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Эта методология нацелена на минимизацию рисков путем сведения разработки к серии коротких циклов. Эти циклы называются итерациями и в большинстве случаев составляют одну-две недели (Википедия).

В 2011 году исполняется 10 лет с момента написания Agile-манифеста.

Существует множество методологий, которые следуют ценностям и принципам, заявленным в Agile. Наша команда использовала Scrum.

В методологии СКРАМ всего 3 роли:
- Скрам-мастер,
- Product Owner
- команда.

Кто такие “команда” и “Продакт Оунер”, надеюсь, понятно. А Скрам-мастер - это такой своеобразный буфер между командой и Product Owner, который отвечает за успех СКРАМ в проекте. Он ведет ежедневные планерки, освещает проблемы и отвечает за соблюдение командой практик и процесса.

Артефакты СКРАМ:

- Product Backlog - это имеющийся на данный момент список требований к системе.

- Спринт Bacкlog - это список тех фич, который команда взяла на спринт.

- Спринт - итерация длительностью от нескольких дней до одного месяца. Каждая итерация представляет собой маленький “водопад”. В конце итерации обычно происходит билд и есть что показывать заказчику.

- Ежедневный СКРАМ митинг - это ежедневная планерка, на которой каждый участник команды рассказывает что он делал вчера, что планирует делать сегодня и с какими трудностями столкнулся.

- Демо и ретро - это демонстрация фич, которые были сделаны в течение спринта, заказчику, и последующая ретроспектива того, что было на спринте. Команда рассказывает что она сделала, чего не смогла сделать, с какими трудностями столкнулась, как они решились, а если не решились, то что с ними делать в дальнейшем.

Место действия:

Современный офис в столице автономии.

Agile. Все работают.

Все - это отряд разработчиков и ПО (Product Owner).

 На момент создания QA-отдела действительно разработка шла уже полноценный год по Agile с использованием парного программирования, написание автоматизированных тестов на функционал, то есть изначально предполагалось, что всего этого вполне достаточно для написания качественного кода и, следовательно, для безбажной системы.

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

Почему программист не может тестировать свою фичу?

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

Вторая причина: у программистов мышление устроено немного иначе, чем у нас. Программист умеет думать логически, как программа. Мы умеем думать как блондинки. Программисту никогда не придет в голову покликать вот там 23 раза, а потом перейти сюда, покликать 15 раз, и тогда вот в том функционале через 3 клика будет бага.
У вас было такое, что вы приходите к разработчику, рассказываете ему каким образом вы получили эту багу, а он на вас смотрит и задает только один вопрос: “Зачем?”
Они искренне не понимают зачем делать так, если есть конкретный путь, который приводит к конкретным, НУЖНЫМ ТЕБЕ, результатам.

Но немногие разработчики отдают себе отчет в том, почему они не могут качественно протестировать свою же фичу. Как ни странно, даже некоторые тестировщики не понимают почему программист не может тестировать.

Если бы программисты умели еще и тестировать - нас бы не было! Мы были бы не нужны!

В общем, в определенный момент команда и руководство поняло, что “мы можем написать, но протестировать качественно мы не можем!” Так в команде появились тестировщики.

А через два месяца — релиз!

Тут стоит обратить внимание на еще один нюанс, весьма важный для рассмотрения нашего дела.

В Agile-командах нет тест-лидов. Нет того человека, за широкую тестерскую спину которого ты мог бы спрятаться, и который бы принимал решения за тебя, и отстаивал твои решения, если бы они были.

Методология гибкой разработки предусматривает, что команда — самоорганизующаяся.

При этом, есть скрам-мастер, который следит за процессом в целом. У разработчиков есть демон, который подготавливает и проводит демо, следит за тем, как разрабатывается фича и постоянно контактирует с ПО и девелопером. У разработчиков есть фичмен - человек, который берет на себя ответственность за подготовку какой-то конкретной фичи, притом, что разрабатывать ее могут несколько человек. У тестировщиков нет никого, кроме них самих.

Выяснилась и еще одна вещь. Проблема, которая известна многим. Тестирование стало узким местом всей работы.

Одна итерация длилась у нас 2 недели. Как вы думаете, сколько готовых для тестирования фич было в конце первой недели? А в конце второй?

Как результат: стало почти нормой, что на демо фича не попадает по причине того, что она не протестирована.

На тестировщиков обратили внимание и стали думать как вовлечь их в процесс наравне со разработчиками.

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

Так тестировщики стали оценивать фичи.

Кроме того, мы стали больше общаться с разработчиками. И это во многом помогло и нам, и им. Мы стали участвовать в этапе планирования фичи, т.е. еще до разработки делились с программистами своими идеями относительно тестовых случаев по фиче. Это помогла им: спланировать и написать сразу проще, чем потом искать куда приткнуть очередной тестовый случай. Это помогло нам: теперь мы реже ходили с вопросом: “А что, у нас не предусмотрен вариант с запуском двух процессов одновременно?”

Мы смогли внедрить нагрузочное тестирование: проанализировали инструменты, выбрали наиболее подходящий и - самое главное - убедили в том, что это нужно. Хотя нет, самое главное в том, что позже мы на практике показали, что были правы и что это действительно нужно.

Но и сам процесс тестирования начал контролироваться демоном. Разработчиком. Иногда это выглядело так: садится программист рядом с тестировщиком и говорит: “Ну, тестируй!”

Не знаю как кому, но вот лично мне сложно оценивать работу программистов. Я знаю, что они ТВОРЯТ, СОЗДАЮТ, ВАЯЮТ! А мы все это ковыряем, уничижаем и показываем дырки. Наверное, поэтому и программистам сложно оценивать нашу работу. Поэтому постепенно все начало приходить к тому, что тестировщики должны автоматизировать свой процесс: писать тесты на Селениуме, оптимизировать их, поддерживать, следить за результатом. То есть, им было проще контролировать нас тогда, когда мы делали то, что им знакомо и понятно. Мануальное тестирование задвигалось на второй план и было очень сложно убеждать в том, что не все поддается автоматизации, и что юнит-тесты, которые пишут программисты, уже являются автоматизированным тестированием.

Оставалась еще проблема очередей. Наверное, знакомо всем. Программист написал фичу, отдал ее на тестирование и со спокойной душой ушел делать другую. Или пить чай. Тут уже кому как повезет.

А ты находишь багу в этой, сданной фиче. И хорошо, если программист пьет чай и еще не вышел из контекста той фичи, что наваял. А если он - отчаянный трудяжка и уже начал ваять что-то еще? Тогда: “Подожди, сейчас я тут закончу и подойду”. Лично у меня рекорд - около 6 часов ожидания. Можно набрать на себя кучу фич за время такого ожидания. Но ведь проблема переключения с контекта на контекст актуальна и для тестировщика тоже.
А очередь стоит. И ждет.

И скоро конец спринта - разработчику надо успеть доваять новую фичу, тестировщику надо успеть доковырять старую. И где золотая середина?

Очень важно, чтобы руководство понимало проблемы тестировщиков. Очень просто, когда руководство тоже само когда-то занималось тестированием и прекрасно понимает твои проблемы. Подчас даже лучше, чем ты сам. Иногда ты даже не знаешь, что тебе это надо. А начальство уже за тебя подумало, придумало, решило и принесло.

Гораздо сложнее, когда руководство - разработчик. Еще сложнее - если оно никогда не сталкивалось с тестировщиками.

Как донести до начальства, что то, что тебе нужно - действительно важно?
Самое главное - как донести до него что-то ДО первых набитых шишек и случайно вырвавшегося: “Я же говорила”?

Тогда мы услышали про Канбан. Но это уже совсем другая история.

И напоследок....:

Не пытайтесь выяснить кто круче: тестировщики или программисты. Мы - единая команда. Мы делаем один продукт, мы - заодно, а не против друг друга.

У меня был опыт работы в компании, где программист мог прийти и запросто спросить: “Ну, что там еще эти тестеры сломали?!”, а тестировщики между собой могли обсмеять программиста, пишущего код с большим количеством багов.

Такого не должно быть. Мы не ломаем, мы помогаем найти слабые места! Мы все люди, мы все ошибаемся: ошибаются программисты, ошибаются тестировщики, ошибаются менеджеры и директора.

Не пытайтесь “переждать грозу”. Не нужно прятаться за спинами тим-лидов или товарищей-тестировщиков, если есть проблема, требующая решения. Если вы ее не решите так, как нужно вам, ее решат за вас и не факт, что вам понравится такое решение.

Как начинать с нуля, если Вы пришли на уже готовый проект с устоявшимся механизмом разработки? Многие предлагают начать с изучения документации. А если нет еще ничего? Я обычно начинаю с вопроса: “А на кого рассчитана наша система? Что она должна делать?” Согласитесь, сайт для домохозяек и система для веб-мастеров должны различаться. После этого провожу исследовательское тестирование, в ходе которого обычно сразу видны основные слабые места, а также какие виды тестирования пригодятся в дальнейшем.

Если у вас появилась идея - не стесняйтесь ее высказывать и предлагать ее реализацию. НО! Прежде чем ее предложить, вы должны изучить все нюансы, быть готовым к любым вопросам. Вы должны не просто прийти и сказать: “Я думаю, нам нужно тестирование безопасности внедрить. Это круто, я прочитал на форуме”. Вы должны прийти и сказать: “Я прочитал на форуме про тестирование безопасности. Потом прочитал еще в блогах и пришел к выводу, что нам оно нужно. Во-первых, наша система работает с финансами, во вторых, с большим количеством данных пользователей, в-третьих, еще чего-то там. А еще я проанализировал вопрос и пришел к выводу, что мы можем использовать вот такие инструменты тестирования”.

Любите свою команду. И тогда она полюбит вас. Или нет. Но тогда ей же хуже.

Спасибо за внимание!