Updated February 21, 2023

Introduction to Typical Journey of a Software Tester

This is an outline on Typical Journey of a Software Tester, so what is the first thing that comes to your mind when you think about a software testing job? A noncoding 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 the easiest task for all of us)? Or do you think of it as the profession that deals with checking the correctness of a product?

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 with understanding the application.

Understanding Application/Product (Typical Journey of a Software Tester)

The 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 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. In-depth knowledge of the application helps the tester validate the product effectively. At the same time,, the tester can become an asset to a project where they are considered one of the primary sources of knowledge concerning product behavior.

While learning domain and functionality is an ongoing process for any tester, the other important factor is knowing the testing process.

Testing Process

The testing process can vary from company to company or even from one project to another. Today we have various software development models like the V model, the the Proto-typing model, or an altogether different methodology like the Agile software development approach. With the change in the the development model, the 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 good domain knowledge and understanding of the testing process; the next challenge that comes in the life of a software tester is learning various tools.

Tools

Tools imply 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 advantageous to know more than one tool. It helps testers to transition projects or teams following different tools easily. With adequate knowledge of the domain, process, and tools, there is more to a software tester’s life, making their work days challenging and exciting. Collaboration within teams is one of the important factors in the the 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 the discussion of requirements, questioning business analysts in case of any queries or gaps in the requirement. Therefore, a tester with effective communication skills can communicate the risks effectively with the the development team and communicate the test results and testing reports effectively.

A Day at work for a software tester usually comprises 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 to test the application effectively. This will help in validating the application and uncovering the defects in the application effectively. To start the test planning, a tester goes through the requirements to understand the expectations.

Requirements

Requirements could be given to the testing team through wireframes, storyboards, and excel sheets. The purpose of all these documents is to present the client’s requirements efficiently and easily. For example, a wireframe document is nothing but a document that may be a PowerPoint presentation depicting the client’s requirements. Along the same lines, storyboards usually depict the required look/design of the screens. Nowadays, various tools are available in the market which can be used to prepare the required documents. The creation of required documents is the business analyst’s primary responsibility. A tester is expected to understand the requirements thoroughly. For the tester and developers to understand the requirements correctly, business analysts keep 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 a chain of emails, a conference call,, or even a shared drive repository maintained to keep track of all open questions and their answers as provided by the the business analysts.

Clear Communication and record of communication play 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 for 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 the 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 (Typical Journey of a Software Tester)

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

Examples of scenarios –

The user should be able to log in successfully.
Users should be able to book tickets in the system.
Users should be able to cancel tickets in the system.
The user should be able to view/update the profile details.

These are the logical tasks that a user performs in the system. When grouped, these logical tasks help testers note all the scenarios a user is expected to perform. These scenarios are usually documented in Excel sheets or sometimes using some tools. A tester thrives in extracting all such scenarios from the requirement documents. A document containing such scenarios is called Test Scenario Document (or a High-Level Scenario Document). This document serves as an input document for drafting Test Cases.

Test Case

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

Scenario: The user should be able to log in successfully.

Test Cases:

Verify that the user can enter the correct username.
Verify that the user can enter a password.
The user can log in successfully when clicking the the Login button after entering the correct username and password.

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

Below are some of the additional example test cases –

Verify that username; when not entered, the system throws an appropriate error.
Verify that password; when not entered, the system throws an appropriate error.
Verify that username and password when not entered, the system throws an appropriate error.
Check that the the system throws an appropriate error message if if entering an incorrect password.
Check that the the system throws an appropriate error message if entering an incorrect username.

Requirement Traceability Matrix (RTM)

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

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

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

An important aspect is to have a way to trace scenarios/cases to requirements and vice-versa. Well-documented requirements make the task for the tester easier to create and maintain these documents. On the other hand, ambiguous and ever-changing requirements make the tester’s life more challenging. Moreover, they can lead to inconsistent deliverable documents, which result in missing some validation and hence a defect in the end product.

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

Test Execution

This is the phase where all the documents mentioned above are used. Requirements were used to create Scenario; Scenario was used to create Test Cases. Test Case Document is Self Sufficient document to start validating the application. The tester starts validating the 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 case can correspond to a single test scenario. It all depends upon the complexity of the scenarios or sometimes the standard followed by 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 purposes; they 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 application’s stability, quality of testing, quality of build, and many such factors which directly impact the product. This phase is the most important as the the tester thrives on covering all test cases (validating almost all required user paths) and raising as many valid defects as possible. All the preparation, communication skills, and queries asked to Business come into the act in this testing phase.

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 Results, and a column for Actual Results. While test planning, this document has a description and expected results and a Blank column for Actual Results. While executing the test cases, the tester is supposed to fill up the actual result column. At the same time, if the actual is not equal to the expected result, the Defect is logged. Logging a defect doesn’t 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 the following fields –

Project/Release Name
Defect Summary
Defect Detail Description
Defect Severity
Defect Priority
Phase the Defect was found
Assigned to

Attachments (Typical Journey of a Software Tester)

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

Project/Release Name – Name of the release where the Defect was found, usually project has multiple releases, and the the same project might have multiple sub-projects. This field helps to raise an issue for a specific release.
Defect Summary – A short one-liner description of the Defect found.
Defect Detail Description – This is the detailed description of the Defect; it should include details like the environment where the Defect was found, test data used, actual results, expected results, and any additional information which adds more valuable information for the stakeholders to understand the Defect.
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.
Defect Priority – It signifies how urgent it is to fix the Defect.
Phase the Defect was found – There are many phases when a defect can be logged, the Unit testing phase, SIT (system integration testing), UAT (user acceptance testing),, or even the production phase.
Assigned to – Name of the developer or development lead.
Attachments – This gives an option to the 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. Might we argue that is logging a defect with all necessary information insufficient for the developers to understand the Defect?

It is, and in some cases, requires additional explanation/discussion with the developers. There are instances where a tester encounters an unexpected behavior that they might not be sure if it is a defect. New testers in the team usually face these circumstances with limited domain knowledge or ambiguity on the requirements. Well, the tester is not to be blamed here if there are tight deadlines and ever-changing requirements, and in most cases, testers learn about the domain while planning and executing test cases. As we can see,, the path of a tester is not as easy as it is perceived. It requires an ever-learning attitude, good communication skills, good collaborating skills, and an eagerness to adjust to conditions where there are changes in domains, tools, and processes. While we talked about the journey of manual testers, the the overall process also applies to Automation testers. On the other hand, automation has significant changes in the process as the scope of testing and planning; Execution varies significantly.

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

Conclusion – Typical Journey of a Software Tester

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

Quiz Result
Total Questions	Correct Answers	Wrong Answers	Percentage