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

[EugeneL]

Здравствуйте.

Недавно попал в не очень обычную ситуацию, хотелось бы услышать мнение многоуважаемого сообщества.

 

В общем, работаю на небольшом проекте (10 человек) в небольшой фирме (150 человек). На моем проекте занимаюсь автоматизированным тестированием, дела, в общем, идут неплохо, Заказчик хвалит, чему подтверждением являются регулярные бонусы мне (и, естественно, моим подчиненным).

 

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

 

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

1. Тестировщика на проекте "Утопающий" нет. Его появление во многом зависит от моей активности

2. Проекту "Утопающий" мне надо будет уделить неделю своего времени в качестве консультанта по процессам обеспечения качества. В будущем предполагается, что я буду периодически возвращаться к проекту, но не надолго (день-два ежемесячно)

3. Принимая во внимание то, что я не имею возможности работать фуллтайм, мне обещают оказывать содействие и стараться следовать моим рекомендациям.

 

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

Я тестирую ПО уже достаточно давно: 4 года как автоматизатор, и лет 6 до этого как разработчик 1с. Что и для чего делать я примерно знаю, но каких-либо готовых рецептов у меня нет, а время неумолимо идет к дедлайну. Быть может, Вы бы мне смогли помочь получше сформулировать методы решения таких задач:

 

1. Есть ли у Вас опыт решения подобных задач? Можете ли поделиться know-how? Стоит ли прочитать какую-либо литературу по этому поводу?

2. Принимая во внимание то, что я располагаю очень сжатым временным интервалом, как лучше организовать подачу материала?

3. Как лучше выстроить процесс, чтобы он работал в тот момент, когда закончится эта моя неделя?

4. Какие могут быть "подводные камни" или трудности?

5. В какой форме лучше сохранить результаты такого спонтанного аудита?

6. Что лучше сделать, чтобы аудит был не спонтанным, а преследовал конкретную цель?

 

Заранее большое спасибо

[Сергей]

Постою, послушаю... Волшебное руководство, однако. Опыт был... Хм, Вам надо донести основную идею, что качество - это не спонтанный процесс, и уж никак не перед дедлайном. Смахивает на стандартную ситуацию, метод прикрывания Ж.

[Freiman]

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

 

1. Есть ли у Вас опыт решения подобных задач? Можете ли поделиться know-how? Стоит ли прочитать какую-либо литературу по этому поводу?

 

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

Читать - Рекс Блэк. Ключевые процессы тестирования

 

2. Принимая во внимание то, что я располагаю очень сжатым временным интервалом, как лучше организовать подачу материала?

 

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

 

3. Как лучше выстроить процесс, чтобы он работал в тот момент, когда закончится эта моя неделя?

Никак. За неделю вы не успеете.

 

4. Какие могут быть "подводные камни" или трудности?

Программисты не хотят, менеджеры не могут. Вы ответственный, вы и делайте :)

Проблем может быть очень много разных. 

 

5. В какой форме лучше сохранить результаты такого спонтанного аудита?

Проблема - причина - решение.

 

6. Что лучше сделать, чтобы аудит был не спонтанным, а преследовал конкретную цель?

1. Узнаем, на что именно жалуется заказчик. Проблемы с качеством могут быть совершенно разные.

2. Самостоятельно выясняем, какие еще проблемы есть на проекте.

3. Предлагаем наиболее быстрые решения для п. 1

4. Предлагаем наиболее эффективные, на ваш взгляд, решения проблем из п. 2

 

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

 

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

[EugeneL]

Freiman, спасибо, начну копать в этом направлении.  Пока, кратко, о чем удалось договориться с руководителем проекта:

1. Тестирование -- это непрерывный процесс. Инвестировать время однократно, и получать результат именно этой конкретной инвестици на протяжении длительного временного периода не получится, т.к. в итоге придем к исходной ситуации.

2. В тестирование надо инвестировать достаточно много времени. В среднем, 30% от времени, требуемую на разработку продукта.

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

4. Тестирование -- это не просто кликание мышкой, а осознанный процесс направленный на конкретный результат. Составление различной документации и составление отчетов об ошибках -- неотъемлемые части проекта. Поэтому, нельзя сказать "тестируй быстрее, а степы в экселе через месяцок набросаешь".

5. Чтобы результат был стабильным, им нужен тестировшик в штате (а не один специалист на неделю разово, а потом -- раз в месяц на несколько дней). В порядке быстрого старта, можно нанять одного тестировщика, чтобы примерно увидеть, по какой траектории пойдет проект. Если проект пойдет по нужной траектории, нанять столько тестировщиков, сколько необходимо. Правда, здесь есть риск, что для Избранного это может оказаться непосильной задачей.

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

[Freiman]

По 4 пункту: документации должен быть необходимый минимум. Это, на самом деле, очень затратный в плане времени процесс, и тратить время на малополезные действия не стоит.

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

 

По 6 пункту: + когда у нас есть свободные ресурсы на автоматизацию. На нее надо будет выделять отдельного человека и она принесет осязаемый результат весьма нескоро.