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

[Klepa]

День добрый!
Возникла задача написать регламент передачи кода от разработчиков тестерам. Инициатива идет именно от тестеров, соответственно, инициатива наказуема :)
Ранее в нашей конторе такого документа не было, писать приходится с нуля. Понимаю, что изначально надо опираться на наши требования. Но, может быть, где-то описаны стандартные требования? Очень бы хотелось иметь что-то, от чего можно отталкиваться и в определенных случаях не изобретать велосипеда

[Kaluga]

Инициатива идет именно от тестеров, соответственно, инициатива наказуема :) 

Не стоит так боятся, ничего экстраординароного в этом нет.

Ранее в нашей конторе такого документа не было, писать приходится с нуля.

Лучше поздно, чем никогда ;)

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

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

[Klepa]

Кстати, что Вы понимаете под передачей кода? Передачу конкретного билда или начало фазы тестирования?

Имеется в виду начало фазы тестирования в принципе. Дело в том что последнее время стало за правило выделять месяц на тестирование, но выдавать код кусками. А тестирование не модульное. Поэтому любая дореализация приводит к перетестированию всего. Вот и хочется как-то регламентировать...

[Kaluga]

Имеется в виду начало фазы тестирования в принципе.

Это вообще не надо боятся делать. Какую технологию или стандарт не возьми - все рекомендуют регламентировать начало фазы тестирования еще в тест плане. Так что - вперед!

[_IT_]

Имеется в виду начало фазы тестирования в принципе. Дело в том что последнее время стало за правило выделять месяц на тестирование, но выдавать код кусками. А тестирование не модульное. Поэтому любая дореализация приводит к перетестированию всего. Вот и хочется как-то регламентировать...

А сообщается заранее какие куски кода они не дали или вы с процессе обнаруживаете пропажу?
Имеет смысл разработать набор тестов, часа на 4, и прогонять их на каждом новом билде, дабы убедиться, что все в наличии. Если тесты прошли, значит билд принят на тестирование, процесс пошел. Если тесты не прошли, билд возвращается, тестирование его прекращается.

[Klepa]

А сообщается заранее какие куски кода они не дали или вы с процессе обнаруживаете пропажу?

Как правило, знаем. Программеры честно говорят: вот это не сделано, но вы пока без этого посмотрите... А "это", бывает, приводит к изменению всего. Вот и от этого тоже хочется защищаться

[Mila]

Как правило, знаем. Программеры честно говорят: вот это не сделано, но вы пока без этого посмотрите... А "это", бывает, приводит к изменению всего. Вот и от этого тоже хочется защищаться

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

[ElenaF]

У нас проблема похожая. ТОлько всё уже усугубляется тем, что есть жесткие сроки выпуска очередной версии... Практически всё время на выпуск версии съедает разработка, поэтому тестировщики, чтобы не подвести всю проектную группу перед выпуском работают со значительной перегрузкой. Что естественно, не может не сказываться на том, насколько внимательно, то есть качественно, проверяют.
Мы пробовали делать так: по плану разработки с такой-то даты должно начаться финальное тестирование, а разработка еще не завершена -> тогда мы начинаем тестирование всё равно, но при получении каждого нового билда на тестирование вместе с ним мы получаем отчет об изменениях в проекте с анализом того, на что эти изменения повлияли -> на основе этого отчета решаем, что из протестированного функционала надо перетестировать, а что нет. Это помогает. Но не для всех проектов. Так как такая вот работа с изменениями - это дополнительная нагрузка на руководителя проекта. а на это идет не каждый.
Поэтому мы вот тоже думаем, как бы так организовать процесс разработки, чтобы не съедалось время выделенное на тестирование, чтобы как-то отделить планы по разработке от планов по тестированию... Но, поскольку, тестирование - это часть цикла разработки, то резать по живому не получается...

[Yury]

Возникла задача написать регламент передачи кода от разработчиков тестерам. Инициатива идет именно от тестеров ...

А нужен ли вашей фирме и вашим разработчикам этот регламент?
Поможет ли он им как-то или нет?

Для ответа на этот вопрос неплохо бы знать ответы на следущие вопросы:
У вас больше тестеров или программистов?
Сколько проектов приходится Вам тестировать?
Что Вы делаете до того, как Вам код передан официально на тестирование?
Если Вы начинаете тестирование до официальной передачи законченного кода, то помогает это вашим программистам или нет?

Имеется в виду начало фазы тестирования в принципе. Дело в том что последнее время стало за правило выделять месяц на тестирование, но выдавать код кусками. А тестирование не модульное. Поэтому любая дореализация приводит к перетестированию всего. Вот и хочется как-то регламентировать...

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

Главное здесь не делать из себя героя и не обещать того, что Вы не можете достичь.

Помните, что Вы не отвечаете за качество продута, а только за её оценку!

[Imbecile]

Поделюсь своим опытом (я руководитель отдела качества).

У нас в компании создание и тестирование новой версии основано на двух столпах:
1. Контроль версий.
2. Баг-трекинг.

Есть технический руководитель проекта (по совместительству Team Leader)
Он вместе с Top Level менеджерами осущевствляет планирование релизов нового функционала. Без одобрения QA отдела релиза быть не может. Поэтому сроки распределяются с учётом времени на тестирование. После того, как поставлен список features, которые надо зарелизить в ближайшем билде, разработчики занимаются разработкой, а QA отдел занимается подготовкой тестирования (тест-план, тест-кейсы, скрипты и т.п.). Это так, преамбула. А теперь сам процесс.

1. Разработчики проводят новую Label в системе контроля версий (у нас это Borland StarTeam).
2. Сообщают QA отделу, что можно собрать и тестировать новый функционал.
3. QA собирает новый билд по проведённой Label.
4. Устанавливает его на тестовом серваке (сносит старый и ставит новый, апдейтит, устанавливает ещё один экземпляр и т.п.)
5. Проводит Common Release Control - CRC (тестирование функционала, который обязательно должен работать в любой версии системы)
6. Проводит тестирование функционала, заявленного, как реализованный.
7. Пока QA занимается тестированием, разработчики занимаются баг-фиксингом, но все пофиксенные баги, репортятся, как баги пофиксенные в следующем билде.
8. Если QA не сообщает о критических багах в CRC, а также об отсутствии таковых в новом функционале, то билд считается стабильным и его можно передавать клиенту.
8.а. Не обязательный, но желательное дополнение к 8. это выпуск Release Notes и в первую очередь внесение в них Known Issues, то есть багов, которые есть в баг-трекинг системе, но не пофиксенных ещё. Тем самым можно снять с себя ответственность за выпуск недостаточно качественного билда, а заодно посовещаться с Top Level менеджерами, по поводу отдачи билда клиентам или нет.
9. Если билд оказался нестабильным, QA может продолжить тестирование нового функционала (если это возможно), чтобы снабдить разработчиков информацией, но в любом случае билд нельзя отдавать клиенту.

P.S. Проблема сроков, это проблема не тестировщиков или разработчиков, а проблема управления проектами. Нельзя сваливать её на QA отдел или Development отдел.

[Inevitable]

Поделюсь своим опытом (я руководитель отдела качества).

У нас в компании создание и тестирование новой версии основано на двух столпах:
1. Контроль версий.
2. Баг-трекинг.

Есть технический руководитель проекта (по совместительству Team Leader)
Он вместе с Top Level менеджерами осущевствляет планирование релизов нового функционала. Без одобрения QA отдела релиза быть не может. Поэтому сроки распределяются с учётом времени на тестирование. После того, как поставлен список features, которые надо зарелизить в ближайшем билде, разработчики занимаются разработкой, а QA отдел занимается подготовкой тестирования (тест-план, тест-кейсы, скрипты и т.п.). Это так, преамбула. А теперь сам процесс.

1. Разработчики проводят новую Label в системе контроля версий (у нас это Borland StarTeam).
2. Сообщают QA отделу, что можно собрать и тестировать новый функционал.
3. QA собирает новый билд по проведённой Label.
4. Устанавливает его на тестовом серваке (сносит старый и ставит новый, апдейтит, устанавливает ещё один экземпляр и т.п.)
5. Проводит Common Release Control - CRC (тестирование функционала, который обязательно должен работать в любой версии системы)
6. Проводит тестирование функционала, заявленного, как реализованный.
7. Пока QA занимается тестированием, разработчики занимаются баг-фиксингом, но все пофиксенные баги, репортятся, как баги пофиксенные в следующем билде.
8. Если QA не сообщает о критических багах в CRC, а также об отсутствии таковых в новом функционале, то билд считается стабильным и его можно передавать клиенту.
8.а. Не обязательный, но желательное дополнение к 8. это выпуск Release Notes и в первую очередь внесение в них Known Issues, то есть багов, которые есть в баг-трекинг системе, но не пофиксенных ещё. Тем самым можно снять с себя ответственность за выпуск недостаточно качественного билда, а заодно посовещаться с Top Level менеджерами, по поводу отдачи билда клиентам или нет.
9. Если билд оказался нестабильным, QA может продолжить тестирование нового функционала (если это возможно), чтобы снабдить разработчиков информацией, но в любом случае билд нельзя отдавать клиенту.

P.S. Проблема сроков, это проблема не тестировщиков или разработчиков, а проблема управления проектами. Нельзя сваливать её на QA отдел или Development отдел.

Imbecile совершенно верно рассказал, у меня есть лишь маленькие комментарии)

Во время сбора требований QA разрабатывает QA Assesment, Development - Impact assesmemt. После финализации требований QA и Development апдейтят свои Assesment (Assesment - это собственно как кодим и как тестим). 1) Затем девелоперы девелопят, тестировщики пишут тест-кейсы.
2)Затем девелоперы выдают build.
как я поняла, у вас, Imbecile, сборкой выдач занимается QA. У нас это делает специальный отдел, и так лучше, потому что принцип хорошей организации работы - четкое разделение труда.
2)Специальный отдел выдает сборку в QA.
3) Qa устанавливает сборку на свои серваки. "(сносит старый и ставит новый, апдейтит, устанавливает ещё один экземпляр и т.п.) - Imbecile, очень индивидуально, у нас процесс обновдения серваков происходит по другому. В любом случае, должен быть специальный док, который описывает действия с сервером, этот док в последствии выдается заказчику, так как правильная установка билда - очень важная часть работоспособности системы.

Далее согласна с Imbecile.
Known bugs (known issues у Imbecile) описание обязательно, если хотите сделать продукт качественным, а отношение заказхчика к вам серьезное.


То есть, со временем у Вас появятся свои наметки, но принцип один:
Программировыание/разработка документации
Сборка/выдача/установка билда
Тестирование
Багфиксинг
Внешняя выдача

При следующих внешних выдачах главное, чтобы были пофикшены критикал и хай внешние баги (то есть баги, которые нашел клиент)