Introduction to Software Tester Work

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 you think of it as the profession which deals with checking the correctness of the product? All of these thoughts are correct and are the day to day activities for a software tester work. However, software testing is not just limited to these activities.

Understanding the Application

The application could be from any domain – Healthcare, Insurance, Finance, etc. Learning the application domain is very important for any software work to open the doors to thinking 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 this. Having an in-depth knowledge of the application helps the 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 sources of knowledge with respect to product behavior.

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

Testing Process

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

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

Tools

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

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

Popular Course in this category

Software Testing Training (9 Courses, 2 Projects)9 Online Courses | 2 Hands-on Projects | 60+ Hours | Verifiable Certificate of Completion | Lifetime Access
4.5 (5,067 ratings)

Course Price

View Course

Recommended courses

Communication

Communication plays a very important role for software it qualities 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. A tster with effective communication skills can communicate the risks effectively, can communicate effectively with the development team and can communicate effectively the test results and testing reports.

Planning Of Software Tester Works

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

1. Requirements

Requirements could be given to the 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 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. Creation of required documents is the primary responsibility of a Business Analyst. A tast is expected to understand the requirements thoroughly. In order for the teste as well as 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 the 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 the business analyst.

Clear Communication and record of communication plays a very important role for a prove. 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 qualities to keep the communication clean. Software Tester Work 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.

2. 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 –

The user should be able to log in successfully.
The user should be able to book tickets in the system.
The user 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. These logical tasks when grouped together helps prover 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 prover 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.

3. Case

This case is the more detailed version of Software Tester work 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 the above-mentioned scenarios is:

Scenario – User should be able to log in successfully.

Test Cases:

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

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

Below are some of the additional example these 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 entering incorrect password, the system throws an appropriate error message.
Check that entering incorrect username, the system throws an appropriate error message.

4. Requirement Traceability Matrix (RTM)

Requirement traceability matrix as the name suggests helps prove 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 the presence of at least a one these 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 Software prove Work document. When the requirements change very frequently, maintaining this document could be overheard. In order to avoid this overhead and at the same time have a way to trace requirements some projects incorporate the traceability part into Software Tester work case or its scenario document itself.

The important aspect is to have a way to trace scenarios/cases to requirements and vice-versa. Well-Documented requirements make the task for Prover easier to create and maintain these documents. Ambiguous requirements, ever-changing requirements make the life of prover more challenging and can lead to having inconsistent deliverable documents which result in missing out some validation and hence a defect in the 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 the prover to validate the functionality and uncover almost all defects. The next phase of the tester’s journey is Execution.

Execution Of Software tester works

This is the phase where all of the above-mentioned documents are put into use. Requirements were used to create a Scenario, Scenario was used to create it Cases. this Case Document is the Self Sufficient document here to start validating the application. Prover starts validating application by executing steps from this case document. Multiple these 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 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 the application, quality of testing, quality of build and many such factors which directly impacts the product. This phase is the 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 for the business comes in to act in this phase of testing.

Defects Of Software tester works

While executing these 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 these planning Software Tester Work 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 actual is not equal to the expected result, the defect is logged. Logging a defect just 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

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 –

Project/Release Name – Name of the release where the defect was found, usually project has multiple releases and the same project might be having multiple subprojects. 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 detail description of the defect, it should include details like environment where the defect was found, and test data used, actual results expected the result 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 – As there are many phases when a defect can be logged, Unit testing phase, SIT (system integration testing), UAT (user acceptance testing) or even production phase.
Assigned to – Name of the developer or development lead.
Attachments – This given 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 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 prover 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 prover 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, the 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 the prover as discussed above can we still say that the job of software tester qualities 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 sometimes forget that the job of the 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 understands that the end purpose is to make application work as expected. Let us hope for everyone to look at the positive side of the testing job as a role which helps in cleaning the product and not as the one which just finds mistakes!