Кто я? Где мое место? или место тестирования в гибких командах разработки

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

Начну с того, что при работе в команде периодически (читаем постоянно) с тестированием вылетаю за сроки наших итераций. Данный факт меня задевает достаточно сильно. Я нормальный человек и при работе в команде не хочу, что бы я был виной в наших «проигрышах».

Задался вопросами, что делать и как все исправить? На мой взгляд, два вполне разумных вопроса. Логично было начать с прочтения книжек, но я начал с google. Побродив по ссылкам, начитался много разных мнений и проблем, которые возникают при тестировании в командах, работающих по agile. В итоге стало более не понятно что делать и что пробовать, но практически все ответы говорили об одной идеи. Первый раз тестирование проводится за счет ручных тестов с описанием тест-кейсов или чек-листов, а дальше все по максимуму переносят в автоматизацию (читаем как написание еще одной программы). Данный подход итогом начинает экономить время тестировщиков затрачиваемое на тестирование и позволяет более надежно развивать разрабатываемый продукт. Вот и ответ. НО! Что делать если автоматизировать либо сложно либо очень трудозатратно? Что делать в этом случае?

Мне повезло. Во время перебора ссылок в интернете наткнулся на книгу Хенрика Книберга «Scrum и XP: заметки с передовой» . Увидев ее, я вспомнил, что ее уже читал, но вот до момента тестирование не дочитал, что-то меня в свое время отвлекло.  Значит, время настало. Каково мое удивление было, что и там, в начале описывается, что тестирование в agile командах один из сложных вопросов. Стоит сказать, что в agile кругах не особо принято делать наставления как бороться с проблемами, поскольку сама идеология agile сводиться к тому, что есть общая идея а дальше надо что-то делать что бы ее достигать при этом нельзя давить и указывать что делать тем кто достигает цель, поскольку можно их сбить с верного и ни кому не известного пути. Х. Книберг же «считерил» в своей книге. Он не описывал, как надо делать, он описывал, как сам поступал при решении этих проблем во время их возникновения.

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

В тоже время Х. Книберг дает ответ на вопрос что можно сделать, что бы повысить качество разрабатываемого кода?

Первый ответ для меня прост и сложен одновременно. Х. Книберг предлагает включить в команду человека специализирующегося на тестирование. Почему для меня этот вопрос прост. Я по своей сути и являюсь таким специализированным человеком в Scrum-команде. Почему этот вопрос для меня сложен. Ответ на вопрос что делать, что бы успевать я так и не знаю. Хотя теперь точно знаю, чем заниматься в начале каждой итерации (но если не кривить душой не так уж и часто у меня получается сидеть без дела в начале наших итераций). Самая интересная мысль в этом подходе, что в конце каждой итерации, если правильно подготовить почву для тестирования, в тестировщиков можно превратить практически всю команду. Для этого, наверное, и надо вести документирование тестов в командах, где тестировщик один.

Второй подход, который предлагает Х. Книберг, заключается в сокращение работы, которую необходимо брать на итерацию. Данный подход вполне разумен, поскольку, чем меньше работы на итерации, тем больше времени можно потратить на выполнение одной задачи. С одной стороны данное утверждение смотрится абсурдным, как можно успевать, тратя больше времени? Но если капнуть глубже в сути вопроса, то становится понятно, что чем больше времени будет разработчик тратить на выполнение одной задачи, тем меньше времени он будет тратить на ее последующую доработку по причине наличия ошибок.

Возникающие неудобства в команде при попадании на доску новых критических багов в начале каждой итерации (у меня как-то спросили, а почему они вдруг возникают? Интересный вопрос, пока еще не думал) можно устранить тем, что в каждую итерацию целенаправленно будет закладыватся время на устранение этих багов, тогда автоматически будем сокращать количество задач направленных на новый функционал. Данный подход позволить нормализовать работу с «горящими» задачами и повысить качество результата.

Вот такие мысли были получены у меня во время самостоятельного поиска ответов на поставленные вопросы.

Но на этом мои изыскания не закончились. На прошлой недели была возможность пообщаться с коллегами по Клубу директоров разработки. Точнее так. В четверг состоялось третье заседание Клуба директоров по разработки и тестирования. Темой данной заседания было «Как эффективно и качественно разрабатывать ПО: использование формальных или гибких (agile) методов разработки». Данная встреча стала удобным моментом, что бы задать каверзные вопросы коллегам. К сожалению, «золотого» рецепта для решения проблем тестирования в agile-командах ни у кого не оказалось, да оно и понятно. Его и не может быть. НО. Пообщавшись с Асхатом Уразбаевым (Agile - тренер, ScrumTrek) и Владимиром Туровцевым (директор по производству, Sitroncs) получил от них один ценный практический совет. Для нормализации работ в итерации на каждую фичу заранее закладывать дополнительное время на устранение багов. Данный подход очень хорошо коррелирует с тем, что предлагал Х. Книберг в своей книге, что однозначно говорит о эффективности данной практики.

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

На этой ноте я и закончу свое повествование.