Всем привет!
Меня зовут Саша Зубарчук. Я пришла в компанию Solid три года назад как Junior Manual QA. С того времени я стала автоматизатором, выпустила студентов первой QA School, с которой мы сотрудничали, и перешла на позицию Product Manager.
В этой статье расскажу об особенностях тестирования платежных систем и поделюсь опытом нашей команды: что мы тестируем, как, с какими вызовами сталкиваемся и как на них реагируем. Этот опыт будет полезен тем, кто выстраивает процесс тестирования на проекте — как QA-инженерам, так и Product/Project-менеджерам.
Я не буду углубляться в технику и конкретные инструменты, но расскажу об основной идее: как сделать процесс тестирования технически сложных сервисов максимально прозрачным и спокойным.
Из чего состоит и как работает платежный сервис
Solid — это шлюз, который позволяет компаниям во всем мире принимать онлайн-платежи клиентов разными способами: от банковских карт и электронных кошельков до PayPal и Alipay.
Во всей этой истории есть четыре основных игрока:
Упрощенно это выглядит так:
Проще говоря, мы помогаем мерчантам монетизироваться и зарабатывать деньги.
У вас мог возникнуть вопрос: почему мерчанты выбирают Solid, если можно напрямую работать с банками? Все просто: 1) банков много, и каждый из них имеет свои специфики — объединяя разные банки из разных стран в единую инфраструктуру, мы добиваемся максимальных конверсий и выручки; 2) у нас есть огромная экспертиза в платежных логиках и антифроде; 3) кроме банковских платежей, мы принимаем все альтернативные способы оплаты, популярные в том или ином регионе, и 4) мы дешевле.
Начнем с первого пункта — что же это за особенности проведения платежей в разных странах? Например, в США, как ни странно, вы не сможете совершить оплату так же просто, как в Украине — используя всего лишь карточные данные. Там банки обязаны проверять дополнительные данные плательщика, такие как платежный адрес и почтовый индекс.
Подобных нюансов — множество. Как и альтернатив карточным платежам. В Нидерландах и Германии, например, люди любят пользоваться локальными интернет-кошельками. Самые популярные способы оплаты в Китае — Alipay, WeChat Pay и UnionPay. А в Нигерии, чтобы оплатить товар в интернете, пользователи идут в банк с наличкой!
Мы принимаем все популярные платежи, без исключения — от банковских карточек до PayPal, электронных кошельков, Google Pay, Apple Pay или SMS. С помощью Solid, мерчант получает доступ к работе со всеми видами оплаты в одной интеграции. Кроме того, шлюз имеет собственную защиту от мошенничества, систему роутинга платежа, инструмент предотвращения необоснованных чарджбеков и многое другое.
К Solid подключено много мерчантов. Поэтому мы отвечаем не только за свой бизнес, но и за монетизацию всех подключенных к нам клиентов. Если что-то пойдет не так на нашей стороне, мы подводим слишком много компаний. И наоборот — тестируя и улучшая свой платежный сервис, мы улучшаем продукты других бизнесов.
К сожалению, помимо успешного платежа могут возникать ошибки — как системные, так и пользовательские. Важно понимать, что никогда и ни на какой локации не будет проходить 100% платежей успешно. Но со своей стороны мы обязаны сделать все, чтобы конверсия платежей была максимально возможной.
Тестировать платежный шлюз — не шаблонная задача, поскольку это довольно сложный механизм из десятков микросервисов и взаимосвязей. Мы все тестируем в три этапа. Сначала проверяем каждую задачу на изолированном окружении, потом объединяем их и проверяем в релиз-кандидате на стейдже, смотрим, как все работает в интеграции, потом релизим и еще раз тестируем все на продакшене.
Давайте подробнее остановимся на том, что конкретно нам приходится тестировать.
Платежная система состоит как из API, так и веб-интерфейсов. Кардинальных отличий в тестировании API и веба для платежных систем, в отличии от любых других продуктов, — нет. Главная особенность — в тестировании конкретно платежей для разных регионов, а также всех вспомогательных сервисов.
Кажется, что тестировать платеж несложно: нужно совершить оплату, проверить, что деньги списались с одного счета, и были зачислены на другой. Но есть нюансы. Тестировщики должны знать особенности платежей в разных странах, а иногда и нюансы местного законодательства и банковской регуляции.
Второй момент — это разные типы платежей: подписки, первый платеж, авторизация (заморозка денег на счету), платеж через электронный кошелек. Для каждого из них есть своя специфика тестирования.
Особое внимание стоит уделить работе с валютами: не все они имеют дробную часть. Например, у гривни есть копейки, а у чилийского песо — нет. Если вы передадите в Украине сумму платежа 100, то банк спишет 1 грн, то есть 100 копеек. А в Чили это будет означать 100 песо. Как видите, такие моменты нельзя упускать.
Все наши клиенты (веб, мобильные приложения, а также back-end сервисы) общаются с нами при помощи Solid API. Сам же шлюз располагается на отдельном кластере и ведет общение с различными системами (антифрод, токенизатор, банки и т.д.).
Разработчики Solid занимаются решением задач нескольких видов (и все эти задачи в итоге попадают в распоряжение команды QA):
Помимо задач, которые приходят непосредственно от разработчиков, мы получаем и другие: это проверка всех данных и UAT при подключении новых мерчантов, проверка задач от команды DevOps, настройка антифрод-правил.
Если обобщить, то все, что мы тестируем, можно разбить на следующие категории:
Backend сервисы Solid:
Интеграция с банками:
Альтернативные (не карточные) способы оплаты:
Админки:
Пользовательские интерфейсы:
Другое:
При работе с масштабными IT-решениями, такими как платежные провайдеры, нужно постоянно тестировать не только работу отдельных элементов функционала, но и их взаимодействие. Без автоматизации не получится. Если какой-то сервис не покрыт автотестами — сбоев не избежать. Прогоняйте автотесты при каждой возможности. Вылили задачу на окружение — запустите тесты. Слили несколько задач в релиз-кандидат — запустите тесты.
В нашем случае это происходит примерно так:
Прогон автотестов занимает время, и потому мы всегда стремимся максимально оптимизировать этот процесс. Тесты запускаются многопоточно, также они разделены на задачи по важности.
У нас есть минимальный набор тестов, который проверяет основные функциональности Solid для процессинга платежей — он проходит меньше, чем за минуту. На все остальные тесты Solid API и других микросервисов уходит порядка 3-4 минут. Тесты по UI, конечно, проходят слегка медленнее. Но и тут мы не прекращаем работу над улучшением и оптимизацией.
Почему изолированное тестирование — не лучший вариант при тестировании платежей? Расскажу на нашем кейсе с антифродом.
У каждого мерчанта Solid подключен антифрод-аккаунт с настройкой правил, как они должны срабатывать. Например, если у мерчанта пользователь за сутки провел больше трех платежей, то четвертый мы блокируем. Или если одной и той же карточкой делают платежи более пяти пользователей — тоже блокируем и добавляем в черный список. Мы покрывали это автотестами, но столкнулись с проблемой.
Изначально мы продублировали все правила на тестовый аккаунт, имитировали мошеннические действия, и тесты вроде как срабатывали. Но получилось так, что у самого мерчанта часто бывают ситуации, когда антифрод-правила комбинируются, например, сработало три из них.
Изолируя каждый платеж под каждое определенное правило, мы избавились от возможности комбинации правил и влияния других сервисов на проведение платежа.
Как мы делали каждый платеж: мы очищали тестовые данные, создавали все условия, чтобы платеж попал под определенное правило, и тогда оно срабатывало. Но не факт, что так будет и в рабочей среде, потому что никогда не будет идеальной ситуации, чтобы платеж попал под одно правило.
Мы решили подключить к тестовому мерчанту реальные антифрод-правила наших клиентов. Тогда они начали отрабатывать более четко. То есть, нужно было создавать не изолированные правила, а тестировать их в совокупности так, как они есть у конкретного клиента.
Сейчас клиенты Solid могут настроить антифрод-правила под себя. Потому что операции, которые похожи на мошенничество для одного мерчанта, могут быть нормой для другого.
Если человек совершает пять покупок за сутки в онлайн-магазине, то это норма: сначала понравился чехол для мобильного, потом блокнот и т.д. Но вот для fitness-приложений — это уже аномалия. Человек вряд ли будет покупать пять программ тренировок в день.
Автоматизация действительно помогает выстроить баланс: вручную проверяются только новые фичи и те сценарии, которые требуют человеческого внимания, все остальное — автоматизировано. Автоматизация поможет снизить как расходы на тестирование, так и риски, связанные с человеческим фактором.
Помимо непосредственной проверки работоспособности функционала, мы много времени уделяем тому, чтобы разработчики и менеджеры воспринимали реализуемый функционал одинаково. Кажется очевидным, но многие этим пренебрегают.
Все конфигурационные сервисы довольно сложные, они имеют огромный ряд возможностей и даже самые незначительные детали могут привести к тому, что сервис будет работать не так, как ожидалось.
У техники «раннего тестирования» есть сразу несколько преимуществ:
Действительно хорошая и структурированная внутренняя документация — половина успеха при тестировании. Несмотря на то, что практически весь функционал должен быть автоматизирован, мануальная работа никогда не сойдет на ноль.
Описание процессов тестирования разных функционалов, статьи с решением возможных проблем и различные мануалы ускоряют работу команды тестировщиков.
Мы в Solid создали собственную базу знаний. В ней описано, как работает каждый банк и альтернативный способ оплаты в разных локациях, какие типы оплат банк поддерживает, и как в принципе проходит платеж в том или ином регионе.
Такая база — емкая и сложная задача, которая стала для нас вызовом. Нужно было свести всю документацию воедино и доступно описать процессы. Зато теперь, когда к нам приходит новый сотрудник, не возникает никаких проблем. Сложно запомнить, как что-то должно работать с первого раза, а при наличии тестовой документации вариант ошибиться минимален. Понятная документация позволяет тестировщику точно определить, почему платеж не проходит: это ошибка или в этом банке такой тип платежа просто не должен работать.
Приведу еще один пример. Однажды мы меняли логотипы международных платежных систем на платежных формах. Различных дизайнов для наших клиентов у нас более 200. Для каждого дизайна может быть несколько конфигураций полей на форме. Например, для Бразилии добавляется дополнительное поле CPF — аналог нашего идентификационного кода.
Из-за нового размера логотипа некоторые поля на форме могли съехать, скрыться или стать некликабельными. Никто из команды тестирования Solid просто физически не может знать, как все 200 форм должны выглядеть.
Тестирование этой задачи было нервным, зато в результате мы создали базу знаний с эталонными видами форм для каждого нашего мерчанта, покрыли это автотестами и теперь никакие изменения, связанные с дизайнами, нам не страшны.
Напоследок расскажу маленький интересный факт из мира процессинга: доля деклайнов Restricted Card в Украине довольно низкая — 1-2%. То ли украинские банки так хороши во fraud prevention, то ли карточные данные украинских пользователей никто не хочет воровать…
Тем не менее, нет продукта с идеальными процессами разработки и тестирования, но в наших силах их улучшить. Ведь задача каждого бизнеса — выпустить качественный продукт. Кто еще, если не QA-инженеры, помогут в этом?
Буду рада, если поделитесь своими принципами хорошего процесса тестирования в комментариях.
Меня зовут Саша Зубарчук. Я пришла в компанию Solid три года назад как Junior Manual QA. С того времени я стала автоматизатором, выпустила студентов первой QA School, с которой мы сотрудничали, и перешла на позицию Product Manager.
В этой статье расскажу об особенностях тестирования платежных систем и поделюсь опытом нашей команды: что мы тестируем, как, с какими вызовами сталкиваемся и как на них реагируем. Этот опыт будет полезен тем, кто выстраивает процесс тестирования на проекте — как QA-инженерам, так и Product/Project-менеджерам.
Я не буду углубляться в технику и конкретные инструменты, но расскажу об основной идее: как сделать процесс тестирования технически сложных сервисов максимально прозрачным и спокойным.
Из чего состоит и как работает платежный сервис
Solid — это шлюз, который позволяет компаниям во всем мире принимать онлайн-платежи клиентов разными способами: от банковских карт и электронных кошельков до PayPal и Alipay.
Во всей этой истории есть четыре основных игрока:
- пользователь (он же покупатель);
- мерчант — любой бизнес, который продает в интернете свои товары/услуги и хочет принимать за них деньги;
- платежный шлюз — Solid;
- банк (эквайер) — финансовое учреждение, выполняющее транзакции с реальными деньгами.
Упрощенно это выглядит так:
Проще говоря, мы помогаем мерчантам монетизироваться и зарабатывать деньги.
У вас мог возникнуть вопрос: почему мерчанты выбирают Solid, если можно напрямую работать с банками? Все просто: 1) банков много, и каждый из них имеет свои специфики — объединяя разные банки из разных стран в единую инфраструктуру, мы добиваемся максимальных конверсий и выручки; 2) у нас есть огромная экспертиза в платежных логиках и антифроде; 3) кроме банковских платежей, мы принимаем все альтернативные способы оплаты, популярные в том или ином регионе, и 4) мы дешевле.
Начнем с первого пункта — что же это за особенности проведения платежей в разных странах? Например, в США, как ни странно, вы не сможете совершить оплату так же просто, как в Украине — используя всего лишь карточные данные. Там банки обязаны проверять дополнительные данные плательщика, такие как платежный адрес и почтовый индекс.
Подобных нюансов — множество. Как и альтернатив карточным платежам. В Нидерландах и Германии, например, люди любят пользоваться локальными интернет-кошельками. Самые популярные способы оплаты в Китае — Alipay, WeChat Pay и UnionPay. А в Нигерии, чтобы оплатить товар в интернете, пользователи идут в банк с наличкой!
Мы принимаем все популярные платежи, без исключения — от банковских карточек до PayPal, электронных кошельков, Google Pay, Apple Pay или SMS. С помощью Solid, мерчант получает доступ к работе со всеми видами оплаты в одной интеграции. Кроме того, шлюз имеет собственную защиту от мошенничества, систему роутинга платежа, инструмент предотвращения необоснованных чарджбеков и многое другое.
Зачем тестировать платежные системы и риски не тестирования
К Solid подключено много мерчантов. Поэтому мы отвечаем не только за свой бизнес, но и за монетизацию всех подключенных к нам клиентов. Если что-то пойдет не так на нашей стороне, мы подводим слишком много компаний. И наоборот — тестируя и улучшая свой платежный сервис, мы улучшаем продукты других бизнесов.
К сожалению, помимо успешного платежа могут возникать ошибки — как системные, так и пользовательские. Важно понимать, что никогда и ни на какой локации не будет проходить 100% платежей успешно. Но со своей стороны мы обязаны сделать все, чтобы конверсия платежей была максимально возможной.
Тестировать платежный шлюз — не шаблонная задача, поскольку это довольно сложный механизм из десятков микросервисов и взаимосвязей. Мы все тестируем в три этапа. Сначала проверяем каждую задачу на изолированном окружении, потом объединяем их и проверяем в релиз-кандидате на стейдже, смотрим, как все работает в интеграции, потом релизим и еще раз тестируем все на продакшене.
Давайте подробнее остановимся на том, что конкретно нам приходится тестировать.
Особенности тестирования платежных систем
Платежная система состоит как из API, так и веб-интерфейсов. Кардинальных отличий в тестировании API и веба для платежных систем, в отличии от любых других продуктов, — нет. Главная особенность — в тестировании конкретно платежей для разных регионов, а также всех вспомогательных сервисов.
Кажется, что тестировать платеж несложно: нужно совершить оплату, проверить, что деньги списались с одного счета, и были зачислены на другой. Но есть нюансы. Тестировщики должны знать особенности платежей в разных странах, а иногда и нюансы местного законодательства и банковской регуляции.
Второй момент — это разные типы платежей: подписки, первый платеж, авторизация (заморозка денег на счету), платеж через электронный кошелек. Для каждого из них есть своя специфика тестирования.
Особое внимание стоит уделить работе с валютами: не все они имеют дробную часть. Например, у гривни есть копейки, а у чилийского песо — нет. Если вы передадите в Украине сумму платежа 100, то банк спишет 1 грн, то есть 100 копеек. А в Чили это будет означать 100 песо. Как видите, такие моменты нельзя упускать.
Что нужно тестировать в платежных системах
Все наши клиенты (веб, мобильные приложения, а также back-end сервисы) общаются с нами при помощи Solid API. Сам же шлюз располагается на отдельном кластере и ведет общение с различными системами (антифрод, токенизатор, банки и т.д.).
Разработчики Solid занимаются решением задач нескольких видов (и все эти задачи в итоге попадают в распоряжение команды QA):
- разработка нового функционала (новые платные сервисы, например, система подписок, различные фичи для мерчантов, новые платежные формы);
- разработка новых интеграций с платежными сервисами (PayPal, Alipay сервисы токенизации Visa и Mastercard);
- актуализация и ревью имеющихся интеграций: банки постоянно обновляют свое API, поэтому раз в месяц мы проводим ревью;
- задачи по оптимизации (увеличение скорости ответа мерчанту, уменьшение времени загрузки формы);
- задачи, напрямую не связанные с процессингом (например, админка для мерчантов, сложная финансовая система и сайт-витрина);
- исправление багов.
Помимо задач, которые приходят непосредственно от разработчиков, мы получаем и другие: это проверка всех данных и UAT при подключении новых мерчантов, проверка задач от команды DevOps, настройка антифрод-правил.
Если обобщить, то все, что мы тестируем, можно разбить на следующие категории:
Backend сервисы Solid:
- антифрод;
- сервис подписок;
- платежный роутинг;
- система учета и финансового контроллинга;
- интеграции с внешними сервисами.
Интеграция с банками:
- проверка корректности работы с валютами;
- проверка разных типов платежей (первый платеж по карточным данным, платеж по токену, возвраты средств, заморозка денег и т.д.);
- обработка нотификаций.
Альтернативные (не карточные) способы оплаты:
- проверка проведения платежа;
- проверка особенностей локации.
Админки:
- внутренняя админка (все то, что помогает аналитикам Solid запускать A/B тесты по конверсии платежной формы, настраивать правила для антифрода);
- админка для мерчантов.
Пользовательские интерфейсы:
- внешний вид платежных форм и страниц;
- отображается ли форма на языке конкретного региона (платежная форма Solid доступна на всех языках мира);
- правильность отображения суммы и валют;
- отслеживание действий пользователя на формах;
- статус страницы.
Другое:
- UAT при подключении нового мерчанта к Solid;
- задачи от отдела рисков по проверке новых конфигураций;
- исследования работоспособности функционала (например, работает ли Apple Pay в WKWebView).
Шаги к успешному тестированию
Автоматизация
При работе с масштабными IT-решениями, такими как платежные провайдеры, нужно постоянно тестировать не только работу отдельных элементов функционала, но и их взаимодействие. Без автоматизации не получится. Если какой-то сервис не покрыт автотестами — сбоев не избежать. Прогоняйте автотесты при каждой возможности. Вылили задачу на окружение — запустите тесты. Слили несколько задач в релиз-кандидат — запустите тесты.
В нашем случае это происходит примерно так:
- разработчики самостоятельно запускают тесты при реализации задачи;
- тестировщики запускают тесты при тестировании задачи на изолированном окружении;
- тесты автоматически запускаются, когда происходит сборка новой версии билда;
- автотесты постоянно запускаются на Prod-окружении.
Прогон автотестов занимает время, и потому мы всегда стремимся максимально оптимизировать этот процесс. Тесты запускаются многопоточно, также они разделены на задачи по важности.
У нас есть минимальный набор тестов, который проверяет основные функциональности Solid для процессинга платежей — он проходит меньше, чем за минуту. На все остальные тесты Solid API и других микросервисов уходит порядка 3-4 минут. Тесты по UI, конечно, проходят слегка медленнее. Но и тут мы не прекращаем работу над улучшением и оптимизацией.
Почему изолированное тестирование — не лучший вариант при тестировании платежей? Расскажу на нашем кейсе с антифродом.
У каждого мерчанта Solid подключен антифрод-аккаунт с настройкой правил, как они должны срабатывать. Например, если у мерчанта пользователь за сутки провел больше трех платежей, то четвертый мы блокируем. Или если одной и той же карточкой делают платежи более пяти пользователей — тоже блокируем и добавляем в черный список. Мы покрывали это автотестами, но столкнулись с проблемой.
Изначально мы продублировали все правила на тестовый аккаунт, имитировали мошеннические действия, и тесты вроде как срабатывали. Но получилось так, что у самого мерчанта часто бывают ситуации, когда антифрод-правила комбинируются, например, сработало три из них.
Изолируя каждый платеж под каждое определенное правило, мы избавились от возможности комбинации правил и влияния других сервисов на проведение платежа.
Как мы делали каждый платеж: мы очищали тестовые данные, создавали все условия, чтобы платеж попал под определенное правило, и тогда оно срабатывало. Но не факт, что так будет и в рабочей среде, потому что никогда не будет идеальной ситуации, чтобы платеж попал под одно правило.
Мы решили подключить к тестовому мерчанту реальные антифрод-правила наших клиентов. Тогда они начали отрабатывать более четко. То есть, нужно было создавать не изолированные правила, а тестировать их в совокупности так, как они есть у конкретного клиента.
Сейчас клиенты Solid могут настроить антифрод-правила под себя. Потому что операции, которые похожи на мошенничество для одного мерчанта, могут быть нормой для другого.
Если человек совершает пять покупок за сутки в онлайн-магазине, то это норма: сначала понравился чехол для мобильного, потом блокнот и т.д. Но вот для fitness-приложений — это уже аномалия. Человек вряд ли будет покупать пять программ тренировок в день.
Автоматизация действительно помогает выстроить баланс: вручную проверяются только новые фичи и те сценарии, которые требуют человеческого внимания, все остальное — автоматизировано. Автоматизация поможет снизить как расходы на тестирование, так и риски, связанные с человеческим фактором.
Тестирование на этапе технического задания
Помимо непосредственной проверки работоспособности функционала, мы много времени уделяем тому, чтобы разработчики и менеджеры воспринимали реализуемый функционал одинаково. Кажется очевидным, но многие этим пренебрегают.
Все конфигурационные сервисы довольно сложные, они имеют огромный ряд возможностей и даже самые незначительные детали могут привести к тому, что сервис будет работать не так, как ожидалось.
У техники «раннего тестирования» есть сразу несколько преимуществ:
- команда разработки правильно поймет задание, и мы не будем тратить время на фиксы;
- хорошо написанное техническое задание — это 70% хорошей документации;
- благодаря тому, что команда тестирования заранее ознакомилась с ТЗ, тестовые сценарии также продуманы заранее, и в момент, когда реализованная задача приходит на тест, процесс идет быстрее.
Хорошая тестовая документация
Действительно хорошая и структурированная внутренняя документация — половина успеха при тестировании. Несмотря на то, что практически весь функционал должен быть автоматизирован, мануальная работа никогда не сойдет на ноль.
Описание процессов тестирования разных функционалов, статьи с решением возможных проблем и различные мануалы ускоряют работу команды тестировщиков.
Мы в Solid создали собственную базу знаний. В ней описано, как работает каждый банк и альтернативный способ оплаты в разных локациях, какие типы оплат банк поддерживает, и как в принципе проходит платеж в том или ином регионе.
Такая база — емкая и сложная задача, которая стала для нас вызовом. Нужно было свести всю документацию воедино и доступно описать процессы. Зато теперь, когда к нам приходит новый сотрудник, не возникает никаких проблем. Сложно запомнить, как что-то должно работать с первого раза, а при наличии тестовой документации вариант ошибиться минимален. Понятная документация позволяет тестировщику точно определить, почему платеж не проходит: это ошибка или в этом банке такой тип платежа просто не должен работать.
Приведу еще один пример. Однажды мы меняли логотипы международных платежных систем на платежных формах. Различных дизайнов для наших клиентов у нас более 200. Для каждого дизайна может быть несколько конфигураций полей на форме. Например, для Бразилии добавляется дополнительное поле CPF — аналог нашего идентификационного кода.
Из-за нового размера логотипа некоторые поля на форме могли съехать, скрыться или стать некликабельными. Никто из команды тестирования Solid просто физически не может знать, как все 200 форм должны выглядеть.
Тестирование этой задачи было нервным, зато в результате мы создали базу знаний с эталонными видами форм для каждого нашего мерчанта, покрыли это автотестами и теперь никакие изменения, связанные с дизайнами, нам не страшны.
***
Напоследок расскажу маленький интересный факт из мира процессинга: доля деклайнов Restricted Card в Украине довольно низкая — 1-2%. То ли украинские банки так хороши во fraud prevention, то ли карточные данные украинских пользователей никто не хочет воровать…
Тем не менее, нет продукта с идеальными процессами разработки и тестирования, но в наших силах их улучшить. Ведь задача каждого бизнеса — выпустить качественный продукт. Кто еще, если не QA-инженеры, помогут в этом?
Буду рада, если поделитесь своими принципами хорошего процесса тестирования в комментариях.
