Отправляет email-рассылки с помощью сервиса Sendsay

Разработка проектов и управление командой разработчиков

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Больше денег от Вашего бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Декабрь 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Александр Левитас

Статистика

2.032 подписчиков
-1 за неделю
←   Все выпуски   →

Разработка проектов и управление командой разработчиков


Информационный Канал Subscribe.Ru

Программисты против насекомых (bugz).

 

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

 

В этой статье я опишу, как мы боролись с «жуками» (bugs), в отличие от предыдущих статей, где упор был сделан на разработку ПО.

 

Дело тестировщика само по себе не хитрое: поиск и описание багов, но тут возникают вопросы:

-         как найти баг;

-         если что-то найдено, то как идентифицировать баг это или нет;

-         определил что баг, а как его теперь описать;

-         куда описание надо заносить, что бы его могли прочесть, а не проигнорировали.

 

Сейчас рассмотрим все по порядку и начнем с того, как найти баг. Здесь можно разделить задачу на две части. Первая: как сделать описание проекта так, что бы тестировщик по нему мог определить, где и как искать баги. Вторая: как из человека сделать тестировщика.

 

На счет грамотного описания проекта вроде все понятно: чем больше деталей на нормальном человеческом языке описано (и желательно с картинками – все люди любят, когда картинки встречаются в описании, – то бишь экранные формы приложения), тем  лучше для вас как менеджеру проекта и проще QA отделу. Ежели вы поленились сделать спецификацию, что норма для большинства потенциально мертвых проектов, то читай пункт 2.

 

Пункт 2. Как из человека сделать тестировщика.

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

 

Я заметил одну особенность. Ну не то что бы особенность, но все-таки, если человек хочет быть, например тестировщиком, то он им станет, не зависимо от того был он на курсах по подготовке тестировщиков или нет. Т.е. это к тому, что напрягать, тормошить курсами, угрожать народу бесполезно. Если человек работает плохо, то пусть лучше работает у конкурентов. Держать и сюсюкаться с такими людьми не стоит. Это правило относится и к программистам тоже.

 

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

 

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

 

Накала страстей может и не быть если пассивные тестировщики будут тихонько себе накапливать баги и не тормошить разработчиков. И потом будет большой «БУМ», когда в конце сдачи проекта нерадивый менеджер проекта увидит кучу багов, огромные безнадежно уставшие глаза программистов  и на фоне всего этого ликующую улыбку на лице тестировщиков типа «доигрались! А я ведь свою работу сделал».

 

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

 

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

 

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

 

Плавно переходим к правильному описанию багов. Здесь тоже все просто, но каких усилий стоит заставить себя и людей руководствоваться описанием из 3-х пунктов:

-         описание ошибки (что собственно получили в результате действий);

-         шаги, которые привели к ошибке;

-         что собственно ожидалось получить.

 

Когда смотришь на описание ошибок или претензий от клиентов, то сознание, просто отключается и не знает, что делать: то ли хохотать, то ли реветь. Но зачастую описание ошибки сводится к предложению «у меня не работает то-то» или еще лучше «ваша программа у меня не работает». Где, что не работает и как повторить, – а в ответ тишина ....

 

Если рассмотреть эти 3-и простых усилия более детально, то вот что получается.

 

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

 

Описание шагов, которые привели к ошибке помогают разработчику воспроизвести ошибку. Нет шагов, нет и исправления.

 

Ну и последний пункт «что собственно ожидалось получить». Это тоже важный пункт, так как ожидаемое это не всегда правильный функционал. На счет того, что правильно, а что нет в проекте это уже претензии к менеджеру проекта и камни кидать нужно именно в него. Плохо когда ожидаемая функциональность берется тестировщиком из головы, а не из документации.

 

Ну, вот и последний из вопросов «куда все это дело с багами сохранять». Перед тем как выдать готовое решение немного предыстории.

 

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

 

Работали тогда удаленно и по домам и первым решением было использовать Excel файлы.

 

Надо сказать, что намучались мы с ними вдоль и поперек с рассылкой и синхронизацией. Результата это не дало.

 

Трудности нас не остановили и вот через некоторое время покупаем Test Track Pro. Гигантская не изученная система, но ее впихнули в процесс. Недовольных было много: новая система, надо заполнять много форм, всего сразу не видно, работает медленно через инет и т.д.. Чем все это закончилось не знаю.

 

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

 

На выручку пришел продукт Джоела Спольски FogBUGZ – простой, удобный, быстрый и дешевый. Все было решено – попробовали на тестовом периоде и купили. Через год все проекты уже переведены под FogBUGZ.

 

Но не сиделось на месте уже изрядно повзрослевшей команде тестировщиков, и решили они усложнить себе жизнь и поставить Test Director. Ну что ж. Усложнили и поставили. Жить стало тяжелей, но не только тестировщикам, но и разработчикам.

 

Система Test Director оказалась сложной в настройке, тормозной и универсальной. Для планирования и проведения процесса тестирования она просто мечта, но для разработчиков она очень не удобна и наши ребята ее сильно раскритиковали. Клиентов решили в нее не пускать.

 

Однако мы не растерялись и силой воли решили:

-         FogBUGZ используем для ведения реквестов к проектам;

-         Test Director используем для планирования тестовых сценариев и проведения тестирования.

 

Ну, вроде бы помирились с тестировщиками приняв такое решение, но до конца еще не известно приживется ли эта мощная и не удобная система Test Director у нас.

 

Вот таким вот образом наладили у себя мы процесс тестирования.

 

Как постскриптум надо сказать, что FogBUGZ – отличная система для небольших и средних проектов, в частности для планирования задач и тестирования проектов. А Test Director – это мощная специально заточенная система для тестирования и планирования тестирования, и разрабатывали ее, похоже, по наводке тестировщиков, всячески игнорируя пожелания программистов.

 

Будут другие мнения пишите.

 

 

Успехов. Пока!

 

Сергей Перегуд

Prj_management@list.ru

http://onlive.nm.ru

 

О, да, С НАСТУПАЮЩИМ!!!

 

И еще. Огромное спасибо Наталье из службы subscribe, за то, что не дала мне окончательно уйти с головой в дела и забыть о рассылке. Наталья, жду Вашего содействия ;). Успехов!

 

 

http://subscribe.ru/
http://subscribe.ru/feedback/		 Подписан адрес:
Код этой рассылки: comp.soft.prog.prjmanagement		 Отписаться
В избранное