35
Планирования задач и мероприятий для улучшения качества продукта,
анализа дефектов.
Разработки и поддержки в актуальном состоянии сопровождающей
тестирование документации (стратегии, подходы, тест-планы, чек-листы,
матрицы покрытия, матрицы рисков и другие «артефакты»), подготовки и
анализа тестовых окружений и данных. По сравнению с QC и
тестированием на данном этапе разрабатывается эффективная стратегия
тестирования и последовательность проведения различных тестов
продукта, описываются средства, инструменты тестирования и сценарии,
которые обеспечат необходимый уровень покрытия функциональных и не
функциональных требований (безопасность, нагрузка, инсталляция,
требования к usability и т.п).
Разработки и поддержки в актуальном состоянии метрик оценки качества
продукта, эффективности контроля качества, оценки достаточности
текущих мероприятий по обеспечению качества, определения
корректирующих мероприятий.
Тестирования и верификации требований и спецификаций.
Непосредственно процесса тестирования продукта.
Анализа результатов тестирования, составления отчетов и других
документов.
Квалификационные требования к специалисту по обеспечению качества, как
правило к QA – менеджеру достаточно требовательны, идеальный QA-
менеджер должен иметь не только управленческие навыки, но и богатый,
разносторонний опыт в:
Разработке ПО и управлении разработкой ПО – понимание того, чем
живет разработка. Проблематику сферы, понимание кода и особенностей
реализаций, стека технологий. Умение говорить на «одном языке» с
техническими специалистами.
36
Аналитике – уметь видеть взаимосвязи, противоречия, достаточность тех
или иных спецификаций, требований и их «тонкие» места.
Продакт-менеджменте – понимать требования рыночного сегмента,
видеть продукт под разными ракурсами, понимать предметную область,
анализировать решения конкурентов.
Руководстве проектами – иметь целостное восприятие всех частей
проекта, понимание сроков, целей, этапов и итераций жизненного цикла
проекта.
Исходя из вышесказанного, становится понятно, что QA помимо
непосредственного тестирования и оценки качества продукта, представляет
собой ряд как организационных мероприятий по планированию и
формированию стратегии управления качеством, так и подготовительных и
далее аналитических активностей. Правильное использование данного
арсенала, позволяет добиваться высокого качества продукта и
непосредственно всего процесса управления качеством, а равно и
обеспечения прозрачности в отношении вопросов качества и развития
продукта.
Quality control - Внутри QA находится QC. Фактически это проверка
актуального состояния объекта тестирования с помощью таких критериев,
как:
Степень готовности продукта к передаче в промышленную эксплуатацию
(т.е. релиза продукта).
Соответствие продукта заявленным требованиям.
Соответствие заявленному уровню качества проекта / продукта.
37
Из этого можно сделать вывод, что основной задачей QC-менеджера является
сосредоточение на качестве промежуточных и конечных результатов
разработки. Контролируется это обычно следующим образом (например):
Проверяется соответствие функционала заявленным требованиям в
определенных точках временной шкалы.
Анализируется документация на соответствие стандартам написания,
содержания и формата.
Делается ревью кода применительно к соответствию стандартам
разработки внутри организации, архитектурной документации,
требованиям безопасности и т.д.
Рассчитываются метрики качества, принятые в проекте.
То есть, цель мероприятий QC заключается в предоставлении актуальных
и своевременных срезов по качеству на основе различных методик его
расчета в зависимости от этапа разработки продукта, количества и
приоритета найденных дефектов, стратегий тестирования и иных трендов в
разрезе управления качеством в проекте.
Тестирование – это проверка соответствия создаваемого продукта
требованиям, осуществляемая путем анализа работы продукта в специальных
условиях, выбранных определенным образом.
Общая схема тестирования выглядит примерно так:
1. Специалист по тестированию получает продукт и/или требования на
входе.
2. Создает тесты (тут важно заметить, что функции тест-дизайна не всегда
делегируются тестировщикам. Часто, данные функции передаются тест-
38
лидам или отдельным специалистам с навыками тест-дизайна, который по
факту является отдельной экспертизой, либо передаются на уровень тест-
менеджеров, специалистов, обеспечивающих непосредственно управление
тестировщиками. В очень редких случаях, разработка тестов может
переходить на уровень QA менеджера или аналитиков проекта) и
наблюдает за поведением программы в тех или иных условиях.
3. В результате выполнения тестов, тестировщик получает данные о
соответствиях и несоответствиях поведения продукта спецификациям.
После чего он документирует это в виде описания дефектов, заполнения
тестовой документации и т.п., в зависимости от принятых в проекте
правил.
4. Полученная информация используется для улучшения и изменения
продукта. Передается «выше» по процессу.
В самом процессе тестирования специалист управляет выполнением
программы и создает необходимые условия путем заранее определенных
воздействий. Наблюдает за поведением продукта, сравнивает фактическое
поведение с ожидаемой ситуацией.
Специалист по тестированию умеет определить, чем вызвана ошибка,
или по крайней мере знает, где и как искать причину. В том числе
стандартной практикой является использование вспомогательного
инструментария и внутренних возможностей платформы разработки,
контроль журналов приложения, работа с БД и т.п. В зависимости от проекта.
Комплексное применение тех или иных подходов и практик в
тестировании и управлении качеством, позволяет обеспечить оптимальный
баланс между сроками и ресурсами тестирования, а равно и стоимостью
процесса как такового, соблюсти заданные критерии качества конечного
39
продукта. Необходимость использования той или иной практики, а равно и
комплекса таких практик, следует определять индивидуально, принимая во
внимание множество факторов из разных областей разработки,
сопровождения и эксплуатации продукта. Именно для этого и существуют
процессы управления качеством программного продукта (QA).
Ознакомившись со схемой ниже, можно получить основную (но не
исчерпывающую) картину многообразия мира тестирования (рисунок 3).
Рисунок 3 Виды тестирования
Как можно увидеть, вариантов достаточно. Каждый вид тестирования
имеет свои собственные подходы и практики, нюансы и рекомендации.
Определить весь спектр необходимых видов тестирования для конкретного
проекта под силу только опытным профессионалам, и об этом стоит помнить,
когда в проекте возникает необходимость в тестировании и управлении
качеством.
Очень часто можно услышать: «Наш продукт написан с
использованием современных технологий и практик», «У нас много
тестировщиков, они прокликивают каждый шаг», «У нас лучшая техническая
поддержка и лучшие программисты». Но нужно понимать, что написать
40
красивый код, использовать самые современные технологии и
протестировать силой «многих тестировщиков» - к сожалению, бывает
недостаточно, для оправдания ожиданий заказчика. На современном рынке
ПО, все важнее становится качество выполненной работы. Ее соответствие
требованиям клиента, причем не всегда явным требованиям.
Управление качеством это не просто тестирование, и уровень
компетенций специалистов, задействованных в решении задач по
обеспечению качества продукта – не исчерпывается знаниями о том, что
нужно нажать на определенные кнопки в заданное время. Именно системный
подход к управлению качеством помогает заглянуть вглубь проблематики
связанной с причинами срывов сроков, дефектов и недовольства клиентов.
Системный подход, «приправленный» профессионалами своего дела,
позволяет минимизировать риск возникновения негативных ситуаций в
будущем, сделав процесс разработки программного продукта прозрачным с
точки зрения качества. А главное, о чем не нужно забывать – позволит
увеличить удовлетворенность клиентов, принесет уверенность в продукте и
расчетную прибыль.
41
Глава 2. Исследование работы ИТ-подразделения компании
ЗАМПА
2.1 Обзор деятельности компании ЗАМПА
Компания ЗАМПА (ZamPa) работает на Российском рынке с 2007 года.
Род деятельности – разработка программного обеспечения для внешних
заказчиков на территории ЕС и России. В большей степени, проекты
компании связанны с написанием программного обеспечения для работы с
системами дальнопольной радиочастотной идентификации (RFID),
применяемой в решениях для транспортной и складской логистики. До 2007
года компания была представлена только на рынке ЕС, а именно в Польше,
где в период с 1998г по 2007г занималась оказанием консультационных услуг
в сфере международной транспортной логистики. В 2007 году компания
приняла стратегическое решение по старту нового направления в виде
разработки программного обеспечения для своих клиентов на территории
ЕС, и так же основала Российское представительство, разместив головной
офис в Калининграде. С 2010 года компания ЗАМПА полностью перешла
под управление российского менеджмента и занимается только разработкой
программного обеспечения «под заказ» в сфере складской и транспортной
логистики с применением технологий радиочастотной идентификации. В
2012 году компания релоцировалась в Москву.
Стратегической целью компании является создание качественных
программных продуктов, их поддержка и доработка в рамках контрактов на
сопровождение, расширение клиентской базы, выход на рынки США и
восстановление утраченных позиций в ЕС, так как с 2010 года основной
фокус компании был сосредоточен на российском рынке, а позиции на рынке
ЕС практически утрачены. По состоянию на 2018 год, в компании ЗАМПА
работает 38 человек, из которых 20 – разработчики ПО, 1 – руководитель ИТ-
42
подразделения, 1 – системный администратор, 2 – специалиста технической
поддержки - инженера, 2 – сотрудника бухгалтерии, 4 – аналитика, 1 – юрист,
4 – менеджера по продажам, 1 – офис менеджер, 2 – управляющих партнера
(один из низ генеральный директор).
Отдельно следует заметить, что начиная с 2016 года руководство
компании уволило двух человек, занимавших в разное время позицию ИТ-
директора компании и системного администратора, указывая как основную
причину – неспособность наладить работу ИТ-подразделения и добиться
«прозрачности» работы ИТ-подразделения для бизнеса.
2.2 Методика обследования
Обследование и анализ организации и работы ИТ-подразделения
проводился с использованием следующих методов:
Анализ существующих документов на каждый процесс или
систему;
Интервьюирование всех сотрудников компании с целью
получения максимальной информации по реальному положению
дел как внутри ИТ-подразделения, так и с точки зрения
коммуникаций с ИТ-подразделением;
Наблюдение. Обследование на рабочих местах в офисе, при этом
происходит наблюдение за участниками рабочего процесса, за
тем, как они выполняют свои рабочие функции, изучаются
рабочие процессы;
Технический анализ существующих аппаратных платформ в
компании на предмет их соответствия предъявляемым бизнесом
требований к надежности, безопасности и доступности;
43
Анализ существующих программных решений, применяемых в
компании на предмет их соответствия предъявляемым бизнесом
требований к надежности, безопасности и доступности;
Изучение отзывов пользователей программного обеспечения,
разработанного компанией;
Так как более половины разработчиков программного обеспечения
работают удаленно, использование методики наблюдения оказалось не
достаточным. Для анализа работы сотрудников занимающихся разработкой
программного обеспечения и работающих из других локаций, применялись
методы анализа исходного кода, трассировка действий разработчиков в
корпоративной сети предприятия и в системе контроля версионности
исходного кода.
Результаты проведенного обследования были донесены до управления
компании, большая часть упомянутых результатов приведена в параграфах
2.3 – 2.7 данной главы, порядка 20% информации, полученной в рамках
обследования работы ИТ-подразделения предприятия не вошли в данную
работу, так как составляют коммерческую тайну.
2.3 Задачи, стоящие перед ИТ-подразделением компании (ЗАМПА)
К моменту обследования ИТ-подразделения компании, на предприятии
не имелось каких-либо формальных документов, анализ которых мог бы дать
сведения о задачах, стоящих перед ИТ-подразделением в компании ЗАМПА.
Посредством проведения интервью с управляющими партнерами компании и
руководителем ИТ-подразделения, была получена информация, которая
позволила сформулировать следующее:
Основной целью ИТ-подразделения компании ЗАМПА (далее –
Компании) является эффективное управление информационными ресурсами
Компании, осуществляемое через поддержку и развитие информационных
44
ресурсов и средств вычислительной техники, а также средств связи и
коммуникаций, необходимых для выполнения сотрудниками Компании
своих задач и должностных обязанностей. А также, с учетом того, что в ИТ-
подразделение Компании входят разработчики программного обеспечения, и
фактически к функциям ИТ-подразделения добавлены функции по
разработке программного обеспечения, то от ИТ-подразделения так же
требуется обеспечить разработку качественного программного обеспечения и
его дальнейшую поддержку.
Основными задачами ИТ-службы компании являются:
- организация, поддержка и развитие комплекса поддержки
пользователей - сотрудников Компании;
- организация, поддержка и развитие локальной сети компании,
отвечающей требованиям бизнеса;
- организация, поддержка и развитие телефонных и Интернет
коммуникаций Компании;
- организация, поддержка и развитие информационных ресурсов
Компании;
- организация, поддержка и развитие процесса разработки
программного обеспечения в Компании;
- организация, поддержка и развитие процесса обеспечения качества
разрабатываемого программного обеспечения в Компании;
- организация, поддержка и развитие процесса обеспечения
технической поддержки разрабатываемого программного обеспечения
в Компании;
- организация, поддержка и развитие комплекса обеспечения
информационной безопасности Компании.