Audio/Video promotion
Место для рекламы
Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate Гости: 7    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Размещение рекламы
Каталог


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

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


Почему QA должен быть осведомлен об архитектуре проекта?
Добавлено: Пн 30.10.2023 • Sergeant
Автор: ProQualityCommunity
Источник: источник
Просмотров: 449
Комментарии: 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
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:

Новое
09:11
Креветки в соевом соусе на сковороде: 10 рецептов для настоящих гурманов
Напитки новой эры: лучшие американские и русские горящие коктейли Чт 29.02.2024
Напитки новой эры: лучшие американские и русские горящие коктейли
Задача по языку C#: Игра «Крестики Нолики» в консоли Пн 26.02.2024
Задача по языку C#: Игра «Крестики Нолики» в консоли
Вс 25.02.2024
10 способов вкусно приготовить креветки
Десять коктейлей с водкой Чт 22.02.2024
Десять коктейлей с водкой
Всё, что вам необходимо знать о Hi-Res Чт 22.02.2024
Всё, что вам необходимо знать о Hi-Res
Pagination in a .NET Web API with EF Core Ср 21.02.2024
Pagination in a .NET Web API with EF Core
Жесткие факты о софт скилах Пн 19.02.2024
Жесткие факты о софт скилах
Крюшон: что это за напиток Чт 15.02.2024
Крюшон: что это за напиток
SQL Server CTE: usage, features and limitations Ср 14.02.2024
SQL Server CTE: usage, features and limitations
Книги
В работу с головой Вт 27.02.2024
В работу с головой
Год: 2017
Жемчужины программирования, 2-е издание Вт 20.02.2024
Жемчужины программирования, 2-е издание
Год: 2002
DOM Enlightenment Вт 13.02.2024
DOM Enlightenment
Год: 2013
Путь программиста. Самоучитель по языку Transact-SQL Вт 06.02.2024
Путь программиста. Самоучитель по языку Transact-SQL
Год: 2020
Ultimate ASP.NET Core Web API Вт 30.01.2024
Ultimate ASP.NET Core Web API
Год: 2021

Разработано на основе BlackNight CMS
Release v.2024-02-21
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент