Updated April 24, 2023
Introduction to Software Tester Work
This is a guide to Software Tester Work. What is the first thing that comes to mind when you think about a software testing job? A noncoding work? Or a profession that is very easy as it allows you to find mistakes in others’ work (finding errors when in others is the easiest task for all of us)? Or do you think of it as the profession which deals with checking the correctness of the product? These thoughts are correct and are a software tester’s day-to-day activities. These activities do not fully encompass the scope of software testing.
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 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. An in-depth knowledge of the application helps the tester validate the product effectively. At the same time, project teams can consider the tester as one of the primary sources of knowledge regarding product behavior, making them an asset to the project.
While learning domain and functionality is ongoing, the other important factor is knowing 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, the Prototyping model, or an altogether different methodology like the Agile software development approach. As the development model changes, the testing approach also varies. Working in a V model will have well-defined processes while working in an agile methodology is expected to test in ever-changing conditions.
The job is not yet smooth with having good domain knowledge and understanding of the testing process; the next challenge that comes with life is learning various tools.
Tools
Tools imply Test management tools, Defect logging tools, Database Management tools, etc.
With various defect logging software qualities & tools, some open source and some licensed, knowing more than one tool is always advantageous. It helps it 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 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 vital role.
Recommended courses
Communication
Communication plays a vital role in software quality. From the initial phases of software development, testing team members are involved (as a best practice) in discussing requirements and questioning business analysts in case of any queries or gaps in the condition. A tester with effective communication skills can communicate the risks effectively, can communicate effectively with the development team, and can communicate the test results and testing reports effectively.
Planning of Software Tester Works
The test planning phase makes preparations for testing, as the name suggests. Preparation for a tester will involve various types of activities that a tester does to apply the application effectively. This will help in validating the application and uncover the defects in the application effectively. To start the planning, a test goes through the requirements to understand the expectations.
1. Requirements
The testing team could be provided with requirements in the form of wireframes, storyboards, or Excel sheets. The purpose of all these documents is to present the client’s requirements in an efficient and easy-to-understand way. A wireframe document is nothing but a record that may be in the form of PowerPoint presentation which depicts the client’s requirements. On the same lines, storyboards usually depict the required look/design of the screens. Nowadays, we can use various tools available in the market to prepare the required documents. The creation of necessary documents is the primary responsibility of a Business Analyst. A test is expected to understand the requirements thoroughly. For the teste and developers to understand the needs correctly, business analysts keep the forum open for everyone to raise and get queries answered on any of the conditions. The platform to discuss and communicate available questions and queries varies from project to project. It could be the 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 business analyst.
Clear Communication and a record of Communication play a vital role in proving. A small assumption in the requirement could sometimes lead to a major defect in the product. At every stage, it is recommended that a software tester qualities 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, having a record of the Communication (preferably by email) is recommended. Having 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
After understanding the requirements, the tester begins to document the scenarios in the Test Scenario document. As the name suggests, a scenario is a flow of functionality the user follows 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. Grouping these logical tasks helps the prover note all the scenarios a user is expected to perform. These scenarios are usually documented in Excel sheets or sometimes using some tools. A prover thrives on extracting all such scenarios from the requirement documents. We call a document containing such scenarios a Test Scenario Document (or, somewhere, a High-Level Scenario Document). This document serves as an input document for drafting Test Cases.
3. Case
This test case is a more detailed version of the software tester’s work scenario. We break down the scenario into smaller and 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 the password.
- Verify when clicking the Login button after entering the correct username and password that the user can 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 additional examples of these cases –
- Verify that the username when not entered; the system throws an appropriate error.
- Verify that password when not entered, the system throws an appropriate error.
- Verify that the username and password, when not entered, the system throws an appropriate error.
- Check that the system throws an appropriate error message if entering an incorrect password.
- Check that entering an incorrect username, the system throws an appropriate error message.
4. Requirement Traceability Matrix (RTM)
As the name suggests, the requirement traceability matrix helps check and incorporate the coverage of the requirements as provided by the Business into the testing documents like scenarios and test cases.
As a best practice, this is a separate document showing the mapping of requirement numbers with that of scenarios/cases incorporating that requirement.
When used, this document can be beneficial in tracing high-level scenarios that map to the requirements, although not all projects may use it. It indicates the coverage, and project teams can use it to verify that each requirement has at least one corresponding test case. It is considered a best practice to create and maintain the RTM document.; however, not all projects (like Agile) use Software proof Work documents. When the requirements change very frequently, maintaining this document could be overheard. To avoid this overhead and at the same time have a way to trace requirements, some projects incorporate the traceability part into the 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 and ever-changing requirements make the life of a prover more challenging. They can lead to inconsistent deliverable documents, which result in missing out on some validation and hence a defect in the end product.
The journey so far for a tester was planning and preparing for testing. The same applies here as preparation for war is part of the warJ. The more concise these documents are, the easier the prover can 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 we put all the documents above into use. The requirements were used to create a scenario, which was used to create test cases. We can use the test case document as a self-sufficient document to validate the application. Prover starts validating the application by executing steps from this case document. Multiple test cases can be used to validate a single scenario, or 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 or 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 to 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 other factors that directly impact the product. This phase is the most important as the tester thrives on covering all test cases (validating almost all required user paths) and, at the same time, raising as many valid defects as possible. All the preparation, communication skills, and queries asked for the business come in to act in this testing phase.
Defects of Software Tester Works
During the Execution of these test cases, the tester identifies and raises any behavior that does not match the expected result as a defect. Each test case has a Description, an Expected Result, and a column for the Actual Result. While this 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 and log a defect if the result is not equal to the expected result. Logging a defect doesn’t mean informing the developer about the issue. Usually, people perform this formal process 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, all these fields aim 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 – Usually, we specify the name of the release in which we found the defect, considering that a project typically has multiple releases and may also have 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 – The detailed description of the defect should include information such as the environment in which it was found, the test data used, the expected and actual results, and any additional information that can provide valuable insight for 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 – We have allowed the tester to attach a snapshot of the screen where they encountered the issue.
Test Execution and Defect logging is the phase where there are many challenges a tester might face. Some of them communicate effectively with the developers. Might we argue that logging a defect with all necessary information is 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. Provers new to the team, have limited domain knowledge, or face ambiguity in the requirements usually encounter these circumstances. Well, the tester is not to be blamed here if there are tight deadlines and ever-changing requirements, and in most cases, the case prover learns about the domain while planning and executing test cases. As we can see, the path of a tester is not as easy as it may seem. It requires an ever-learning attitude, good communication skills, good collaborating skills, and eagerness to adjust to conditions where there are changes in domains, tools, and processes. While we talked about the journey of manual testers, the overall process also applies to Automation testers. Conversely, automation significantly changes 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?
One could argue that instead of comparing the roles of testers and developers, discussing how their collaboration can lead to the product’s overall success would be more beneficial. We sometimes forget that the tester’s job is to find issues in the application and not to point out developers’ mistakes. When we ignore the very idea of our job, it sometimes leads to unnecessary discussion. We have observed that there are testing and development teams where everyone understands that the end purpose is to make the application work as expected. Let us hope everyone looks at the positive side of the testing job as a role that helps clean the product and not as the one that finds mistakes!
Recommended Articles
This is a guide to Software Tester Work. Here we have discussed some basic concepts, top test planning, and test defects. These are the following external link related to software tester work.
