Unfortunately, the QA manager role is still referred to as being the lesser achievable QA position compared to that of a QA engineer. In this blog post I’ll elaborate on the fact that manual quality assurance is not only a user-centric way of testing but a technical one as well — although it might not include the development of automated tests.
The following facts refer to my experience at Project A and their ventures, where we use the method of gray-box testing.
When it comes to testing a new feature or bugfix, the changed code can not only be tested by using the black-box testing method, which basically only takes the inputs and outputs into account, but also by a method called gray-box testing. Gray-box testing will also take things into account that happen while juggling around with the inputs and the outputs.
Some people might wonder why it is important to take this into account if the outputs are appearing as expected. But be cautious, this could only be a coincidence. Even if an output seems correct, the way of generating the output might be wrong and not as it was intended to be. The only way to find this out is to analyze and observe the system's behaviour.
In the following section, I’ll go a bit more into detail about tools that can be used for gray-box testing with the focus on debugging issues. However, the tools can be used for feature testing as well.
The main thought behind gray-box testing is to find out why an issue exists a.k.a. what the issue causes. There are multiple tools that support this method of functional testing, such as:
Browser dev tools like Chrome or Firefox
The browser dev tools support with information regarding Javascript errors, cookies or API request/response data.
Internal and external logging tools like New Relic
Logging tools log all kinds of errors, which can be analyzed and also help the developers to understand the issue better.
API documentation and testing tools like Swagger
API testing tools are used to purely test the API functionality without the frontend part. Thus they can be used to preclude issues caused by the frontend.
Your system databases
Databases are helpful to validate data related to e.g. saving, updating or deleting actions.
System environments
Comparing a functionality that causes issues to any other environment with the same product version can help to find out if a problem is potentially only related to the environment.
Your knowledge about the product and system architecture
A QA manager has a big knowledge base when it comes to the product and its system architecture. Take that knowledge, store it somewhere and use it whenever it’s needed.
Contrary to the method of gray-box testing, black-box testing only refers to the issues themselves and what each issue is about, but it doesn’t shed any light on the cause of the issue. This means that the developers have to put more time and effort into the root cause analysis.
In order to give the developers as much information about an issue as possible, a technical QA manager does not only provide information regarding the environment, time, web page or steps to reproduce but also provides information on any related errors or other relevant information. The browser dev tools and internal/external logs are an awesome source for this.
Caution: Make sure the provided errors are really related to the problem. If in doubt, you can compare them to the production environment or any other environment with the same product version.
Additionally, the browser dev tools will not only display Javascript errors or whether a request failed, but they even track form data that was not correctly sent to the API or data that was returned incorrectly.
Those practices will most likely help to find out whether a problem is caused by the frontend or back end of a system. However, sometimes it’s not that easy to find out what the root cause is. In such a case, developers will work closely together with the technical QA manager and support them with the analysis.
For some features it might be the case that the back end is done before the frontend development even started — or the component of the website doesn’t even have a related frontend. In this case, it might make sense to test the endpoints of the API without using the frontend. This can be done with e.g. Postman, Swagger or tools developed by yourself.
The good thing about it is that it’s mostly faster than testing through the frontend. However, in many cases, it eventually saves time to just test back end and frontend together instead of testing each of them individually.
Being a QA manager means to know about the software architecture and how the software components play together. On the one hand, it has to be clear which parts of the product are directly affected by the code change and thus need to be tested; on the other hand, it is crucial to know what doesn’t have to be tested (there’s a difference). Usually, it is very helpful to know how the code functioned before in order to better understand what has changed. In that way, a QA manager can be performant and won’t get lost in details.
A test script does not question things. A QA manager does. This is one of the most important values that a QA manager brings into the game.
Of course, product managers will also question those things, but sometimes business requirements change during development. Same goes for design. From time to time designers only see the single component they are designing. But as a whole on the website — desktop or mobile — it might not appear as user-friendly as expected.
A QA manager connects product managers and developers. Mostly this will encompass the clarification of questions from both sides and finding the best way of solving them. Everyone in this round should be open to compromises in order to find a solution within a reasonable period of time, which can as well be realized in a reasonable time. In case of not meeting the specifications when the due date is met, it should anyhow be possible to release the current version if it is functioning and still an improvement for the customer. By creating a follow-up ticket, the missing parts won’t get lost.
Organization comprises self-organization as well as team organization. Self-organization partly overlaps with the principles of hands-on testing, e.g. being aware of what needs to be tested and what not, recognizing which tickets can be tested together or whether a specific testing order of tickets has to be followed. Having an overview of everything that needs to be tested first can help organize properly. Once testing has been done, an understandable test report needs to be written. It goes without saying that a QA manager should be familiar with the principles of text processing (a.k.a. “organizing” text) as well.
Additionally, a QA manager might need to organize within the QA team as well. Aligning with other QA members on tickets and tasks can, for example, enhance the performance or the knowledge gathering of the team.
In some companies, a QA manager will have to fully start over and implement a suitable QA process. As the QA process is usually aligned with the development process, either the development process might adapt to the QA process or vice versa. This depends on the preferences. In any case, there should be enough time for a proper testing round in the end. The worst thing is to have stressed QA people who don’t test thoroughly because there is literally not enough time. This won’t help anybody in shipping a reliable and stable product.
When building software for a specific customer audience, the team behind the product should always try to think like their customers. The experience of a QA manager can help the whole team with achieving the ambitious goal of developing a product that fully covers their customer’s needs at any time.
trendig
