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

[VLana]

Всем доброе время суток!

Не могли бы вы поделиться практикой составления и утверждения тест-плана. Сразу скажу, что под тест-планом я понимаю ту часть, которая определяет набор функций подлежащих тестированию.
1) Кто из коллектива тестировщиков составляет данный план?
2) Каким образом человек определяет что именно надо протестировать? По какому-то общедоступному документу? По согласованию с ведущим разработчиком? РМ? По набору сообщений в БагТрекер? Может еще что-то?
3) Есть ли взаимодействие с представителями разработчиков во время планирования? Как происходит взаимодейтвие? Устно? Письменно? С один или несколькими разработчиками?
Интересуют случаи, когда протестировать надо не всю систему, а только ее часть. Как определить покрытие?

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

Первое и наверное самое главное- информация. Что у меня есть в наличии:
-Документ, определяющий ЗАДАЧИ на версию. Т.е что новое будет разрабатываться, кем, процент выполнения задачи, запись о задаче в БТ
-BugTacker. На версии есть баги и пожелания от заказчика, которые надо сделать в текущей версии. Весь набор когда-то установили, чтобудут делать. НО. В данный момент информация о том, что будут делать, а что нет стала не актуальной. Перебирать 100+ багов на предмет "что выносим из версии" никто не будет. Т.е даже если перебрать всю пачку багов мне, врятли тест-план получится актуальным.
-Не все работы по проекту ведутся в рамках бага. Т.е изменения могут вноится "попутно".

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

Т.е если я могу составить тест-план по задачам и замечаниям, то по багам и "еще-каким-то изменениям" никак не получается.

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

[greesha]

Всем доброе время суток!

Не могли бы вы поделиться практикой составления и утверждения тест-плана. Сразу скажу, что под тест-планом я понимаю ту часть, которая определяет набор функций подлежащих тестированию.
1) Кто из коллектива тестировщиков составляет данный план?
2) Каким образом человек определяет что именно надо протестировать? По какому-то общедоступному документу? По согласованию с ведущим разработчиком? РМ? По набору сообщений в БагТрекер? Может еще что-то?
3) Есть ли взаимодействие с представителями разработчиков во время планирования? Как происходит взаимодейтвие? Устно? Письменно? С один или несколькими разработчиками?
Интересуют случаи, когда протестировать надо не всю систему, а только ее часть. Как определить покрытие?

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

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

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

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

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


Если Вы работаете тестировщиком, но Вам приходится самостоятельно определять набор тесткейсов, то видятся такие основные варианты:
1) Вам доверена роль тест-менеджера. Требуйте повышения зарплаты
2) За выпускаемый продукт реально никто не несёт ответственности. Либо принимайте её на себя (и переходите к пункту 1), либо каждый раз при принятии решения требуйте формального подтверждения от "ведущего по версии"

Настораживают в Вашем рассказе следующие моменты:

От руководства поступило желание сократить объем тестирования.

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

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

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

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

А чем он тогда вообще занимается? В чём выражается его статус "ведущего"?

[astenix]

1) Кто из коллектива тестировщиков составляет данный план?

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

2) Каким образом человек определяет что именно надо протестировать? По какому-то общедоступному документу? По согласованию с ведущим разработчиком? РМ? По набору сообщений в БагТрекер? Может еще что-то?

По всему сразу, и в зависимости от ситуации.

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

Если релиз делают из уже существующего продукта, у которого уже есть определенные "Баги, которые надо фиксить" и "Баги, которые можно не фиксить", список "Новых функциональностей" и "Список измененных функциональностей" - ситуация даже упрощается. Особенно если все грамотно регистрируется в багтрекере.

Согласование в большинстве случаев (и в вашем) не требуется. Требуется обсуждение "до того, как" начинается работа надо составлением тест-плана. Вот когда ваш план будет готов, тогда можно будет требовать согласования.

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

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

3) Есть ли взаимодействие с представителями разработчиков во время планирования? Как происходит взаимодейтвие? Устно? Письменно? С один или несколькими разработчиками?

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

Они в первую очередь "подскажут", результаты тестирования каких модулей или фич им нужно получить от тестировщиков.

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

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

Интересуют случаи, когда протестировать надо не всю систему, а только ее часть.

Это не имеет значения в вашем случае.

Как определить покрытие продукта тест-кейсами?
Вот: showtopic=9678.

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

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

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

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

Первое и наверное самое главное- информация. Что у меня есть в наличии:
-Документ, определяющий ЗАДАЧИ на версию. Т.е что новое будет разрабатываться, кем, процент выполнения задачи, запись о задаче в БТ

Отличный документ.

-BugTacker. На версии есть баги и пожелания от заказчика, которые надо сделать в текущей версии. Весь набор когда-то установили, чтобудут делать. НО. В данный момент информация о том, что будут делать, а что нет стала не актуальной. Перебирать 100+ багов на предмет "что выносим из версии" никто не будет. Т.е даже если перебрать всю пачку багов мне, врятли тест-план получится актуальным.
-Не все работы по проекту ведутся в рамках бага. Т.е изменения могут вноится "попутно".

Это очень плохо в смысле работы с багтрекером, но пока не мешает задаче типа "Составить тест-план". Можно ведь напрямую спросить продакт-менеджера - что у вас там за ситуация, парни, что вам там надо тестировать, что не надо.

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

Так у вас уже есть тест-план? Какие проблемы-то?

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

Сидеть на совещаниях разработчиков - это полезно только изредка.

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

Это уже системная беда. Но если он очень занят, то к нему можно подойти с какими-то набросками плана тестирования. Глядя на перечисленные пункты, ему будет проще сказать, что нужно, а что нет.

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

Если с документами сложно разобраться, ориентируйтесь по продукту, которые следует "подвергнуть тестированию".

Например, основные функции системы типа "Livejournal.com":

"Гость"
 
   	зарегистрировать и создать свой дневник
 
   	пройти тесты на сайте
 
   	принять участие в опросах
 
   	прочитать случайный дневник
 
   	общаться в talxy-чате
 
   	просматривать "интересные" ссылки
 
   	смотреть "кто, где, когда?"
 
   	посмотреть гороскоп
 
   	посмотреть, кто в онлайне
 
   	посмотреть интересы других пользователей
 
   	посмотреть города и страны, в которых живут другие пользователи
 
   	поиграть в онлайн-игры
 
   	посмотреть полный список всех пользователей
 
   	посмотреть список всех дневников
 
"Зарегистрированный пользователь"
 
   	прочитать ленту друзей
 
   	проверить, изменилось ли что-нибудь в дискуссиях, в которых он участвует
 
   	закачать аватарки
 
   	завести дневник
 
   	назвать дневник
 
   	закачать свою фотографию
 
   	настроить дизайн дневника
 
   	найти ответы на многие вопросы в помощи
 
   	посмотреть, кто подписан на его дневник
 
   	посмотреть, кто живёт рядом с ним
 
   	посмотреть, кто имеет общие интересы
 
   	почитать ленту дневников из его закладов
 
   	подобрать себе аватарки в библиотеке аватарок
 
   	создать свой опрос
 
   	добавить ссылку
 
   	добавить желание
 
   	пригласить друзей

Это основа плана. С этим на руках уже можно что-то обсуждать.

[VLana]

Спасибо за развернутые ответы :)
2_greesha:
Очень порадовала ваша организация. Очень хорошо, когда есть "кадры" для любой работы :)
Хотелось бы спросить, а какую должность занимаете Вы? Так картина будет еще яснее. Если не сложно, то с кратким перечнем обязанностей.

1) Вам доверена роль тест-менеджера. Требуйте повышения зарплаты

:) Обязательно, если все пройдет успешно.

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

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

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

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

А чем он тогда вообще занимается? В чём выражается его статус "ведущего"?

У нас в компании "Ведущий" передается как эстафетная палочка. Одну версию один, другую другой. В любом случае эта палочка ходит только по руководителям групп разработчиков. Ведущий получается и частично РМ и программист. Т.е решение административных вопросов с заказчиком+ ведение группы+ непосредственный кодинг.
Ну вот и протиснутся со своими проблемами сложно. Т.е чувствуешь что человеку не до тебя. Очень неприятный момент.

2_astenix

Если релиз делают из уже существующего продукта, у которого уже есть определенные "Баги, которые надо фиксить" и "Баги, которые можно не фиксить", список "Новых функциональностей" и "Список измененных функциональностей" - ситуация даже упрощается. Особенно если все грамотно регистрируется в багтрекере.

Скажите, а список измененных функциональностей составляют разработчики? Или вы сами определяете как-то?
Этот список в БТ? Или отдельным документиком?

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

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

Мы составляеи в Mercury QC. Документ только для внутреннего использования. Заказчику пишется ПиМ со всеми колонитулами и абзацами :)
При разработке плана я выделяю более крупные функции, которые будут разрабатывать, далее подхожу к программисту, который эту функцию реализовывает и уже с ним выясняю что будет сделано по функции.

Так у вас уже есть тест-план? Какие проблемы-то?

Есть тест план по новыйм функциям и по замечаниям от заказчика. В проекте на версии зарегистрировано еще 100+ багов, которые создавались нами самими. Эти баги какие-то правяться, какие-то висят грузом. Никто их не отслеживает в БТ. Когда версия закроется, все что не починили переводится на следующую версию.
Вот в этом и есть проблема, что при составлении ТП я не могу учесть изменения по багам, так как они не актуальны.


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

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

Может еще кто-нить поделиться хочет ? :)

[greesha]

Спасибо за развернутые ответы :)
2_greesha:
Очень порадовала ваша организация. Очень хорошо, когда есть "кадры" для любой работы :)
Хотелось бы спросить, а какую должность занимаете Вы? Так картина будет еще яснее. Если не сложно, то с кратким перечнем обязанностей.

Должность у меня простая: технический директор. :)
Обязанности перечислить затрудняюсь, я их изобретаю сам по мере необходимости.

[astenix]

Список измененных функциональностей составляют разработчики? Или вы сами определяете как-то?
Этот список в БТ? Или отдельным документиком?

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

Эти документы я уношу в свою берлогу и готовлюсь к тестированию по ним.

В момент, когда релиз готов, оказывается, что по мере работы были сделаны какие-то изменения, о которых эти меня не проинформировали. Я этого ожидал, поэтому ежедневно спрашивал тим-лидов "Что у вас там нового?". Большая часть изменений мне уже известна, однако раздражает, когда время, официально отведенное на тестирование, уходит на выяснение незапланированных (для меня) изменений.

К слову, чтобы это предотвратить, нужно абсолютно все задачи проводить через баг-трекер. Чтобы не дергать каждого по-отдельности.

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

Все, что не актуально, выбрасывается в архив в связи с неактуальностью.

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

У нас есть идея, что задачи на тестирование раздаются тестерам. Каждый из тестеров знакомится с деталями задачи, проводит тестирование, пишет кейсы. На выходе получаются полный ТП с кейсами. Кто-нить так практиковал?

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

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

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

Конечно, должен. Change log должен быть в любом случае, и у менеджеров проекта, и у программистов. Особенно у программистов. Он же пишется не ПОСЛЕ того, как, а задолго ДО.