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

[ЛаМпочка]

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

Мысли есть конечно свои, но в них такой разброд и шатания, что в моем документе дальше колонтитула с названием компании и надписи "Конфиденциально" ничего не продвигается :(

Буду благодарна любым советам по написанию подобной документации.

[Darkus]

Как всегда, стандартно начну с вопроса: " А кому это нужно? "
Если вам это нужно для начальства - то можете ради галочки описать просто всё так, как сейчас у вас происходит, никто это читать больше 1 раза не будет, всем такой документ будет до ЛаМпочки :)
...
Другое дело, что от данного документа будет кому то польза.
Вот смотрите. У нас приходят новые сотрудники. Они не знают что им нужно ставить кроме голой винды и к кому обращаться.
Сделали документ, где написано где что брать и к кому обращаться за помощью. Это РЕАЛЬНО помогло всем.
Теперь переходим к вашему случаю

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

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

[ЛаМпочка]

Как всегда, стандартно начну с вопроса: " А кому это нужно? "

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

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

[JimR]

Если совсем непонятно что и как делать, то попробуйте для начала нарисовать схему, по которой идет выпускаемое ПО.

Условно:
постановка задачи -> разработка -> тестирование -> сборка -> внедрение.

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

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

[Darkus]

Давайте обсудим вот этот момент:

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

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

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