Baur Urazalinov
May 14

How To Succeed as SQA with Your Team (Part 2)

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 other cases they will not work. All provided information is based on the author's experience.
Greetings, my dear reader!
This second article in a series with practical samples that you as an SQA engineer can apply in your professional journey and achieve certain successes. Here we start with hands-on samples of how to improve your impact directly on team performance and team delivery.
Let's continue our narration.

Table of Contents

  •   Mind Maps
  •   Upstream/Downstream
  •   Technological Stack
  •    Misc
  •   Tools

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 are product components (front-end: framework, components, etc.; back-end: database, APIs, etc.); data flows inside a product; how data transforms from one form into 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 the testing strategy into branches with more detailed goals. (By product I mean an application.)

Technological Stack

Another important aspect is the technological stack of a product. You may ask, why do we need this information? This actually will determine our next steps for changes. Here I'm talking about the general testing strategy of a product, such as test cases, coverage for data flows and functionality, test automation, quality gates, manual testing approaches, synthetic data generation, etc.

Misc

Other questions to cover:
Do we have unit tests? Are those a part of a build process? Do we have system tests? Are those a part of CI/CD? Oh! Do we have CI/CD? Any end-to-end tests (aka integration tests)? Any performance tests? Do we have any feedback loop from tests? Do we use any static code analyzers? Any quality gates in PRs?

Tools

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 will rely on them as a reference 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.

About the Author

My name is Baur Urazalinov
I am a software engineer passionate about all aspects of the software development lifecycle, including development, quality assurance, automation, and programming.
20 years in IT, last 10 years in the SQA field, current Staff Software Quality Engineer at CVS Health, former Senior Software Quality Engineer VI at Signify Health.
Get in touch on LinkedIn or X.