When we say Tools and Technologies we often forget techniques. For any Software Tester techniques should be the primary concern as it deals with the approach we apply to test something. ‘Technical Tester’, this word is often used in Software Testing but the meaning is taken as technological tester i.e. one who knows about technologies (Internet, Web servers, Databases, etc). Whereas Technical tester term is more about the skills and crafts required for testing, for example, designing tests, approach to exploratory testing, etc.
When we turned to our community as what do they have to say about bare minimum tools and technologies a QA should posses we received wonderful responses from Testers having varied experiences.
We thought of compiling the comments and sharing it outside the group so that our Testing fraternity is benefitted with content.
The tester has to have at least an elementary programming knowledge with a fundamental understanding of how software is built and run. If you haven’t learned to program, start small and learn continuously.
Below are the things which I think a Technical Tester should be doing(List is what I could think of while I wrote. There can be surely more).
Will you guys mind adding more to this list or suggesting if something should be removed?
Here it is (in no particular order):
- Knows Different types of Testing. Knowing those at the core I mean and not just being limited to one tool. Remember, if the use case/understanding is clear, one objective may be achieved using many tools.
- Understands the architecture of his/her application
- By architecture I mean, what all technologies are used to form the complete application.
- What exactly each of those is doing.
- In what way they are connected to each other.
- How do they communicate?
- When a business user initiates a request, how the entire request-response flow works.
- Understands the logs, or at least tries to understand. There are several ways like Google the exception or error, past experience, asking a developer and remember, making logical guess while reading and cross-checking with Dev if your understanding was correct.
- Questions himself/herself why a particular issue is occurring while using all the logs available(front end, backend, web server logs, DB logs) whenever possible before routing to Dev. Same can be done in parallel if urgency demands.
- Requests RCA for the bugs logged. Asks questions till the time it is clear
- Explicitly asks for Impact area of the Bug fix/new feature
- Requests overview of how particular bug was fixed
- Requests overview of how the new feature is getting developed. Helps Dev to further assess the impact area, a better approach, etc.
- May not be an expert coder but if situation demands can code. More the better here.
- Always thinks of how to automate basic routine stuff. Something as simple as Build deployment or Executing Automation suite.
- Thinks of innovative approaches to test and still follows a set process.
- Does research about the new technology/jar/upgrade being taken and looks for information on open issues. Also on its compatibility with remaining Tech stack.
- Understands the value of automation, and decides what to automate and makes sure it is being automated right.
- If not fluent, decent with Database queries and is ready to learn on demand. Remember knowing everything is best but knowing basics/nothing and being ready to research as needed is ‘human’.
- Probably repeating, but an understanding of different types of Testing. For example, Security Testing. It’s ok if you cannot hack or find critical Vulnerabilities. But at least test for basic flaws like other customer data in export, URL tampering, open admin pages, easy guess passwords, XSS wherever you can, etc.
- Knows how to use browser developer toolbar for different purposes like checking response, request, response time, 404 errors, etc.
Testers should be full stack Tester. This term ‘Full stack QA’ was later beautifully elaborated on another community discussion by Mahesh and Ravisurya, posting their excerpts as it is
A lot more technical, not just a bit. The more, the better, as elaborated below:
Monitoring production logs especially after deployments has benefits of its own. And if the tester does it regularly then there is a lot they can discover through those logs.
If as a tester, you are not yet doing production deployments then I suggest you to start doing it and make sure to check production logs (or logs on other environments for that matter). If for some reason, you do not own deployments then try to spend at least one short session for monitoring your application’s production logs, every day. That’s what I mean by “Monitoring session”.
Monitoring sessions can also help you identify technical bugs, errors or warnings, which might not be directly affecting the end user but still warrant attention and fixing. It’s hard to identify such issues in regular functional testing which usually has a big scope of its own.
Some of the technical stuff a Tester can learn
- OOPS concepts
- Flow of request in the infrastructure
- Build deployment and CICD
- What is the role of Apache and nginx
- DB schema
- Knowing tables affected on performing an action on UI
One of my favorite – a Tester should know how the internet works?
As a tester one should gather as much as knowledge possible for whatever one is working upon. There isn’t any minimum technical or programming concept one should learn. Rather it should be let’s learn and explore as much as possible.
Just as technical understanding would help the tester understand the product a little more from a developer perspective, the knowledge of management skills would help them make use of proper time estimation techniques, RTM, criticality matrix and even create it accurately if needed.
There’s a need for every tester to have the holistic approach – TechFuncMan (technical, functional and managerial)
We are sure you too must be having your list, do share it with us by writing in the comment box below.
Disclaimer: We have tried our best to keep the comments from the contributors as original as possible.