Документ "Методика работы отдела тестирования"
#1
Отправлено 09 сентября 2009 - 09:51
Столкнулся с проблемой - нужно описать методику работы отдела тестирования.
Есть наработки, но хотелось бы "классики", либо действительно полезных статей, мнений, идей.
Уважаемый ALL, поделитесь мнениями, как у вас описывается данный документ, что полезного и нужного нужно указать в нём?
#2
Отправлено 09 сентября 2009 - 19:29
Отдел обслуживает один или несколько проектов? Структура отдела - пул ресурсов с привлечением к проектам или выделенные группы по специфике видов тестирования? Наружу работаете? В ответственность руководителя отдела входит HR-функция? Свой бюджет есть? ЗП или только бонусы?
Редактор портала www.it4business.ru
#3
Отправлено 10 сентября 2009 - 04:08
По пунктам:
1. Отдел обслуживает несколько проектов.
2. Структура отдела - руководитель отдела, несколько руководителей групп тестирования, тестировщики. Как минимум, на 1 проект есть выделенный 1 тестировщик. На проект (или группу проектов) есть выделенный руководитель группы тестирования.
Есть также группа
В целом ситуация такая, что группа тестирования, состоящая из 1 постоянного тестировщика + 2-3 из свободных, тестируют некий проект.
Как только они заканчивают основной объём работа, что "свободные" переходят в другую группу, а постоянный продолжает работы.
3. Наружу не работаем.
4. В ответственность руководителя отдела входит HR функция.
5. Своего бюджета нет (всё делается через служебки)
6. Есть оклад, с него могут "срезать" за несвоевременное выполнение или некачественную работу. Бонусы только в виде 13й з.п.
#4
Отправлено 10 сентября 2009 - 06:47
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#5
Отправлено 10 сентября 2009 - 06:56
Документ "Положение о тестировании" я уже написал.. это немного другой документ, нежели "Методика работы отдела".
В положении указываются общие принципы, стандарт процесса, документы... Это внутренняя организация.
"Методика работы отдела" - это (в моём понимании) документ, описывающий более глобальные схемы, возможно взаимодействие с заказчиком, описание работы отдела и взаимодействия с другими отделами. И в этом документе уже можно ссылку давать на "Положение о тестировании".
В иерархии документов приблизительно так:
1. Штатная структура и должностные обязанности отдела
2. Методика работы отдела
3. Положение о тестировании отдела
и далее вспомогательные документы
4. План тестирования
5. Стратегия тестирования (как часть плана тестирования, но более развёрнуто)
6. Шаблоны ...
и т.д.
С меня сейчас требуют документ "Методика работы отдела"... Слава отпишется, надеюсь, что будет видна разница.
#6
Отправлено 10 сентября 2009 - 07:40
Прям так и называется? :) Неоднозначно…3. Положение о тестировании отдела
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#7
Отправлено 10 сентября 2009 - 08:08
Никакой осмысленной причины писать кучу разных документов со столь сложными взаимными отношениями я не могу придумать.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#8
Отправлено 10 сентября 2009 - 08:44
Вы думаете, это я сам придумал?Либо вам там по случаю кризиса нечем полезным заняться :)
- скорее "либо" :) Обратите внимание http://software-test...topic15863.html - видите, не я один такой.либо готовится какой-то аудит/сертификация.
...
To Alfa
Полное название "ПОЛОЖЕНИЕ О ВНУТРЕНЕМ ПРОЦЕССЕ ТЕСТИРОВАНИЯ В ПРОЕКТАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ"
#9
Отправлено 10 сентября 2009 - 19:01
1. Отдел обслуживает несколько проектов.
Тогда нужно расписать очередность выполнения задач. Я бы рекомендовал обычный стэк как в службе поддержки (все в очередь, когда доберемся до вашего запроса - скажем когда будет сделано) + правила исключений. Иначе будет толкотня вокруг тебя когда ПМ-ы будут торговаться за приоритеты их задач.
2. Структура отдела - руководитель отдела, несколько руководителей групп тестирования, тестировщики. Как минимум, на 1 проект есть выделенный 1 тестировщик. На проект (или группу проектов) есть выделенный руководитель группы тестирования.
Правила назначения сотрудника в проект и вывода из проекта. Или будет торговля "А дай мне лучше Колю, у него вид умнее". Это твоя полянка - распиши по каким правилам ты кого и куда ставишь.
Есть также группа
Кхм. Накой? Аврал это ЧП - присвой авралам такой статус и сделай все, чтобы недопускать, просто формально не принимая в тестирование (раздел "Приемка ТЗ и Продукта в отдел тестирования для анализа: состав поставки продукта в тестирование и сроки поставки").
В целом ситуация такая, что группа тестирования, состоящая из 1 постоянного тестировщика + 2-3 из свободных, тестируют некий проект.
Как только они заканчивают основной объём работа, что "свободные" переходят в другую группу, а постоянный продолжает работы.
Я бы оставил 1-2 на каждом проекте как тест-дизайнеров с глубоким погружением в спейифику проекта + бегающих бойцов на тест екзекьюшен + группа автоматизации. Если уж без бойцов никак совсем.
3. Наружу не работаем.
Значит SLA не нужен, уже проще.
4. В ответственность руководителя отдела входит HR функция.
Хреново :) Тогда у тебя большой раздел "Должностные инструкции и правила получения грейдов".
5. Своего бюджета нет (всё делается через служебки)
Хреново :) Тогда у тебя большой раздел "Правила согласования и утверждения расходов" в котором ты встроишь себя как точку выхода заявок из отдела наружу. В бюджетировании принимаешь участие?
6. Есть оклад, с него могут "срезать" за несвоевременное выполнение или некачественную работу. Бонусы только в виде 13й з.п.
Ты можешь срезать (тогда у тебя есть раздел "Премирование и депремирование") или кто?
Редактор портала www.it4business.ru
#10
Отправлено 10 сентября 2009 - 19:07
Глобально или не глобально зависит от степени детализации. У тебя достаточно хорошая и понятная задача."Методика работы отдела" - это (в моём понимании) документ, описывающий более глобальные схемы, возможно взаимодействие с заказчиком, описание работы отдела и взаимодействия с другими отделами. И в этом документе уже можно ссылку давать на "Положение о тестировании".
В иерархии документов приблизительно так:
1. Штатная структура и должностные обязанности отдела
2. Методика работы отдела
3. Положение о тестировании отдела
и далее вспомогательные документы
4. План тестирования
5. Стратегия тестирования (как часть плана тестирования, но более развёрнуто)
6. Шаблоны ...
и т.д.
Из чего состоит отдел (рабочие группы, правила ввода-вывода из группы, найма, обучения, повышения и увольнения), задачи (что отдел или группы умеет и должен решать, что не умеет и не должен - последнее обязательно), правила обращения в группу (я бы снова-таки рекомендовал стек и правила внесения исключений в стек), процедуры приемки продукта-задачи в работу (чтобы считаться принятым в рабоу версия продукта сопровождает release notes, ссылок на ревизию или собранный продукт, ссылкой на отчет о unit-тестовом покрытии, etc), процедура оценки трудоемкости (иначе буду торги "а почему вот это вы оценили аж в 3 недели!"), правила предоставления отчетности и завершения работ предусматривая вариант выхода по условию (если поставили "туфту", goto exit).
Редактор портала www.it4business.ru
#11
Отправлено 10 сентября 2009 - 19:09
Либо вам там по случаю кризиса нечем полезным заняться :) , либо готовится какой-то аудит/сертификация.
Никакой осмысленной причины писать кучу разных документов со столь сложными взаимными отношениями я не могу придумать.
Дык, никто вроде и не спрашивал "И нафига это всем им понадобилось?" :) На само деле расписать Конституцию и Законы государства оно не лишнее, имхо. Мягко говоря не лишнее.
Редактор портала www.it4business.ru
#12
Отправлено 11 сентября 2009 - 03:11
#13
Отправлено 11 сентября 2009 - 05:51
Извините, не сдержался :)Либо вам там по случаю кризиса нечем полезным заняться :) , либо готовится какой-то аудит/сертификация.
Никакой осмысленной причины писать кучу разных документов со столь сложными взаимными отношениями я не могу придумать.
Дык, никто вроде и не спрашивал "И нафига это всем им понадобилось?" :) На само деле расписать Конституцию и Законы государства оно не лишнее, имхо. Мягко говоря не лишнее.
Вообще-то ключевые слова были "со столь сложными взаимными отношениями". Я не против того, чтобы была Конституция. Но вот когда появляются Законы, тут начинается караул.
И даже не потому что для того, чтобы они были, нужен целый парламент, который их сочиняет, а также куча исполнительной и судебной власти, чтобы проводить их в жизнь.
А потому, что сами эти Законы становятся вещью в себе, к ним появляются поправки, на региональном уровне возникают законы, уточняющие федеральные и фиг разберёшь, чем руководствоваться.
Ну а самая страшная вещь -- это комментарии к Законам, которые по объёму скоро начинают превышать сами Законы в разы.
Вообще-то я даже не против Законов, пусть будут. Лишь бы они действительно соответстовали реальному укладу жизни в компании, тогда они хотя бы исполняться будут сами собой. Но вот если их написать, руководствуясь желанием сделать "лучше", позаимствовав "полезные идеи" у других государств -- может получиться нечто такое, отчего граждане либо предпочтут тяготы эмиграции, либо просто не будут соблюдать Законы.
И ещё одно замечание. Будучи тестировщиками-аутсорсерами нам приходилось работать с разными заказчиками, с разной степенью регламентированности процедур. Так вот, чем более зарегламентировано всё, чем больше всяких шаблонов-маблонов, отчётов-мотчётов, планов-шманов, тем дороже получается и внутреннее производство, и услуги аутсорсеров (если заказчик хочет -- нам приходится всю эту фигню писать, и мы это конечно включаем в счёт).
Мораль: не умножайте сущности сверх необходимого.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#14
Отправлено 11 сентября 2009 - 07:40
Обратите внимание http://software-test...topic15863.html - видите, не я один такой.
Так собственно из-за Вашей темы и решила свою проблему озвучить.
Руководство существующее положение дел не устраивает. Руководство ищет пути - как дела улучшить.
Чье-то рукодство - решило, что вот будет еще и методика - положение улучшится.
А вот у меня - руководство решило - вот будет подразделение - и положение улучшится.
Ну а далеко не всякое рукодство имеет представление о методологиях и о прочих аспектах разработки ПО.
#15
Отправлено 11 сентября 2009 - 08:45
Но создавать таким образом, чтобы они были полезные для сотрудников, а не только для
И если есть возможность вложить свой опыт в документы, то нужно его использовать.
#16
Отправлено 13 сентября 2009 - 09:41
Если начальство требует документы, то их нужно писать.
Но создавать таким образом, чтобы они были полезные для сотрудников, а не только дляначальства"галочки".
И если есть возможность вложить свой опыт в документы, то нужно его использовать.
#17
Отправлено 13 сентября 2009 - 13:39
За это нужно бить канделябром по голове.Хреново :) Тогда у тебя большой раздел "Должностные инструкции и правила получения грейдов".
А за это тем более канделябром.Есть оклад, с него могут "срезать" за несвоевременное выполнение или некачественную работу. Бонусы только в виде 13й з.п.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#18
Отправлено 13 сентября 2009 - 19:56
Редактор портала www.it4business.ru
#19
Отправлено 23 сентября 2009 - 10:57
Это "рыба" (только содержание), поэтому наращивайте и меняйте её содержимое, как вам удобно.
1. Задачи отдела
1.1. Тестирование программных продуктов
1.1.1. Определение тестирования
1.1.2. Основные документы
1.1.3. Этапы выполнения работ
1.1.3.1. Планирование
1.1.3.2. Тест дизайн
1.1.3.3. Выполнение тестирования
1.1.3.4. Тест анализ
2. Состав отдела
2.1. Структура отдела
2.2. Правила назначения сотрудника в группу тестирования
2.3. Штатное расписание
2.3.1. Штатное расписание
2.3.2. Должностные инструкции
2.3.3. Премирования и поощрения
2.3.4. Взыскание и увольнение
2.3.5. Аттестация сотрудников
3. Правила оказания сервиса
3.1. Очередность выполнения заявок на тестирование
3.2. Процедуры приемки продукта в работу
3.2.1. Приёмка документации
3.2.2. Приёмка продукта
3.3. Правила предоставления отчётности и завершения работ
3.3.1. Отчёт о проведённой работе
3.3.2. Передача версии в отдел внедрения
3.3.3. Подготовка к приёмо –сдаточным испытаниям, итоговый отчёт
#20
Отправлено 24 сентября 2009 - 08:44
Совместно со Славой сделали вариант документа по сабжу.
Это "рыба" (только содержание), поэтому наращивайте и меняйте её содержимое, как вам удобно.
Ой!!! Спасибочки!! Пригодится!
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных