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

[Mahmud]

Уважаемые посетители форума - есть ли здесь люди, которые формировали отдел тестирования с нуля? Хотелось бы побеседовать на данную тему: о структуре отдела, роли сотрудников данного отдела, документообороте, техническом обеспечении, управлении персоналом и т.д. Ведь это не простая задача, особенно для новичка, с удовольствием пообщался бы на данную тему с опытными людьми. Да и думаю, такие материалы будут полезны многим.

[Олешка]

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

Как мне кажется, если вы ответите на эти вопросы, и не обязательно в форум, структура отдела, роли его сотрудников и необходимость в техническом обеспечении прояснятся.

[Yarilo]

Привет!
Согласна с Олешкой, что нужно уточнить цели создания отдела.
Мы в своей компании пробовали создать отдел тестирования, но в конце концов мы его расформировали - как работали тестировщики по проектам так все и осталось :)

[Олешка]

Кстати, интересный момент по поводу расформирования отдела. Мы с ростом объемов пришли немного к другому решению. Внутри отдела есть группы, работающие на конкретный проект. Состав групп может меняться за счет перемещения тестировщиков между проектами. И есть одна служебная группа, состав которой вообще произволен и меняется от 0 до 10 человек, в зависимости от загрузки текущими релизами. Там смотрят разные тулзы, технологии, разрабатывают методику тестов, сверяются со стандартами.

[Mahmud]

2 Олешка: мне жутко понравилась организация вашего отдела тестирования. если это не секрет, какова численность сотрудников в этом отделе? :) я прикинул, это как минимум человек 10 нужно :)

[Олешка]

Столько и есть.

[Case]

Мне доводилось создавать с нуля отдел (практически постоянно этим и занимаюсь).

Сейчас в силу причин которые перечислю ниже у нас одна команда тестеров работает по всем проектам. Иногда всем тимом, иногда разбиваемся - в зависимости от приоритетности задач и общего объёма работ.

А почему так: есть несколько команд разработки - некоторые работают по XP, некоторые по чему-то, что напоминает RUP (по-крайней мере по графикам времени уделяемого тестированию на разных стадиях разработки). По ХР тестировщики должны быть на уровне заказчика погружены в задачу и выступать в роли источника информации для самих девелоперов, они же должны составлять (автоматизировать) приёмочные тесты. Выделить кого-то из команды (а по сути даже не одного а нескольких на ХР) я не могу - объём работ не позволит, приходится работать над всеми проектами вместе.

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

Кроме того, что взял из ХР и пока очень доволен:
- Парная работа при сотставлении чек-листов. Потрясные результаты - из довольно таки скучноватой работы получается довольно результативный и нескучный процес.
- Парное тестирование - буквально ПАРНОЕ - две пары глаз в монитор, один периодически отмечает в чек листе и выполняет фукнции штурмана, я бы тоже рекоммендовал попробовать. Я очень доволен, сам с удовольствием работаю в паре.

Исследованием новых тулов или технологий занимаюсь сам - очень время от времени (времени просто нет) - это огромный минус с которым сейчас воюем.

[Mahmud]

2 Case & Олешка: большое спасибо за ответы!

[Натали]

Тоже хочу сказать спасибо за ответы.
Одно "но" -они все помогают в случае, если раньше тестировщики были, не было спец. отдела.
А если тестировщиков не было?
Мне сейчас как раз и приходится формировать отдел с нуля, вернее не сколько формировать отдел, сколько определять свое место в компании (весь отдел - пока я одна).
Соответственно у меня возникает масса вопросов - начиная от выбора средств обработки и сохранения ошибок и заканчивая механизмом начисления премии.
И иногда я просто теряюсь - как охватить весь объем.
Может существует какая-нить справочная информация?
Или просто советы - ведь тут не просто перераспределение ролей, а ввод чего-то совсем нового...

[barancev]

Про организацию процесса тестирования есть, насколько мне известно, только одна приличная книжка - Automated Software Testing by Dustin, Rashka and Paul. Она даже переведена на русский язык, но перевод такой, что я всё таки советую использовать оригинал, если есть такая возможность.

[Олешка]

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

1. Вопросы, связанные собственно с тестированием - методологии, выбор инструментов, разработка процедуры тестирования. Хотя бы минимально, на уровне - что на входе в процесс тестирования, что на выходе. Например, так: на входе - спецификации+продукт+сопровождающая документация, на выходе - тестовые планы, отчеты о проблемах. Составить бумааажку по процедуре.

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

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

4. Вопросы приоритетов и разделения задач между тестировщиками - если тестировщик не один.

Ну вот, пока писала, и Баранцев ответил. :) Есть и еще, тот же Сэм Канер, "Тестирование программного обеспечения", а также - "Быстрое тестирование", авторы - Роберт Калбертсон, Крис Браун и Гэри Кобб. Есть на русском языке. ISBN 5-8459-0336-X (рус.)

[Натали]

Я наверное неправильно написала.
Небольшой опыт тестирования(год) у меня есть. Есть и опыт использования того же самого ClearOuest'а и части других продуктов Rational.
Меня интересуют в большей степени административные проблемы и их решения.

[Олешка]

Эти проблемы могут быть у всех разные. Можно конкретнее вопрос сформулировать?

[Guriy]

Кроме того, что взял из ХР и пока очень доволен:
- Парная работа при сотставлении чек-листов. Потрясные результаты - из довольно таки скучноватой работы получается довольно результативный и нескучный процес.
- Парное тестирование - буквально ПАРНОЕ - две пары глаз в монитор, один периодически отмечает в чек листе и выполняет фукнции штурмана, я бы тоже рекоммендовал попробовать. Я очень доволен, сам с удовольствием работаю в паре.

Нет, ну какая общность мысли :)

Я сейчас как раз хочу сделать что-то подобное, но руки пока-что не дошли :)

[Case]

Я уже анонсировал но на всякий случай повторюсб - я тут некоторые мысли на этот счёт изложил в виде статьи:

«Парное тестирование — возьмём от ХР лучшее»
http://tester.com.ua...are_testing.htm

[Натали]

Эти проблемы могут быть у всех разные. Можно конкретнее вопрос сформулировать?

Начала формулировать, и поняла, что на данный момент непреодолимая проблема одна - как формализировать оценку моей деятельности, в основном в финансовом смысле.
:)

[Guriy]

Эти проблемы могут быть у всех разные. Можно конкретнее вопрос сформулировать?

Начала формулировать, и поняла, что на данный момент непреодолимая проблема одна - как формализировать оценку моей деятельности, в основном в финансовом смысле.
:)

lol

Уменьшение затрат на разработку, путем более раннего нахождения дефектов в ПО.

:D

[Spy]

как формализировать оценку моей деятельности, в основном в финансовом смысле. :)

Что-то подобное сечас у меня. Только мне нужно иницировать проект.

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

А потом с этой чудо бамажкой к руководству, об успехах поделимся! ;)

[Viktor]

Начала формулировать, и поняла, что на данный момент непреодолимая проблема одна - как формализировать оценку моей деятельности, в основном в финансовом смысле.
:)

Предостерегу Вас от попытки формализовать работу новой группы,
Лучше поработать, освоиться, обучить персонал, наладить процессы, а затем сами увидите, по каким критериям можно и лучше оценивать, отсекете лишнее, оптимизируете процессы. Иначе Вы можете свести на "нет" все результаты. В таком духе и нужно настраивать руководство :) на выделение средств.

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

[Натали]

Spy, жду сообщений о ваших успехах. Качественные характеристики я худо-бедно описала, и что изменится при появлении отдела тестирования - тоже. Вот количественные показатели - совершенно неизвестная область.

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