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

[Trushkin]

Добрый день коллеги айтишники

Я представляю производителя систем электронного документооборота www.idlab.net.
Платформа IBM Lotus Domino
Мы занимаемся разработкой, внедрением и аутсорсингом систем автоматизации WorkFlow

Хотим встроить процесс тестирования в имеющуюся у нас технологию extrime programming (XP)

Если честно до сих пор руки не доходили, проблемы с тестирвоанием закрывались самими программистами пока мы не достигли некоторых количественных показателей скорости выполнения проекта и загрузки внедренцев. В реале наши продукты сейчас начал клиент тестировать, что рождает определенные проблемы. Я планирую высвободить до 30% времени внедренца и архитектора, за счет качественного тестирования доработок к нашим системам и ускорить внесение изменений на 20-30 %

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

Весь процесс от 20 минут до дня!!! Вся инфраструктура для онлайна у нас есть. Внутренняя автоматизация управления на том же Домино. IBM купило Rational, ждем спец релиз для Домино :rolleyes:

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

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

С уважением

[Олешка]

Добрый день :).

У меня пока вопрос по Вашей цепочке. Поясните, пожалуйста, что понимается под словами:

- местное тестирование - кем и что выполняется? Это тестирование силами программистов, тестирование отдельных модулей, отдельных функций?

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

Далее, время на весь процесс подразумевает что? Разработку отдельного патча, его тестирование и сдача клиенту? Есть ли там время на полную проверку функциональности (регрессионные тесты)?

Автоматических тестов у Вас пока нет? Заложено ли в процесс время на их создание?

[zar]

А extrime programming (XP) у Вас "классический"? Т.е. два разработчика за одним компьютером, постоянный рефакторинг и т.д.?

[Trushkin]

У меня пока вопрос по Вашей цепочке. Поясните, пожалуйста, что понимается под словами:

- местное тестирование - кем и что выполняется? Это тестирование силами программистов, тестирование отдельных модулей, отдельных функций?

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

Далее, время на весь процесс подразумевает что? Разработку отдельного патча, его тестирование и сдача клиенту? Есть ли там время на полную проверку функциональности (регрессионные тесты)?

Автоматических тестов у Вас пока нет? Заложено ли в процесс время на их создание?

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

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

С уважением

[Trushkin]

А extrime programming (XP) у Вас "классический"? Т.е. два разработчика за одним компьютером, постоянный рефакторинг и т.д.?

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

Я в эту область глубоко не погружался. Опишите в двух словах схему работы.

С уважением

[Case]

У Вас ведь технология ХР, не совсем понимаю в чём она тогда выражена.

[Олешка]

Я планирую высвободить до 30% времени внедренца и архитектора, за счет качественного тестирования доработок к нашим системам и ускорить внесение изменений на 20-30 %

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

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

А документация есть? Хотя бы постановка задачи, описание бизнес-логики? Или архитектор действительно все держит в голове?

[zar]

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

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

Одним словом, Вы хотите оптимизировать весь процесс, или только добавить в существующий тестера?

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

А система баг трекинга в существующем сейчас процессе используется? А сценарии тестирования (или просто использования системы) пишутся?

очень много зависит от постановки Архитектора, по сути проект у него в голове

А постановка то в каком виде? Формализованном (документы, диаграммы) или реально в голове?

[Green]

Какой вопрос - такой ответ!

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

Уважаемый, Trushkin!

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

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

В первую очередь, вам необходимо оценить состояние производственного процесса на предприятии в терминах CMM, т.е. определить где вы находитесь.

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

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

Но это еще не все. Вы уже имеете возможность оценить соответствие выших действий заданным целям, но как вы будите это осуществлять (оценку)? Необходим механизм ревизий или аудита.

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

Схема может показаться слишком громоздкой и не "подъемной". Но реалии таковы, что другого пути нет. B)

Вопрос заключается только в том, сколько и когда, т.е. сколько из вышеперечисленного реализовать и за какой срок.

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

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

Вопрос: как организовать процесс тестирования наиболее эффективным способом до того, как будет создан отдел тестирования или нанят тестировщик?

B)

[SALar]

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

...

В первую очередь, вам необходимо оценить состояние производственного процесса на предприятии в терминах CMM, т.е. определить где вы находитесь.

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

Скажу, что мне самому интересно формализовать этот список вопросов.

Итак группа "Где находится организация?":
1) Сколько человек работает над созданием ПО?
2) Сколько человек в проектной команде и сколько команд?
3) А какие роли у Вас в текущем процессе выделены? (с) zar?
4) Какие способы коммуникаций в проектной команде? Что считается официальным документом?

5) Каким образом построен документооборот?
6) Какие типы документов ведутся в компании?
7) Насколько они актуальны?
8) Кто делает приемку документов и каких?

9) Кто в настоящий момент принимает решение о передачи проекта / модуля / патча в производство?
10) На основании чего?

11) Как и кем ведется тестирование программы в настоящий момент? (список)
12) Какие процедуры применяются для улучшения качества документации, кода, продукта?
13) Как ведется учет ошибок?
14) Как осуществляется управление требованиями к изменениям / ошибками?

Список далеко не полный. Давайте его увеличим. А потом перейдем к группе вопросов "Что хочет организация?"

[Green]

Good job, SALar!

Предлагаю немного модифицировать угол зрения на проблему. :blink:

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

И коль речь зашла о процессах, то, на мой взгляд, будет уместнее всего привязаться к процессам по системе RUP, т.к. система ISO не столь конкретна в области производства ПО, а СММ пока не столь известна, что выбирать эти системы в качестве опорной точки.

[Green]

По RUP выделяется девять процессов. Из них 6 основных и 3 вспомогательных. Каждый из процессов отражает свой аспект общего производственного процесса и выражается в терминах: роли участников процесса, область их ответственности, процедура вхождения в процесс и критерии выхода из него, входные и выходные артифакты.

Техническими процессами являются:
- процесс моделирования производства;
- процесс управления требованиями;
- процесс анализа и проектирования;
- процесс реализации;
- процесс тестирования;
- процесс распространиения.

Процессы поддержки:
- процесс управления проектом;
- процесс управления конфигурацией и требованиями;
- процесс управления средой.

Все ли процессы нас интересуют в данный момент? :)

[Green]

Длительные праздники это хорошо!
С одной стороны можно отдохнуть, с другой стороны - есть время подумать.
:rolleyes:

Уважаемый Trushkin!

Еще раз перечитав Ваш вопрос, мне показалось, что для Вашей организации было бы полезно начать с самого начала,
а именно НАЧАТЬ ТЕСТИРОВАТЬ ПО.

(Именно то, о чем Вы спрашивали, но мы от обилия знаний, наверное, углубились в дебри теории. :unsure: Но это не означает, что описанное выше - неверно).

Если Вы задались таким вопросом, значит убеждать Вас в том, что тестирование полезно и важно, необходимости нет.

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

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

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

3. Кто примет решение о начале тестирования?
В этой роли может выступать руководитель проекта. В его же служебные обязанности должен быть включен пункт о контроле тестировочного процесса.

4. Какие документы готовит тестировщик до начала тестирования?
Прежде чем приступить к тестированию ПО, тестировщик должен ознакомиться с ним, понять бизнес-логику и разработать стратегию тестирования. Именно это описывается в плане тестирования. Так же к выходу первого билда готовятся тест кейсы, по которым тестируется первая функциональность.

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

6. Какая документация сопровождает передаваемую на тестирование функциональность?
Из своей практики могу сказать, что два документа обязательно должны готовиться с очередным билдом.
- Первый документ описывает как установить разрабатываемое приложение в тестовую среду (своеобразный прототип пользовательского документа). Готовиться один раз и в последствии только актуализируется.
- Второй - какая новая функциональность добавлена в данный билд. Хорошо бы со ссылками на требования или юс кейсы.

7. Что и в каком порядке тестирует тестировщик?
У нас на фирме все тесты разбиты на три категории:
- smoke tests - тесты, занимающие от 2 до 8 часов и проводимые с целю определения тестопригодности приложения;
- critical path tests - тесты, проверяющие наиболее вероятные пути пользователей;
- extended tests - тесты, не вошедшие в первые две категории.

8. Какой отчет готовит тестировщик по результатам тестирования?

9. Когда тестировщик заканчивает тестировать приложение?

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

Одновременно, можно "подтягивать" остальные отделы к пониманию процессов и вводить в них элементы технологичности.