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

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

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

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

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

Модульное тестирование

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

Тестирование дыма

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

тестирование пользовательского интерфейса

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

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

Регрессионное тестирование

Регрессионное тестирование является чрезвычайно важной частью текущей разработки. Он предназначен для проверки того, не вызвали ли какие-либо изменения в одной части приложения проблемы в другой части. Например, изменение функции JavaScript, используемой для проверки формы «Свяжитесь с нами», потенциально может повлиять на формы, используемые при оформлении заказа. Из-за сложного характера любой платформы электронной коммерции проблемы регрессии не являются редкостью, поэтому разработка надежного плана регрессионного тестирования жизненно важна, чтобы гарантировать, что эти проблемы не повлияют на работу ваших пользователей.

УАТ

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

UAT часто путают или объединяют с SIT (тестирование системной интеграции), когда вы будете специально тестировать интеграцию между несколькими системами. SIT является частью сквозного тестирования, которое гарантирует, что все части цепочки работают правильно вместе.

Хороший UAT включает в себя создание тестовых случаев и планов тестирования. Как правило, они представляют собой набор сценариев (сценарий представляет собой набор задач, которые необходимо выполнить), которые выполняет ручной тестер и либо проходит, либо не проходит тест в зависимости от результата. Нередко сквозной план тестирования UAT включает более 500 тестовых случаев.

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

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

Тестирование безопасности

Иногда меня очень удивляет, как некоторые розничные продавцы недостаточно серьезно относятся к тестированию безопасности. Нет ничего необычного в том, что продавец не знает, когда он в последний раз проводил тест на проникновение на своей веб-платформе. Как правило, это те, кто еще не пострадал от кибератаки (или еще не знает, что подвергся удару). В нынешних условиях, когда киберпреступность продолжает расти по частоте и изощренности, особенно в связи с появлением GDPR в Европе, тестирование безопасности становится все более важным. Все веб-платформы электронной коммерции должны проходить тестирование на проникновение сторонним специалистом не реже одного раза в год, а в идеале два раза в год. Также желательно, чтобы ваше приложение регулярно сканировалось на наличие уязвимостей с помощью специального программного обеспечения, такого как Nessus. В Envoy мы еженедельно сканируем веб-платформы наших клиентов, чтобы обеспечить очень быстрое обнаружение уязвимостей в приложениях. По крайней мере, вы должны выполнять сканирование безопасности приложений перед каждым выпуском в производство. Нет смысла ждать 6 месяцев до следующего теста на проникновение, когда вы представили новую уязвимость в приложении.

Тестирование производительности

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

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

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

Хотя приведенный выше список не является исчерпывающим, вы можете видеть, что объем тестирования в рамках разработки программного обеспечения может быть очень большим и сложным. Каждый тип тестирования требует времени и усилий, и вы не должны просто предполагать, что все это делается стандартно без дополнительной оплаты. Компании, уделяющие большое внимание тестированию, будут выделять на тестирование до 40% времени любого проекта, что может оказаться очень неожиданным. Хорошее тестирование может снизить риск проекта и может окупиться в долгосрочной перспективе, поскольку оно приведет к уменьшению количества ошибок, повышению производительности и улучшению общего опыта для ваших клиентов.