С 2006 года наша компания вкладывает в «самостоятельный» инфоресурс — ecm-journal.ru. Предвкушая, что вопросы «самостоятельности» и «независимости» могут казаться спорными, сначала пишу определения в кавычках; но, в общем-то, эпитеты имеют место быть.



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

Постановка задачи

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

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

Используемые технологии:

• Microsoft SQL Server;
• Microsoft Office Excel;
• Комплекс sql-запросов, организованный в проект SQLProfilerReportHelper;
• Инструмент нагрузочного тестирования с возможностью выполнить sql-запрос (JMeter, Visual Studio Ultimate, ...);

Уровень 300 (для профессионалов).

Если коротко, то порядок действий для формирования отчётов по готовому трейсу таков:

1. запустить SQLProfilerReportHelper, кликнуть по кнопкам;
2. выполнить выборку записей из таблиц-отчётов, скопировать результаты в буфер обмена;
3. запустить Microsoft Office Excel, вставить записи из буфера в автоматически форматируемую таблицу и сохранить документ-отчёт.

Инструмент и шаблон отчёта доступны для скачивания SQLProfilerReportHelper.
Если вам интересно ознакомиться с описанием инструмента и отчётов и порядком их составления, читайте далее.

Постановка задачи

Одной из неотъемлемых частей любой ECM-системы является управление бизнес-процессами, или workflow.

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

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

Это диктует некоторые требования, которые предъявлялись к движку бизнес-процессов:

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

При разработке новой версии движка бизнес-процессов мы решили попробовать Windows Workflow Foundation (далее WF).

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:

• командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
• автоматизация рутины важнее задавливания массой;
• быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
• доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
• открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
• демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
• необходимый минимум правил, но требовательность при их исполнении;
• когда все думают одинаково — никто не думает;
• «мужик сказал — мужик сделал», все несут ответственность за свои решения.

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

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

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

Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:

• Пользователям некогда оформлять замечания к продукту. Особенно если это касается удобства использования программы, а не функционала.
• Не понятно, насколько интуитивен интерфейс. Можно, конечно, проводить опросы, но они обычно малоинформативны.
• Замечания поступают слишком поздно. У разработчика остается меньше времени на их исправление.

Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.