РУБРИКА «ЭКСПЕРТЫ SOLAR INRIGHTS»: Тестировщик – это адвокат пользователя!

Тестирование программного обеспечения (ПО) является неотъемлемой частью жизненного цикла разработки ПО. Любая проблема с функциональностью в программном обеспечении может привести к серьезным последствиям, таким как потеря времени, ресурсов, репутации, а также к значительным затратам на исправление некачественной разработки. Поэтому своевременная проверка того, что программный продукт выполняет заявленные функции и не содержит критических ошибок в основных сценариях использования, является очень важной задачей.

О важности процесса тестирования и о работе подразделения тестирования в Solar inRights рассказывает руководитель отдела тестирования Алёна Зубкова.

Что такое тестирование ПО?

Тестирование ПО – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением.

В широком смысле слова тестирование – это одна из техник контроля качества, включающая активности:

• По планированию работ
• Разработке тестов
• Выполнению самого тестирования
• Анализу полученных результатов

Если говорить о целях тестирования, то это прежде всего повышение вероятности:

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

Помимо этого, тестирование предоставляет нам актуальную информацию о состоянии системы на данный момент.

Чем грозит заказчику исключение тестирования из процесса поставки ПО?

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

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

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

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

Таким образом, тестирование дает нам уверенность в корректности и безопасности работы системы. А отсутствие такой уверенности обессмыслило саму ее разработку.

Почему сам разработчик не может проводить тестирование ПО?

У разработчика и тестировщика разный фокус на задачи. Основная задача разработчика – это реализовать по требованиям задачу/доработку. На этапе разработки пишутся свои автоматизированные тесты и проводится тестирование функционала. Кроме того, на этапе разработки можно проверить работоспособность с точки зрения взаимосвязанности функциональных модулей, но не бизнес-сценарии в комплексе.

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

На каких этапах жизненного цикла ПО необходим тестировщик?

Если говорить коротко, то на всех.

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

• Следующий этап – это непосредственно разработка ПО. Это основной этап работы тестировщика. На этом этапе разрабатываются тестовые сценарии (тест-кейсы), после чего они выполняются и фиксируются дефекты, если они есть. Это этап верификации, который подтверждает, что функционал работает так, как описано в требованиях, и не противоречит здравому смыслу, что тоже важно. Здесь основные инструменты тестировщика – тестовые сценарии и дефекты, с корректными приоритетами.

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

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

С какими артефактами работает тестировщик?

Артефакты подразделяются на две большие группы: то, что тестировщик получает на входе, – это результаты работы других коллег в рамках департамента, и то, что сам тестировщик производит в процессе труда.

Первая группа – это требования, инженерная документация, документация разработчиков и дизайн-проекты:

• Требования – это главный источник информации для тестировщика при работе с функционалом. И в процессе работы с требованиями сами требования будут подвергаться всесторонней верификации со стороны тестировщика.
• Инженерная документация используется тестировщиком, когда мы говорим о составлении тестовых сценариев, учитывающих интеграцию, а также она необходима, когда мы самостоятельно настраиваем систему при проведении тестирования.
• Разработческая документация используется для фиксации ограничений реализации и для того, чтобы обеспечить корректную работу тестировщика со скриптами и настройками.
• С дизайн-проектами, которые используются для тестирования UI, т. е. пользовательского интерфейса, мы сравниваем то, что мы фактически видим.

В процессе труда тестировщик создает следующие артефакты:

• Сквозные сценарии, которые проверяют, что, с одной стороны, разработанное решение снимает проблемы, а с другой – не создает новых.
• Помимо этого, есть простые тестовые сценарии, т. е. сценарии по требованиям. Они нужны для того, чтобы убедиться, что при различных вариантах использования системы она не ломается: полностью либо частично. Что те функции, которые были разработаны ранее, продолжают работать корректно, несмотря на то, что мы добавили новые функции.
• Также среди артефактов, которые создают тестировщики, следует упомянуть ПМИ (программа и методика испытаний), которая создается для подготовки к демонстрации функционала заказчику и основывается на базовом положительном сценарии использования системы.
• Также следует упомянуть об отчетах о тестировании, которые могут создаваться в разном виде в зависимости от проекта, от стейкхолдеров, от конкретных нужд.

Есть ли какие-то особенности в подходе к тестированию в Solar inRights?

Если говорить о нашем подходе, то, как я уже говорила, у нас тестировщик – это основной адвокат пользователя. Т. е. тестирование у нас помогает проконтролировать, что модуль, или отдельная функция, или вся система в целом решает проблемы и задачи заказчика. При этом наш опыт работы в различных процессах и методологиях, как гибких, так и классических, помогает нам выбирать инструментарий под нужды каждого конкретного проекта. Пожалуй, особенную роль здесь играет независимость тестирования. Я недавно обсуждала наш подход к тестированию с лидом разработки и услышала от него аналогию, что у нас есть «три ветви власти» по созданию решения: аналитик, как законодательная; разработка, как исполнительная, и тестирование, как судебная. Я думаю, что это очень удачное сравнение, которое справедливо отображает не только наш подход, но и его очевидные плюсы. Потому что система сдержек и противовесов – это хороший инструмент достижения общего блага не только в обществе в целом, но и в процессе создания ПО в частности.

Отличается ли тестирование IdM-систем от тестирования другого ПО?

Главная особенность в тестировании IdM-решений заключается в том, что оно строится на стыке профессии тестировщика, как изначально междисциплинарной сферы, и специфики нашего продукта. IdM-система – это априори сложный продукт, и его тестирование требует целого ряда навыков. И не только технических – hard skills, но и тех, которые принято назвать soft-skills. Управление доступом с помощью IdM – это управление доступом в интегрированных c нашим решением информационных системах. Это означает, что нам необходимы знания как теоретические, так и практические по работе конкретных систем (объектной модели, конфигурирования, скриптовых языков и т. д.). Наши доработки, которые могут изначально показаться простыми и очевидными, в итоге оказываются достаточно многогранными и требуют всеобъемлющего тест-анализа, применения различных техник тестирования, подходов, технических навыков. Помимо этого, важны навыки коммуникации, планирования, разрешения проблем, управления рисками. У нас тестировщик – это всегда командный игрок, причем достаточно самоотверженный.

На проектах IdM применяется ручное или автоматизированное тестирование?

Когда мы говорим о ручном и автоматизированном тестировании, я предпочитаю примять именно союз «и», потому что проблемы начинаются там, где потерян баланс. Часто в подходе к тестированию сознательно или неосознанно делается крен: или в сторону мануального тестирования, или автоматизированного тестирования. Мы в своей работе руководствуемся принципом разумной достаточности и считаем, что затраты на организацию автоматизированного тестирования и его поддержку должны быть оправданны и целесообразны. У нас, как правило, ручное тестирование нацелено на то, чтобы найти дефекты по сложным сценариям использования. Автотесты – это небольшой кластер проверок, который позволяет удостовериться в том, что в целом по основным сценариям система работает корректно, и облегчить регресc, это значительный набор проверок, который позволяет нам убедиться, что после внесения изменений система целиком работает корректно. Такой подход помогает нам экономить время и повышать мотивацию. Потому что тестировщики высвобождаются от рутинных задач по регреcсу для выполнения более сложной, интересной и творческой работы и своего развития.

В каких случаях выгодно применение автотестов?

Здесь нужно понять, через какое количество итераций начнет окупаться автоматизированное тестирование, т. е. окупятся затраты на его разработку, организацию и внедрение. Есть ряд требований к критериям, которым должны соответствовать сценарии тестирования для того, чтобы быть пригодными для автоматизации. Это сценарии частого использования или сценарии, по которым в ближайшее время не планируется изменений. У нас автоматизирована бо́льшая часть регресса, и это нам здорово помогает экономить время.

Можно ли переиспользовать автотесты из проекта в проект?

В зависимости от того, о каком проекте мы говорим. У нас есть два подхода. Есть типовые проекты, которые основаны на продуктовом ядре, и здесь, конечно, можно говорить о том, что часть автотестов может быть переиспользована для стандартных сценариев работы IdM. Но есть и уникальные крупномасштабные проекты со своими особенностями, для которых уже автотесты должны разрабатываться отдельно. В любом случае, даже если говорить не только о тестировании, всегда, когда можно что-то переиспользовать – подход, процесс, автотест, инструкции, компетенции и т. д., – нужно это делать. И мы к этому стремимся.

Вы используете стандартные или собственные практики и методики тестирования?

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

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

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

Какими качествами должен обладать тестировщик?

Главные качества — это адаптивность, любознательность и неравнодушие. Что людей толкает становиться тестировщиками? Я считаю, что это обостренное чувство справедливости, т. е. когда ты хочешь, чтобы все было правильно, чтобы мир становился лучше, и сам желаешь принимать активное участие в его улучшении.

Качества, которые можно назвать ключевыми для тестировщика в inRights – это заточенность на общее дело, на результат, на эффективные коммуникации внутри команды и на процессы. У нас отсутствует классическое противостояние между разработкой и тестированием, когда, например, тестировщик, найдя дефект, радуется. А мы слегка расстраиваемся, потому что наш подход к процессу производства заставляет нас понимать, сколько сил затрачено всей командой. Производство – это командная игра, и найденный дефект – это повод для всей команды подумать над тем, как в следующий раз на ранних этапах производства подобную ошибку не допустить. Этому способствует высокий уровень вовлеченности и личной ответственности тестировщика и значимость тестирования в процессе производства. У нас тестирование не формальное, оно встроено в систему обеспечения качества, влияет на него, и доводы тестирования учитываются и в целом в процессе, и в разработке конкретного функционала. Такое встречается не всегда и не везде. Это возможно, когда мы понимаем, что мы все в одной лодке и плывем к общей цели. Т. е. создаем продукт, за который мы можем испытывать гордость и радость от удовлетворения заказчика.