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

[saezar]

Собственно сабж. Ясно, что ответ на такой вопрос будет столь же пространным сколь бесполезным. Потому, немного о сути.
Вот впринципе, из чего может состоять процесс создания отдела тестирования с нуля?
Я так понимаю, что надо выполнить несколько подготовительных этапов:
1. Создать формальную (читай финансовую) основу для создания отдела.
2. Найти (нанять, подготовить, обучить, ввести в курс дела) персонал.
3. Подготовить материальную базу - компы, столы, тестовые машины и сервера, оборудование, отвертки, паяльники...
4. Подготовить нормативную базу - кто кому начальник, кто кому подчиняется, выпустить положение об отделе, короче
5. Подготовка обеспечения работ - расписать процесс и поток документов.

Что ещё? Ощущение, что этого явно недостаточно. Но чего? В голову не идёт.

[astenix]

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

[saezar]

Издеваетесь. :/

[Green]

Коллеги,

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

Когда мы говорим об организации тестирования в проекте, то речь идет о технологической составляющей. У нас есть задача, план, ресурсы, объем финансирования. И, в перспективе проекта, все достаточно понятно. Вот объем задач, вот ресурсы под задачи, вот механизмы управления и система обеспечения работ.

Когда обсуждается вопрос организации отдела тестирования (т.е. структурной единицы организации), то на первый план выходит бизнес составляющая. Другими словами, необходимо решить ряд вопросов:
1. Какой объем работ гарантирован на значительный промежуток времени?
2. Где, какими способами, в какие сроки и какой квалификации набирать специалистов?
3. Как приводить "новеньких" к общему знаменателю? Чему их необходимо обучить? Кто и как будет проводить обучение? Как быстро "новенький" может быть включен в работу, и он сможет поддерживать средние корпоративные стандарты?
4. Какой критический уровень утилизации специалистов? Другими словами, сколько специалистов и в течение какого времени могут не быть востребованы в проектной работе (в случае если для всех проектов требуется=оплачено меньше специалистов, чем есть в наличие) без их увольнения? Это вопрос управления бюджетом.
5. Чем занять "свободных" специалистов, не востребованных в проектной работе на текущем этапе?
6. Есть ли ресурс для управления людьми? По другому, есть ли у руководителя время (выделяется ли) на работу с людьми?

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

Представьте, что вы компоненты программы. Есть компонент разработка, компонент эксплуатация (или еще какой) и есть компонент тестирование. Все общение между компонентами происходит через СТАНДАРТНЫЙ интерфейс. Это означает, что правила игры, требования и документы на "входе" и на "выходе" зафиксированы и регламентированы. Отделом предоставляется пакет СТАНДАРТНЫХ услуг в рамках стандартной (проектной) работы компании. Возможен отдельный интерфейс на не стандартные запросы.

Все! Можно начинать работать.

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

[astenix]

saezar отнюдь не издеваюсь.

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

Вон, очень верные вопросы:

3. Как приводить "новеньких" к общему знаменателю? Чему их необходимо обучить? Кто и как будет проводить обучение? Как быстро "новенький" может быть включен в работу, и он сможет поддерживать средние корпоративные стандарты?

4. Какой критический уровень утилизации специалистов? Другими словами, сколько специалистов и в течение какого времени могут не быть востребованы в проектной работе (в случае если для всех проектов требуется=оплачено меньше специалистов, чем есть в наличие) без их увольнения? Это вопрос управления бюджетом.

5. Чем занять "свободных" специалистов, не востребованных в проектной работе на текущем этапе?

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

Конкретно по-делу: Из чего может состоять процесс создания отдела тестирования с нуля?

Отвечу так:

• Понять, что именно разрабатывается
• Понять, какие используются технологии разработки
• С учетом вышеуказанного принять решение о том, как "вклинить" в разработку процесс тестирования

Дальше начинаются всякие "если":

• Если разработка в стиле agile - будет один метод тестирования
• Если разработка "классическая" - будет другой метод тестирования
• Если и то, и это - придется комбинировать. Это уже тактика, ситуация на поле боя, а она, как известно, меняется каждую минуту.

Мне кажется, что подготовительный этап несколько бледнеет по сравнении с этапом внедрения.

1. Создать формальную (читай финансовую) основу для создания отдела. - это делается быстро.

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

Для этого надо знать, сколько народу будет в отделе. И где они будут сидеть - рядом с программистами? В отдельном кабинете? В отдельном здании?

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

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

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

Что ещё - найти того, кто будет главным тестировщиком в будущем отделе. Тим-лид нужен.

[Oldman]

Можно глянуть презентацию моего доклада на SQA2 http://sqa2conf.blog...-post_5947.html
Там конечно много всего пропущено, но основные вехи есть

[saezar]

2 Oldman: C нетерпением жду полного текста доклада.
2 astenix: *Издеваетесь* было по поводу недостаточно опытного... Всё правильно, много вопросов не задано. В принципе, я и завёл эту тему потому что бы собрать вопросы, на которые приходится отвечать в большинстве случаев, что бы обойти проблемы, на котрые уже наталкивались другие.
2 Green: Спасибо, ваши вопросы включу в свой список. Применительно к моей ситуации я их переформулирую и дополню:
Организация:
1. Сколько нужно человек в отдел?
2. Какой у тестировщиков должен быть уровень знаний в предметной области ?
3. Какой у тестировщиков должен быть уровень знаний по профессии ?
4. Какие сроки подготовки допустимы для новичков?
5. Приемлемо ли брать студентов?
6. Какие ключевые роли присутствуют?
7. Какие роли могут допускать совмещение?
8. Каков бюджет?

Окружение:
10. Помещение?
11. Оборудование?
12. Программные средства? (Тут я имею ввиду систему документооборота, систему управления требованиями, багтрекер, и т.д.)

Методологии:
14. Существующий процесс разработки?
15. Место тестирования в процессе разработки?
16. Структурная декомпозиция работ по тестированию?

И на основе ответов на эти вопросы, выполнить 5 моих пунктов. Подозреваю, что вопросы перечислены далеко не все, поэтому, жду дополнений, замечаний и предложений :)

[saezar]

Неужели всё? Никаких идей?

[astenix]

Ясно, что ответ на такой вопрос будет столь же пространным сколь бесполезным.

Собственно, что еще?

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

[Green]

2 saezar,

Как успехи?

[saezar]

Только что заметил ваше сообщение. Ко мне похоже не весь RSS приходит - строго не более 20 сообщений за сутки.
Проблем пока больше чем успехов.

[DrVal]

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

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

[saezar]

К сожалению, нашей библиотеке не удалось приобрести эту книгу. Если у когото вдруг обнаружится - буду премного благодарен.

[rlabs]

К сожалению, нашей библиотеке не удалось приобрести эту книгу. Если у когото вдруг обнаружится - буду премного благодарен.

Купите на Озоне и принесите чек в бухгалтерию. Обычно это делается так.

[saezar]

Библиотека в курсе про Озон.

[LeshaL]

Библиотека в курсе про Озон.

Ну видать не совсем в курсе:
http://www.findbook....

Но на озоне что-либо покупать не рекомендую, цены 20-30% выше чем нужно.
Недели две-три назад делал несколько закупок в books.ru, никаких нареканий.

[rlabs]

Ну видать не совсем в курсе:

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

Но на озоне что-либо покупать не рекомендую, цены 20-30% выше чем нужно.
Недели две-три назад делал несколько закупок в books.ru, никаких нареканий.

В Омск (а у меня откуда-то появилась мысль, что речь идет про Омск) отлично возит книжки Bolero. Сам обычно ими пользовался, а вот в Петербурге озон как-то ближе.

[LeshaL]

Ну видать не совсем в курсе:

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

Но на озоне что-либо покупать не рекомендую, цены 20-30% выше чем нужно.
Недели две-три назад делал несколько закупок в books.ru, никаких нареканий.

В Омск (а у меня откуда-то появилась мысль, что речь идет про Омск) отлично возит книжки Bolero. Сам обычно ими пользовался, а вот в Петербурге озон как-то ближе.

А букс.ру чем в Питере не ближе :) ?
Они даже книги издательства питер торгуют дешевле чем само издательство

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

[rlabs]

А букс.ру чем в Питере не ближе :) ?
Они даже книги издательства питер торгуют дешевле чем само издательство

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

Трудно сказать. Про findbook я знаю, пользуюсь правда достаточно редко. Книги бумажные покупаю обычно по принципу "накатило что-то", поэму чаще всего иду в круглосуточный "Буквоед". А если там нет - то проще заказать на озоне, дорога к их доставочному офису привычная. Хотя, может, и стоит поискать чего-то нового.

[culver]

Организация:
1. Сколько нужно человек в отдел?
2. Какой у тестировщиков должен быть уровень знаний в предметной области ?
3. Какой у тестировщиков должен быть уровень знаний по профессии ?
4. Какие сроки подготовки допустимы для новичков?
5. Приемлемо ли брать студентов?
6. Какие ключевые роли присутствуют?
7. Какие роли могут допускать совмещение?
8. Каков бюджет?
Окружение:
10. Помещение?
11. Оборудование?
12. Программные средства? (Тут я имею ввиду систему документооборота, систему управления требованиями, багтрекер, и т.д.)
Методологии:
14. Существующий процесс разработки?
15. Место тестирования в процессе разработки?
16. Структурная декомпозиция работ по тестированию?
И на основе ответов на эти вопросы, выполнить 5 моих пунктов. Подозреваю, что вопросы перечислены далеко не все, поэтому, жду дополнений, замечаний и предложений :)

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

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

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