Поиск  
Always will be ready notify the world about expectations as easy as possible: job change page
24 марта

Почему QA должен быть осведомлен об архитектуре проекта?

Почему QA должен быть осведомлен об архитектуре проекта?
Автор:
Источник:
Просмотров:
1603

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

Написать сообщение
Тип
Почта
Имя
*Сообщение