How can we test technical architecture for any product?

Question

How does tester test the technical architecture of any application? is this really a test-related thing that can be done while the architecture is still being developed, In my project, We have below design:

Business Architectural Design: This design consists of business operations and functions workflow, moreover like profit and losses analysis for business point of view.

Application and Functional Architectural Design: In this we have an application-level design, how to achieve a business goal in the form of software here technical part is abstract most of the time on this level. Most of the QA work on this design as end-user.

Technical Architectural Design: We have dedicated infrastructure, Technical Frameworks (those which are generic for any functional project, like KPI, logging, exception management...etc), Multiple storages(Blobs, Queues, Tables, and files), Virtual Networks, Server's & much more.

Developer Architectural Design: In this we have a UI project structure, Multiple services, controller, nested logic which is interrelated to each other in a complex way.

As all these designs make a single end-product so how should we approach to test technical architectural & developer architectural design.

Answer 1

In essence, it doesn't change much, after all...

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.” James Bach, Exploratory Testing 3.0

Therefore, the idea behind testing architectures implementations is to explore its assumptions and component interactions, in order for you to learn about them and then find risks and faults.

Traditional testing heuristics, like A FEW HICCUPPS, RCRCRC, and SFDPOT may help in the exploration process. Risk-based testing mindset as well.

Product Coverage Outlines may help to create a vision of what and how you tested. The Heuristic Testing Strategy Model may help you to organize your context needs and strategy.

Some notion of software architecture, like the Clean Architecture or the C4 model, may help you to create better arguments for bug advocacy.

In summary, whenever you are going to test some of these architectural views, you have to ask:

1. What are the risks that I see here and how can I uncover new risks?
2. Which tools and techniques allow me to investigate the state of the product (and its models/docs) against these risks?
3. How can I better communicate my findings, so that I maximize the possibility of having these problems addressed?

Answer 2

Still working in waterfall?

Embrace Agile!

Big Design Up Front BDUF is poorly adaptable to changing requirements and that BDUF assumes that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation. For substantial projects, the requirements from users need refinement in light of initial deliverables, and the needs of the business evolve at a pace faster than large projects are completed in - making the Big Design outdated by the time the system is completed.

Source : Wiki