How to Be a Better Tester – Neotys Testing Roundup

1. 10 Qualities that Can Make You a Good Tester

“What makes you think you are good at testing?”

The question still bangs in my ears whenever it comes to an interview. This was the question I was asked at the beginning of my career as a software tester. The interviewer asked some aptitude questions as usual and suddenly he threw this question to me. I was almost speechless. Most of the time, we think we are good at something because we are doing it or maybe we presume we are good at it.

#1. You understand priorities:

A software tester unknowingly becomes a good time manager as the first thing he needs to understand is priority. Most of the time, you are given a module/functionality to test and timeline (which is always tight) and you need to give output. These regular challenges make you understand how to prioritize things.

#2. You ask questions:

Asking questions is the most important part of software testing. If you fail at it, you are going to lose important bunch of information.

Questions can be asked:

  • To understand requirement
  • To understand changes done
  • To understand how requirement has been implemented

Read the other 8 points made by Bhumika Mehta, a project lead with 7 years experience, here.

2. Cosmetic and the Functional Bugs – What had to be treated and how?

There are always huge responsibilities imposed on the tester to uncover any kind of bug that software has got. Irrespective of the functionality and user interface, testers can raise bugs wherever there is a non-conformance. This article helps in understanding the importance of the functional and the cosmetic bugs.

Cosmetic bugs and their significant importance

Cosmetic requirements are nothing but the user interface or just the front end appearance of the software. Most of the time it happens that it keeps changing between different releases. This happens especially in the projects where agile methodology is being followed. The releases occur here in the form of sprints. Hence they are usually called Sprint release or just SR-xx, where ‘xx’ refers to the release number.

Each and every release can have certain set of requirements. Generally the clients prepare to request for changes in the user interface or just the UI very often.

To read more on cosmetic and functional bugs click here.

3. What is the difference between test plan, test strategy, test script, test scenario and test condition?

In today’s article in this series, we are going to answer (with examples) some most commonly asked (and confusing) questions about the difference between test plan, test strategy, test case, test script, test scenario and test condition.

What is difference between Test plan and Test strategy?

Test plan is a term and a deliverable. Test plan is a document that lists all the activities in a QA project, schedules them, defines the scope of the project, roles & responsibilities, risks, entry & exit criteria, test objective and anything else that you can think of. Test plan is as I like to call a ‘super document’ that lists everything there is to know and need.

This is also a deliverable and also a document at that. Test strategy outlines the testing approach and everything else that surrounds it. It is different from the test plan, in the sense that a test strategy is only a subset of the test plan. It is a hard core test document that is to an extent generic and static. There is also an argument about at what levels test strategy or plan is used – but I really do not see any discerning difference.

To read more on the differences between testing terms click here.

4. How to Write a Test Plan Document from Scratch

In this article you will learn the basic elements of a test plan document. First you need to understand the Software Testing Life Cycle (STLC) process. Which can be divided into 3 parts:

  1. Test planning
  2. Test Design
  3. Test Execution

The Test Plan is a dynamic document. The success of a testing project depends on a well written test plan document that is current at all times. Test Plan is more or less like a blueprint of how the testing activity is going to take place in a project.

The first phase of the STLC process is Initiate. Ideally QA team should get involved while the scope of the project is gathered from the customer/client in the form of business requirements. But in the real world, that is not the case. From a practical point of view, the involvement of the QA team is NIL. At the end of this phase, BRD is finalized and a basic Project Plan is created.

To read the other phases of the STLC process and how to structure a test plan click here.

Leave a Reply

Your email address will not be published. Required fields are marked *