Сообщение администратору
Имя:
Почта:
Сообщение:
Вход на сайт
Логин:
Пароль:

Поддержка  •  Дневник  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate  •  Рекомендованное  •  Написать администратору Гости: 5    Участники: 1 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
RSS-лента
Поделиться ссылкой:
Каталог


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

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


Почему QA должен быть осведомлен об архитектуре проекта?
Добавлено: Пн 30.10.2023 • Sergeant
Автор: ProQualityCommunity
Источник: источник
Просмотров: 487
Комментарии: 0


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



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.

Новое
3D рисунки на асфальте 09:11
3D рисунки на асфальте
Настоящие бриллианты теперь можно создавать с нуля в лаборатории всего за 15 минут вчера, 17:54
Настоящие бриллианты теперь можно создавать с нуля в лаборатории всего за 15 минут
5 вкусных салатов с курицей 2 дня назад, 09:00
5 вкусных салатов с курицей
Митболы в густом пикантном соусе 2 дня назад, 02:31
Митболы в густом пикантном соусе
Почему W-образные моторы уходят в прошлое, если они были лучше V-образных Пн 02.12.2024
Почему W-образные моторы уходят в прошлое, если они были лучше V-образных
20 простых и очень вкусных салатов с кальмарами Сб 30.11.2024
20 простых и очень вкусных салатов с кальмарами
Вирусы на Android: подробное руководство по обеспечению безопасности Пн 25.11.2024
Вирусы на Android: подробное руководство по обеспечению безопасности
15 интересных салатов со свежими огурцами Сб 23.11.2024
15 интересных салатов со свежими огурцами
Зал короля Артура оказался неолитическим загоном для скота Пн 18.11.2024
Зал короля Артура оказался неолитическим загоном для скота
15 действительно вкусных салатов с крабовыми палочками Сб 16.11.2024
15 действительно вкусных салатов с крабовыми палочками
Книги
Blazor in Action Вт 04.06.2024
Blazor in Action
Год: 2022
Security for Containers and Kubernetes Вт 28.05.2024
Security for Containers and Kubernetes
Год: 2023
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020
Разработано на основе BlackNight CMS
Release v.2024-11-16
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка
МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контентРекомендованное