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

[Yuliya]

Подскажите как улучшить процесс взаимосвязи работы программистов и тестировщиков.

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

[Tiana]

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

[Vasiliy]

1) Пусть программисты или менеджер проекта пишут какие изменения произошли в проекте.
2) А что все изменения вносят сразу в боевой продукт? Нельзя сделать так, что бы нововведения сначала отлаживали на внутренней сборке какой-нибудь? А вставлять уже после того как все оттестировано.

[Clauster]

Подскажите как улучшить процесс взаимосвязи работы программистов и тестировщиков.

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

Это нормально. Только надо научиться планировать тестирование. Разделять верификацию, регрессионное тестирование, тестирование новой функциональности и т.д.

[Yuliya]

Подскажите как улучшить процесс взаимосвязи работы программистов и тестировщиков.

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

Это нормально. Только надо научиться планировать тестирование. Разделять верификацию, регрессионное тестирование, тестирование новой функциональности и т.д.

Вы не могли бы об этом поподробнее.

[Yuliya]

Tiana, у нас разработчики и тестировщики работают на одном сервере

[Tiana]

Tiana, у нас разработчики и тестировщики работают на одном сервере

По опыту работы в нашей компании могу классифицировать выпускаемые версии следующим образом:
1. локальная версия продукта (у разработчика на машине).
2. версия для тестирования на локальном сервере.
3. версия для тестирования на удаленном сервере (таких серверов может быть несколько, к примеру, с различной конфигурацией).
4. Production версия.

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

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

[Clauster]

Вы не могли бы об этом поподробнее.

Боюсь, у меня не хватит на это ни сил, ни времени, ни желания. Тем более, что это есть в книжках, в статьях на этом сервере и в некоторых темах на форуме. Поищите, информации много.

[Clauster]

Ещё в базе знаний есть кое-что http://software-test...;JetapovProekta

[Tiana]

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

[dimasoft]

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

[ЛЭП-500]

Я тоже за автоматизацию стандартного набора с ручным тестированием нового.

[Ted]

Подскажите как улучшить процесс взаимосвязи работы программистов и тестировщиков.

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

Это нормально. Только надо научиться планировать тестирование. Разделять верификацию, регрессионное тестирование, тестирование новой функциональности и т.д.

Это ненормально, т.к. программа одна разрабатывается и взаимодействие отделов для достижения результата должно присутствовать, иначе это басня Крылова будет. Да и существует множество программ по контролю версий, приложений для управления разработкой. К тому же множество бесплатных. Только чаще всего программистам просто не охота написать две строчки об изменениях в комментариях. Вот и приходится перерывать весь программный код и указывать, что данные изменения генерят новый баг :) На это прогеры реагируют в основном "дико". Другого слова не получилось найти:))) Поэтому до внедрения процесса разработки желательно прочитать пару глав по психологии взаимотношений на рабочем месте и дать почитать или провести двух часовой трениг с разработчиками :)))
А вот как строить "дипломатию процесса" с прогерами, которые в своей служебной жизни не встречались с тестеровщиками?!... Это и для меня осталось загадкой на сегодня:) Но думаю тут решения возможны только через высшее руководство... после протоколирования затрат на исправления одних и тех же ошибок в течении недели, месяца. Больно, но проект нужно выпускать все таки. И тестировщик "подписывается" под очередной сборкой и релизом тоже. И в случае пропущенного бага является перед руководством не в лучшем свете. Спасибо за внимание:)

[bsod]

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

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

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

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

Необходимо сесть с представителями разработчиков и обсудить проблему. Донести до них, что качество - это не всецело вотчина отдела тестирования. Выпуск качественного продукта невозможен без ответственности за качество со стороны разработчиков. У них есть возможности первичного QA кода, поверьте ;) Однако желания участвовать в QA скорее всего нет. Это вам и нужно исправить. Как именно - отдельная история, не обязательно со счастливым концом. Но всё же вам стоит попытаться.