В этой статье я собираюсь поделиться некоторыми идеями, которые помогли создать качественные продукты. Хотя 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, мы должны быть в курсе любых изменений, сделанных с помощью любой стори или фичи. Обладая этими деталями, мы определенно можем проверить любую фичу / продукт на детальном уровне, потому что мы знаем, где что-то может сломаться.
