What is the first thing that comes in your mind when you think about a software testing job? A non coding work? Or a profession which is very easy as it gives you opportunities to find mistakes in others work (finding mistakes when in others is easiest task for all of usJ)? Or you think of it as the profession which deals with checking correctness of product?

All of these thoughts are correct and are day to day activities for a software Tester. However software testing is not just limited to these activities.

A typical journey of a Software Tester starts from understanding the application.

Understanding Application/Product for software tester

Application could be from any domain – Healthcare, Insurance, Finance, etc. Learning the application domain is very important for any software tester as it opens the doors to think from various angles and various user perspectives while testing the application. To uncover and validate the obvious and not so obvious paths of application is always the primary expectation from a software tester. Having an in-depth knowledge of the application helps tester to validate the product effectively at the same time the tester can become an asset to a project where he/she is considered as one of the primary source of knowledge with respect to product behavior.

While learning domain and functionality is an ongoing process for any tester the other important factor is having knowledge about the testing process.

Testing Process

Testing process can vary from company to company or even from one project to another. Today we have various software development models like V model, Prototyping model or an all together different methodology like Agile approach of software development. With change in development model, testing approach to be followed also varies. A tester working in a V model will have well defined processes while the tester working in agile methodology is expected to test in ever changing conditions.

Job is not yet smooth with having acceptable domain knowledge and understanding of testing process, next challenge that comes in the life of software tester is learning various tools.

Tools

Tools implies Test management tools, Defect logging tools, Database Management tools and so on.

With various defect logging tools, some open source and some licensed, it is always an advantage to have knowledge of more than one tool. It helps testers to easily transition projects or teams following different tools. With adequate knowledge of domain, process and tools there is more to the life of software tester which makes his/her work days challenging and exciting. Collaboration within teams is one of the important factor in success of any project and for effective collaboration, communication plays a very important role.

Communication

Communication plays a very important role for a software tester as from the initial phases of software development, testing team members are involved (as a best practice) in discussion of requirements, questioning business analysts in case of any queries or gaps in the Requirement. A tester with effective communication skills can communicate the risks effectively, can communicate effectively with development team and can communicate effectively the test results and testing reports.

A Day at work for a software tester usually comprises of Test planning or Test Execution.

Test Planning

As the name suggests, test planning is the phase where preparation for the testing is done. Preparation for a tester will involve various types of activities that a tester does in order to test the application effectively. This will help in validating the application and uncovering the defects in the application effectively. In order to start off the test planning, a tester goes through the requirements to understand the expectations.

• Requirements

Requirements could be given to testing team in the form of wireframes, storyboards, excel sheets. Purpose of all these documents is to present the client requirements in an efficient and easy to understand way. Wireframe Document is nothing but a document which may be in the form of PowerPoint presentation which depicts the client requirements. On the same lines storyboards usually depicts the required look/design of the screens. Nowadays various tools are available in the market which can be used to prepare the requirement documents. Creation of requirement documents is the primary responsibility of Business Analyst. A tester is expected to understand the requirements thoroughly. In order for the tester as well as developers to understand the requirements correctly, business analysts keeps the forum open for everyone to raise and get the queries answered on any of the requirements. The platform to discuss and communicate the open questions and queries varies from project to project. It could be chain of emails or a conference call or even a shared drive repository maintained to keep track of all open questions and their answers as provided by business analyst.

Clear Communication and record of communication plays a very important role for a tester. A small assumption in the requirement could sometimes lead to a major defect in the product. At every stage, it is recommended to a software tester to keep the communication clean. This communication could be with Business analysts or even within a team. Clear communication helps to keep assumptions away during planning and execution. At the same time it is recommended to have a record of communication (preferably email communication). Having a written communication on queries in requirements helps in the later stages of test execution where the functionality might not have been developed as confirmed in the recorded communication.

• Test Scenario

Once the requirements are understood, tester starts documenting the scenarios in the Test Scenario document. A scenario as the name suggests is a flow of functionality that user follows in order to accomplish a task.

Examples of scenarios –

1. User should be able to login successfully.
2. User should be able to book tickets in the system.
3. User should be able to cancel tickets in the system.
4. User should be able to view/update the profile details.

These are the logical tasks that a user performs in the system. These logical tasks when grouped together helps testers to make note of all the possible scenarios that a user is expected to perform. These scenarios are usually documented in the Excel sheets or sometimes using some tools. A tester thrives to extract all such scenarios from the requirement documents. A document containing such scenarios is called is Test Scenario Document (or somewhere as High Level Scenario Document). This document serves as an input document for drafting Test Cases.

• Test Case

A test case is more detailed version of test scenario where the scenario is broken down into more detailed steps which the user will actually perform while using the application. A simple example based on above mentioned scenarios is:

Scenario – User should be able to login successfully.

Test Cases:

1. Verify that user is able to enter correct username.
2. Verify that the user is able to enter password.
3. Verify when clicking Login button after entering correct username and password, user is able to log in successfully.

Such list of test cases can go on to include validation check on each field, checking negative scenarios and so on.

Below are some of the additional example test cases –

1. Verify that username when not entered, system throws an appropriate error.
2. Verify that password when not entered, system throws an appropriate error.
3. Verify that username and password when not entered, system throws an appropriate error.
4. Check that entering incorrect password, system throws an appropriate error message.
5. Check that entering incorrect username, system throws an appropriate error message.

• Requirement Traceability Matrix (RTM)

Requirement traceability matrix as the name suggests helps testers to check and incorporate the coverage of the requirements as provided by Business into the testing documents like scenarios and test cases.

As a best practice, this is a separate document showing the mapping of requirement number with that of scenarios/cases incorporating that requirement.

This document may not be used by all kinds of projects but when used it helps in the strong way to trace the high level scenarios mapping to the requirements. It indicates the coverage and can be used to check presence of at least a one test case against each and every requirement. Creating and maintaining the RTM document is considered as the best practice however not all kinds of projects (like Agile) use this document. When the requirements change very frequently, maintaining this document could be overhead. In order to avoid this overhead and at the same time have a way to trace requirements some projects incorporate the traceability part into test case or test scenario document itself.

Important aspect is to have a way to trace scenarios/cases to requirements and vice-versa. A well-documented requirements make the task for tester easier to create and maintain these documents. Ambiguous requirements, ever changing requirements makes the life of tester more challenging and can lead to having inconsistent deliverable documents which results in missing out some validation and hence a defect in end product.

Journey so far for a tester was planning and preparing for testing. As preparation for war is part of the warJ, same applies here. The more concise these documents are created, it is easier for tester to validate the functionality and uncover almost all defects. The next phase of tester’s journey is Execution.

Test Execution

This is the phase where all of the above mentioned documents are put into use. Requirements were used to create Scenario, Scenario were used to create Test Cases. Test Case Document is the Self Sufficient document here to start validating the application. Tester starts validating application by executing steps from the test case document. Multiple test cases could be used to validate a single scenario or even a single test cases can correspond to a single test scenario. It all depends upon the complexity of the scenarios or sometimes the standard followed in the test team. Hence a single test case document can contain 20-50 test cases or it may have 100-120 test cases. These numbers are only for explanation purpose, it may vary wildly from project to project. The Outcome of this phase is Test Defects. The number of valid defects raised in this phase gives a good idea about the stability of application, quality of testing, quality of build and many such factors which directly impacts the product. This phase is most important phase as tester thrives to cover all test cases (validating almost all required user paths) and at the same time raise as many valid defects as possible. All the preparation, communication skills, queries asked to business comes in to act in this phase of testing.

Test Defects

While executing a test case, any behavior which is not equal to the expected result, is raised as the Defect. Each test case has a Description, Expected Result and a column for Actual Result. While test planning this document has a description and expected results and a Blank column for Actual Results. While executing the test cases, tester is supposed to fill up the actual result column. At the same time if actual is not equal to expected result, defect is logged. Logging a defect just doesn’t not mean informing the developer about the issue. It is again a formal process usually done with the help of a tool. Currently there are various tools in the market, some open source and some licensed. Any defect logging tool has following fields –

1. Project/Release Name
2. Defect Summary
3. Defect Detail Description
4. Defect Severity
5. Defect Priority
6. Phase the defect was found
7. Assigned to
8. Attachments

As we can see the purpose of all these fields is to have a formal process wise details of the issue found. This helps developers to reproduce the defect in their environment and fix it. Below is the short description of all these fields –

1. Project/Release Name – Name of the release where defect was found, usually project has multiple release and same project might be having multiple sub projects. This field helps to raise an issue for a specific release.
2. Defect Summary – A short one liner description of the defect found.
3. Defect Detail Description – This is the detail description of the defect, it should include details like environment where defect was found, and test data used, actual results, expected result and any additional information which adds more valuable information for the stakeholders to understand the defect.
4. Defect Severity – It signifies how severe the defect is. Usually it has values similar to Critical, High, Medium, Low or numeric values like 4,3,2,1.
5. Defect Priority – It signifies how urgent it is to fix the defect.
6. Phase the defect was found – As there are many phases when a defect can be logged, Unit testing phase, SIT (system integration testing), UAT (user acceptable testing) or even production phase.
7. Assigned to – Name of the developer or development lead.
8. Attachments – This given an option to tester to attach the snapshot of the screen where the issue was encountered.

Test Execution and Defect logging is the phase where there are many challenges a tester might face. Some of them are communicating effectively with the developers. We might argue that is logging a defect with all necessary information not sufficient for the developers to understand the defect?

It is and in some of the cases, it requires additional explanation/discussion with the developers. There are instances where a tester encounters an unexpected behavior which he/she might not be sure if it is a defect. These circumstances are usually faced by testers who are new in the team, having limited domain knowledge or having ambiguity on the requirements. Well the tester is not to be blamed here if there are tight deadlines and there are ever changing requirements and in most of the cases testers learn about the domain while actually planning and executing test cases. As we can see the path of a tester is not as easy as it is perceived. It requires ever learning attitude, good communication skills, good collaborating skills and eagerness to adjust oneself in conditions where there are changes in domains, tools, processes used. While we talked about the journey of manual testers, overall process applies to Automation testers as well. Automation on the other hand have significant changes in the process as the scope of testing and planning, execution varies significantly.

Considering the journey of tester as discussed above can we still say that the job of tester is easier than that of a developer?

It can be said that more than comparing the tester v/s developer roles, it will be more useful to have a discussion of how the collaboration of two can lead to a major success of the product as a whole. We sometime forget that the job of tester is to find issues in the application and not to point of mistakes of the developers. When we forget the very idea of our job, it sometimes leads to unnecessary discussion. However it is been observed that there are equally good testing, development teams where everyone understand that the end purpose is to make application work as expected. Let us hope for everyone to look at the positive side of testing job as a role which helps in cleaning the product and not as the one which just finds mistakes!

The post Know What Software Tester Career is All About appeared first on eduCBA.