Игорь Гунько: проблема отсутствия тестирования требований и почему IT компании сталкиваются с этим

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

Игорь Гунько – менеджер и консультант по обеспечению качества программного обеспечения (QA Manager) с многолетним опытом работы поделится своим секретом успеха. У него за спиной десятки успешных проектов и опыт сотрудничества в таких международных компаниях, как Ciklum, PM, Favbet. Программные продукты компаний в которых работал Игорь охватывают более 30 стран мира - США, Канада, страны Южной Америки, страны Европы, СНГ и страны Азии. Свою карьеру начал в 2009 году, а спустя 3 года уже занимал позицию QA Team Lead. Начиная с 2012 года стремительно поднялся по карьерной лестнице и стал экспертом своего дела.

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

Решение проблем с помощью тестирования требований

За годы работы на позициях QA Team Lead и QA Manager я являлся свидетелем того, как разные организации сталкивались с постоянной проблемой – отсутствием или ненадлежащим тестированием требований к программному обеспечению. Эта проблема, хотя широко распространена, часто недооценивается и не замечается, что приводит к ужасным последствиям. Не стоит думать, что такая проблема относится исключительно к малым IT компаниям и стартапам, вы будете очень удивлены, но и крупные международные IT компании с миллионными и миллиардными оборотами средств имеют ту же проблему, порой ярко выраженную, порой и скрытую. Позвольте мне поделиться некоторыми типичными проблемами, с которыми я сталкивался.

Неприемлемый сбор требований

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

Отсутствие сотрудничества

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

Изменение требований

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

Проблемы с документацией

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

Важность тестирования требований

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

Игорь, не могли бы вы поделиться примером проекта, где вы столкнулись с отсутствием проверки требований и проблемами, которые это вызвало?

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

Какие потенциальные риски пренебрежения тестированием требований при разработке программного обеспечения?

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

Как вы привлекаете тестировщиков к процессу тестирования требований и какова их роль в обеспечении качества программного обеспечения?

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

Можете ли вы привести конкретный пример того, как привлечение тестировщиков улучшило качество продукта из-за тестирования требований?

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

По вашему опыту, каков ключевой вывод о важности тестирования требований в разработке программного обеспечения?

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