Study what you test
What’s the first question you will ask when starting something new? One of the hundreds answers: “What potential challenges or problems could arise?”
Why read this?
- I wanted to share my experience with an important part of the activity I usually perform when I join a new project
- Why other people are more important than you might imagine
- Why product knowledge might be more valuable than technical skills
- How can you influence the team and product value
Other people
David Hume saw causation as a relationship between two impressions or ideas in mind. He argued that because causation is defined by experience, any cause-and-effect relationship could be incorrect because thoughts are subjective and, therefore, causality cannot be proven. Simply put, Hume was skeptical of causality.
When we come to a new project, we meet many other people with experiences and knowledge which are usually different from ours.
Each of us has a subjective representation of the situation:
- what process to use
- how to test
- how to deploy
- where to put the efforts, and so on
Different roles have different focuses and priorities.
At different times, we think differently about the same thing, for example, “the importance of E2E tests”. And other people influence our views, so it is essential to perceive a different point of view, create alternative approaches, and choose the right one depending on the situation (architecture, infrastructure, team).
When we start working together, we subconsciously think that others know the same as we do. There is even a cognitive bias toward the Curse of Knowledge.
“You know something that the other does not know, and you have forgotten what it is like not to have this knowledge.” Robin Hogarth
1. The “curse of knowledge” makes us feel like others don’t understand the obvious.
2. Having gained experience, we forget our ignorance. We don’t remember how it’s being unable to read or drive a car.
3. We forget many details and cannot explain them to others because this knowledge has become an automatism.
This is why I think Quality Assurance will succeed if you can agree with your team members, especially when you understand each other.
Where to start learning
This is the domain of your application. You can learn about your domain from Product Owners, documentation, or even google it. Today you can also use a ChatGPT(ask only common questions related to your domain). For example, you are going to test recurring charges in the telecommunication domain:
You shouldn’t trust ChatGPT 100%, and you should not leak sensitive data, but with the help of new knowledge, you can ask great questions on QA Refinement. This knowledge is mega-critical for ensuring quality, and I called it “domain research.”
Usually, when we see a new feature, we are limited to the knowledge described in the new Story. You can look at the new feature with the information received. It will help developers to write code that will be easily adapted to other features. QA will write more focused tests for business value. Can it be called overhead? I don’t think so. On the contrary, it will allow you to eliminate unnecessary headaches in the future, especially on long-lived projects.
It is possible to go further and expand your vision of the system you are testing by studying its characteristics, which will change your view of “how” you test.
Beginner example: if you have a dorp-down on UI, before testing all its values, ask if they impact other functionality or are just static data.
You can identify the areas requiring greater attention by understanding the weak points if you know the patterns developers employ in their implementation.
In a microservices world, for example, Transactional Outbox, you can ask if the message consumer is idempotent(can handle duplicate messages correctly) and include corresponding Integration tests.
What helps me to learn a product?
Describing basic E2E flow for critical features.
Allows you to understand the most important functionality of the product (for example, the most used or the one that brings the most profit)
API Documentation
Usually, API documentation has a static description. For me, it is necessary to understand each field’s influence on subsequent requests and entity states.
Architecture diagrams
Ask Architect/Tech Lead for:
1. 4+1 Architecture
2. Internal connections
3. External dependencies
4. Data flow
5. Sequence diagram
6. Entity states and transitions
Organise KT from the developer to QA
Usually, I ask different questions to understand the current situation (few of them):
- What is the current state of the testing process from the development side?
- How is communication with other teams conducted?
- How do you know about the changes inside other services?
- What are the most critical parts of our platform?
- Where are most problems exist?
Outline the testing role in app architecture
- Highlight each of the steps in the process from an engineer’s code commit to production deployment.
- Overlay testing processes to see what types of testing we use and whether they match the information that the engineer needs at each stage in the pipeline.
What benefits do I see?
1. It helps to create a system of sharing knowledge
2. Important for writing test automation framework (going to describe this in one of the following articles)
3. Helps with a Test Design. In the context of your SUT, the concentration of your tests is more intense for specific features.
4. It is crucial for creating a test strategy or its calibration
Summary
You must define a common enemy to organize and motivate a team in the modern world properly. The hierarchy does not work anymore. Since this is not an area where you need to look for enemies, we will replace it with a shared team objective. And here is an analogy for you.
Imagine you are at war and sitting in a trench with your comrades. How important is it for everyone to be on the same page? How important is a common understanding of the situation?
