Why should QA be aware of the project’s architecture ?

In this blog, I am going to share some insights that helped deliver quality products. Though QA is not the only person responsible for quality but most of the time, QA is the last person to perform exploratory/end to end testing before delivering or showcasing it to clients.

It will be useful for any QA who usually focus on black box testing and automation testing but don’t think much about architecture and implementation details.

Nowadays learning more and more automation tools has become a trend, but the most important thing is the QA mindset.

Generally QA should be able to do:

• Think ample scenarios from an end user perspective that sometimes any non tech person and any developer can’t think of. If we can not think of almost every possible test scenario, we will miss them in automation as well.
• Based on the product’s vision, think of any kind of improvements or bottleneck with current architecture so that we can avoid any rework later on and also brainstorm on non functional scenarios.
• Test at a more granular level and at the correct layer of the test pyramid (Unit, Api, UI) to save time and cost.
• Most important, based on the architecture of the application and tech implementations, should contribute in developing the Test Strategy and Test Plan.

How deeper QA should dive with architecture details ?

If we refer C4 Model, I would suggest someone should be at least aware of C3 level details of the product we are working on. Eventually based on need and interest, can move to C4 level.

I am taking an example of a Web Application and have listed down a few things that will give you the basic ideas. Though this is a never ending list. It depends on the kind of project and our role, responsibility as well.

1. What kind of application are we building and why ? (e.g. Microservice vs Monolithic, their pros and cons, different design patterns)

2. In the case of microservices, How different services are divided ? Which will give us idea on complete flow, any possible point of failure, dependency.

3. What’s the entry point of any request from a client? e.g. Any kind of API gateway, proxy, firewall, load balancer etc.

We can understand better, where can be the bottleneck in case of heavy load on application ? What all security related issues might occur ?

4. What all different https calls are triggered from the front end for any user action and how the application reacts in case of any delay or failure ? Failures are handled gracefully or not ? There are proper timeouts or not ? What all validations are put at server side ?

5. How different services are communicating with each other (eg. Rest api, or using any asynchronous mode using kafka or any other tool) and check performance accordingly.

6. What kind of front end do we have (e.g. micro frontend or not) ? What kind of storage do we have at the frontend to manage the states (e.g. Redux or any other — How do they work ?). Any input validations on frontend ?
Impact of any backend micro service failure on any part of frontend/UI ?

7. What kind of database do we have ? Any pros, cons — functional, performance and security wise. Easily exposed to SQL injection or not ?

8. How to ensure data consistency across services ? Using a shared database or database per service ?

9. How do we aggregate the response form different services — at frontend or backend ?

10. Are we using any kind of caching ?

• Api response at the client side ?
• Server side, any CDN (content delivery network)?
• Duration of caching and how caches are invalidated in case response has been changed ?

11. How does Authentication and Authorisations work and How the client sessions are maintained ? It’s crucial since we cant compromise with unauthorised access of any PII information.

12. How are the cookies being used ? Any security concerns ?

13. How do we deploy ? Number of machines/pods/containers in use ? How is the scaling strategy — horizontal or vertical ?

14. Should be aware of resources/services used from different cloud providers. Any limitations, bottleneck in terms of performance, security, network, availability zone ?

14. Application logging mechanism. Are logs aggregated from different containers and across different services for easily troubleshooting any issue?

15. How does application monitoring and alerting works in case of failure or if application is not healthy.

Final note: The Architecture of any application evolves over time. As a QA, we should keep ourselves updated about any change done through any story or feature. With those details, we can definitely validate any feature/product at a granular level because we know where the things can break.

Please share any feedback in comment. Thank you.