Сообщений в теме: 25

[Валера]

Мы достаточно долго (1,5 лет) практикуем объединенные группы программистов и тестировщиков. Подробнее: над одним проектом работает несколько групп, в каждой группе 5-7 человек. В группу входят и программисты и тестировщики. Члены группы сидят в одной комнате, интенсивно общаются и несут коллективную ответственность за результат. Используется Bug tracking system (ClearQuest).

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

[Case]

Уважаемый мной за отличные статьи Джоель (Joel on Software)
в статье "Огонь и движение" подробно описывает почему изложенная картина, когда разработчики сидят в одном помещении (тем более если там и тестировщики и оживлённое общение), только вредит разработке.

Я за разделение териториально. У нас соседние комнаты (правда у ребят-разработчиков сейчас тесновато, но руковдство уже оговорило сроки расширения)
Обьединяться можно во время митингов, штурмов, совещаний.

[Олешка]

Валера, а как организован контроль за версиями? Есть ли процедура передачи версии на тестирование, процедура получения отчета от тестировщиков по версии?

[OlegSh]

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

Поскольку традиционно тестировщиков выделяют в отдельную орг единицу

Не совсем понятно, что под этим подразумевается - то ли это про обязанности, то ли про зарплату :-), то ли про все сразу ...

[Валера]

> Олешка
все исходники живут в Visual SourseSafe. Билд для всех групп общий, дата и время билда предопределены (2 раза в неделю при разработке, каждый день при стабилизации). Тестируется всегда последний билд. Можно собрать внеплановый билд, если нужно. Ошибки фиксируются в BTS, результаты тестов (пройден / непройден) фиксируются пока в файлах.
Таким образом получается непрерывный ритмичный и предсказуемый для всех процесс.

[Валера]

Ответы на замечания

1) Шум
На практике не шумно. если нужно люди подходят друг к другу и общаются в полголоса. Когда кто-то хочет сделать broadcast (важный для всех вопрос) он(а) просто говорит громко. А общаться нужно обязательно, без этого основной деятельностью фирмы будет исправление недопонятостей. Конечно аська хорошо и мы активно ее внутри используем, но часто нужно вдвоем смотреть на один код / рисунок / экран приложения.
2) Зачем программисты и тестировщики вместе
Разные специализации порождают разный взгляд на вещи, который проявляется в спектре от непонимания до антогонизма. Организационная структура призвана этому активно противодействовать. Основной практический результат укорочение жизни бага (нашли - зарегистрировали - назначили - исправили - проверили) с 5-8 дней до 1-3 дней.
3) Зачем делиьь команду на группы
Группа больше 6-8 человек все равно распадется на подгруппы. Поэтому лучше поделить явно.

[Олешка]

> Валера:

Если можно, пожалуйста, уточните следующие моменты:

1) С какой группой продуктов Вы работаете? Web сайты/Windows приложения/UNIX или что-то другое? Есть ли там серверная часть? Если да, то есть ли для тестировщиков отдельный сервер где не работают разработчики?

2) Тестируется ли инсталляция/delivery?

[Олешка]

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

[Олешка]

2) Зачем программисты и тестировщики вместе
Разные специализации порождают разный взгляд на вещи, который проявляется в спектре от непонимания до антогонизма. Организационная структура призвана этому активно противодействовать. Основной практический результат укорочение жизни бага (нашли - зарегистрировали - назначили - исправили - проверили) с 5-8 дней до 1-3 дней.

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

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

Расскажите, пожалуйста, как Вы связываете практический результат - время жизни бага - с использованием такой оргуструктуры?

[Mike]

Полностью согласен с ex_dani. Когда я работал тестировщиком, у нас было так же (тестировщики и программеры в одном здании, ещё часть программистов - в другом). И, кстати, жизненный цикл бага был не 7-8 дней, а (если баг серьёзный и легко исправимый) от 3 часов до 2-х-3-х дней. Грамотная система баг-трэкинга полностью покрывает все нужды общения тестировщиков с программистами. Кроме того, есть такая штука, как телефон ;). И ещё 30-40% вопросов решаются без программистов если ведущий тестировщик (QA Manager) - грамотный специалист, и хорошо разбирается в системе.

[Mike]

Mike можете пояснить вашу точку зрения?

Это не точка зрения, а личный опыт :) . Наш QA Manager как правило разрулилавала процентов 40 вопросов (вроде пинг-понга "Submit->Reject->ANew->Reject", правильности описания ошибок, из Importance и прочее, чем в других случаях пришлось бы заниматься программистам или Projectам.). В общем, по моим наблюдениям, хороший QA Manager сильно "оптимизирует" общение программистов и тестировщиков, беря его (общение) на себя. Он как-бы служит буффером между тестерами и программистами, помогая избегать конфликтов (кроме всего прочего).

[Case]

Основной практический результат укорочение жизни бага (нашли - зарегистрировали - назначили - исправили - проверили) с 5-8 дней до 1-3 дней.

:unsure: Не понял... на исправление одного бага нужно до 3 дней? Зачем так много?

[Валера]

> Олешка
Ответы на вопросы

1) система автоматизации бизнес-процессов. долгосрочная разработка, тиражируемый продукт
2) инсталятор тестируем, но менее интенсивно, чем основной функционал

3) Насчет выделения тестировщиков в отдельную группу
гибкость такой команды, -- да есть такое преимущество
возможность быстрее переключить тестировщика с одного проекта на другой -- все равно часто дергать людей с задачи на заду вредно - потери времени на въезжание.
и выработка общего подхода к тестированию -- стремимся в технологических документах отразить

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

[Валера]

Время жизни бага и как его уменьшает единая команда:

должен пояснить что я имею в виду. Баг есть в программе до обнаружения, т.е. баг != запись в BTS. Мы условно считаем, что баг рождается в момент, когда он попадает в очередной билд, а умирает, когда его отсутствие проверил тестировщик.
Из каких основных кусков состоит жизнь бага:
1) от билда до обнаружения
2) от обнаружения до назначения (не рассматриваем ситуацию, когда баг отложен)
3) от назначения до исправления
4) от исправления до попадания исправления в билд
5) от попадания исправления в билд до проверки тестировщиком (не рассматриваем ситуацию, когда баг на самом деле не исправлен)

Теперь рассмотрим, как единая команда способствует уменьшению этого времени (у нас):
1) Программисты сообщают тестировщикам, что именно они "трогали", это резко сокращает время нахождения багов - тестировщик идет в нужное место (но никак не исключает сплошное регресионное тестирование).
2) никак
3) Тестовые наборы и автоматические тесты, сделанные тестировщиками используются программистами. Здорово помогает.
Еще на практике часто бывает полезно, чтобы тестирощик посмотрел на исправление бага сразу, до билда. В BTS всего не напишешь и хотя мы обеспечиваем программистам доступ к среде идентичной тестовой (полная копия тестовой БД) подсказка тестировщика часто помогает
4) вобщем не сильно, но во время стабилизации частенько по согласованию с тестировщиками собираются внеочередные билды
5) наверно никак

[Валера]

Время жизни бага (2)

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

Красиво ? Мне кажется да. Но вот для этого нужна глубокая интеграция тестировщика в процесс разработки.

Кстати, а у кого какая длительность жизни бага ? Тут наверно в выигрыше будут те, у кого daily build.

[Case]

Тестировщикам тогда останутся хитрые баги, для которых нужна интуиция и регрессионное тестирование.

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

Немного отвлекусь:
Мне, если чесно, очень не нравится какая-то романтизация любой профессии, что программиста, что тестировщика. И то и то профессия, которой просто нужно учится и оттачивать владение ею. "Интуиция", "структурное видение архитектуры и потенциальных уязвимостей", очень красивые слова, которые можно ввернуть в разговор и вставить в соответсвующий раздел резюме. Но не вяжется это у меня с понятием професионализм, никак.
Пример: сейчас я сяду со свежей головой за Ваше приложение, включу всю интуицию и через 5 минут выдам 2 бага и саджест по интерфейсу. Вы же просто глядя на приложение сможете наметить за пару минут несколько узких мест, включая логику (!) и за полчаса спокойной работы обоснуете разработчикам свои мысли. Ну и где моя интуиция окажется? Ваш опыт делает её как стоячую, верно?

Кстати, а у кого какая длительность жизни бага ? Тут наверно в выигрыше будут те, у кого daily build.

Тут вы совершенно правы. У нас ежедневный билд входит в разработку как только появляются первые строки кода. Даже пусть интерфейса нет и билдится 15 строчек кода - сам процесс билда должен быть налажен сразу. Чем ближе к выходу версии, тем больше билдов в день. Вчера их к примеру было только за вторую половину дня 8.
Время жизни бага определяется временем выхода следующего билда, в котором этот баг исправлен. (я не беру более глобальный подход, который предложили Вы, потому как для меня баг это - задокументированная и воспроизводимая ошибка, а не потенциально заложенная при разработке неточность)

И ещё чуток:

Программисты сообщают тестировщикам, что именно они "трогали"

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