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.

  • Still working in waterfall? May 9, 2020 at 15:52
  • No.. @VishalAggarwal ... I didn't mention anything about the process but btw how development process is relevant to this question? my question is about the testing of Technical Architectural & Developer Architectural Design. May 10, 2020 at 4:25
  • If these documents are being made in an agile project, then I guess you need to step back and ask much bigger question to yourself. May 10, 2020 at 12:49
  • The question of testing these are only valid, if they are created in the first place. May 10, 2020 at 12:59

2 Answers 2


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?

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.