Never underestimate the power of your mind.
Internet
Disclaimer
The author is a practitioner and used those techniques. In some cases, those can work; in others, they will not. All provided information is based on the author's experience.
Greetings, my dear reader!
This second article in a series offers practical samples you, as an SQA engineer, can apply in your professional journey to achieve success. Here, we start with hands-on samples on how to improve your impact directly on team performance and delivery.
Let's continue our narration.
Mind Maps
I hope you have documentation about a product (an application, system, etc.) that you're supposed to support. Its functionality, perhaps some test cases, etc.
I would recommend building a mental map or knowledge graph about a product. Potential areas to deep-dive include product components (front-end: framework, components, etc.; back-end: database, APIs, etc.); data flows within a product; how data transforms from one form to another (transformation); and data shape. Pay attention to user flows if it's a UI application.
Upstream/Downstream
When you're done with all of this, you can collect information about upstream and downstream systems. In your case, for the initial stage, it would be enough to know who is a producer of data for a product and who is a consumer (client/clients) of a product. Understand contracts and messages (events), especially data points.
This information is important because it will define your testing strategy in general, and then you will divide it into branches with more detailed goals. (By product, I mean an application.)
Technological Stack
Another important aspect is a product's technological stack. You may ask, why do we need this information? This will actually determine our next steps for changes. Here, I'm talking about the general testing strategy for a product, including test cases, data flow, functional coverage, test automation, quality gates, manual testing approaches, synthetic data generation, etc.
Misc
I would recommend building knowledge graphs or mind maps using tools such as Diagram.net, Obsidian, or mind map applications.
Perhaps Confluence or other text processors or editors can be useful too.
Do not worry if something sounds unfamiliar or not connected by context; we will circle back to those sections and rely on them as references later when we discuss a sample project.
Thanks for reading. I hope you find something useful and applicable to your day-to-day professional activities.
