В этой статье я собираюсь поделиться некоторыми идеями, которые помогли создать качественные продукты. Хотя QA не является единственным лицом, ответственным за качество, но в большинстве случаев QA является последним человеком, который проводит предварительное / сквозное тестирование, прежде чем доставлять или демонстрировать его клиентам.

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

Тенденцией современности является изучение всё большего количества инструментов для автоматизации, но мышление QA важнее.

Как правило, QA должен уметь:

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

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

• Уметь тестировать на более детальном уровне и на соответствующем слое пирамиды тестирования (юнит, API, пользовательский интерфейс) для экономии времени и снижения затрат.

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

Насколько глубже QA должен погрузиться в детали архитектуры? 

Если мы говорим о модель С4 (Контекст, Контейнеры, Компоненты, Код), я бы посоветовал, чтобы кто-то знал, по крайней мере, о деталях уровня C3 продукта, над которым мы работаем. В итоге, исходя из потребности и интереса, можно перейти на уровень С4. 

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

1. Какое приложение мы разрабатываем и с какой целью? (например, микросервисы против монолитных архитектур, их преимущества и недостатки, различные паттерны проектирования). 

2. В случае микросервисов, как распределены разные сервисы? Это поможет нам составить представление о полном рабочем процессе, потенциальных точках отказа и зависимостях. 

3. Какова точка входа любого запроса от клиента? например, любой тип API-шлюза, прокси-сервера, брандмауэра, балансировщика нагрузки и т. д. 

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

4. Какие различные https-вызовы запускаются из внешнего интерфейса для любого действия пользователя и как приложение реагирует в случае какой-либо задержки или сбоя? Сбои обрабатываются изящно или нет? Есть правильные тайм-ауты или нет? Какие проверки проводятся на стороне сервера? 

5. Как разные сервисы взаимодействуют друг с другом (например, REST API или с помощью любого асинхронного режима с помощью Kafka или любого другого инструмента) и проверить производительность соответственно. 

6. Какой у нас фронтенд (например, микрофронтенд или нет)? Какое хранилище у нас есть во фронтенде для управления состояниями (например, Redux или любое другое — Как они работают?). Есть ли какие-либо проверки ввода во внешнем интерфейсе? 
Влияние любого сбоя серверной микросервиса на любую часть внешнего интерфейса/пользовательского интерфейса? 

7. Какая база данных у нас есть? Любые плюсы и минусы — с точки зрения функциональности, производительности и безопасности. Легко ли подвержена SQL-инъекции или нет? 

8. Как обеспечивается согласованность данных между службами? Используете общую базу данных или базу данных для каждой службы 

9. Как мы агрегируем ответы из разных сервисов — во фронтенде или бэкенде? 

10. Используем ли мы какое-либо кэширование?

• Ответ API на стороне клиента? 

• Серверная часть, любая CDN (сеть доставки контента)? 

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

11. Как работает аутентификация и авторизация, и как поддерживаются клиентские сессии? Это очень важно, поскольку мы не можем пойти на компромисс с несанкционированным доступом к какой-либо личной информации. 

12. Как используются файлы cookie? Есть ли какие-либо проблемы с безопасностью? 

13. Как мы развертываем? Количество используемых машин/подов(pods)/контейнеров? Как устроена стратегия масштабирования — горизонтальная или вертикальная? 

14. Должен быть осведомлен о ресурсах/сервисах, используемых различными облачными провайдерами. Есть ли какие-либо ограничения, узкие места с точки зрения производительности, безопасности, сети, зоны доступности? 

14. Механизм логирования приложений. Агрегируются ли журналы из разных контейнеров и разных служб, чтобы легко устранять любые проблемы? 

15. Как работает мониторинг и оповещение приложений в случае сбоя или если приложение неработоспособно. 

Заключение: Архитектура любого приложения развивается со временем. Как QA, мы должны быть в курсе любых изменений, сделанных с помощью любой стори или фичи. Обладая этими деталями, мы определенно можем проверить любую фичу / продукт на детальном уровне, потому что мы знаем, где что-то может сломаться.