EDUCBA

EDUCBA

MENUMENU
  • Free Tutorials
  • Free Courses
  • Certification Courses
  • 600+ Courses All in One Bundle
  • Login
Home Software Development Software Development Tutorials Software Testing Tutorial Typical Journey of a Software Tester
Secondary Sidebar
Software Testing Tutorial
  • Basics
    • What is Software Testing
    • Careers in Software Testing
    • Defect Life Cycle in Software Testing
    • Bug Life Cycle
    • Levels of Software Testing
    • Software Testing Life Cycle
    • Software Tester Work
    • Software Testing Principles
    • Software Testing Services
    • Testing Methodologies
    • Test Approaches
    • Grey Box Testing
    • Types of Software Testing
    • What is a Bug in Software Testing
    • Benefits of Automation Testing
    • What is Automation Testing?
    • Types of Automation
    • Typical Journey of a Software Tester
    • Automation Testing Process
    • Mobile Automation Testing
    • Automation Testing Life Cycle
    • Software Quality Assurance
    • Software Quality Assurance
    • What is Test Environment?
    • Verification and Validation Testing
  • Types of Testing
    • Adhoc Testing
    • Types of System Testing
    • Manual Testing Types
    • Unit Testing Types
    • Unit Testing Benefits
    • Agile Testing
    • What is Agile Testing
    • Acceptance Testing
    • Stress Testing Types
    • Alpha and Beta Testing
    • Application Testing
    • Automation Testing
    • Automation Testing Advantages
    • Benchmark Testing
    • Black Box Testing
    • Domain Testing
    • Dynamic Testing
    • Ecommerce Testing
    • Fuzz Testing
    • Gray Box Testing
    • GUI Testing
    • Installation Testing
    • Interface Testing
    • Interoperability Testing
    • Mainframe Testing
    • Manual Testing
    • Mutation Testing
    • Monkey Testing
    • Negative Testing
    • Penetration Testing
    • Penetration testing phases
    • Penetration testing framework
    • Protocol Testing
    • Recovery Testing
    • Regression Testing
    • Mobile Penetration Testing
    • Accessibility Testing
    • Sanity Testing
    • Scalability Testing
    • Security Testing
    • Spike Testing
    • Stability Testing
    • State Transition Testing
    • Static Testing
    • Gatling Load Testing
    • System Integration Testing
    • Structural Testing
    • Locust Load Testing
    • System Testing
    • Control Flow Testing
    • Unit Testing
    • Cypress testing
    • Volume Testing
    • Web Testing Application
    • What is Exploratory Testing
    • What is Stress Testing
    • What is Usability Testing
    • White Box Testing
    • Types of White Box Testing
    • Compatibility Testing?
    • Use Case Testing
    • Beta Testing
    • Integration Testing
    • Non Functional Testing
    • Non Functional Testing Types
    • What is Functional Testing
    • Functional testing types
    • Cookie Testing
    • Alpha Testing
    • Boundary Value Testing
    • Equivalence Class Testing
    • Glass Box Testing
    • SOA Testing
    • Smoke Testing
    • Visual Testing
    • Visual Paradigm
    • Model-Based Testing
  • Testing techniques
    • Software Testing Methodologies
    • Black Box Testing Techniques
    • Static Testing Techniques
    • Test Case Design Techniques
    • What is Static Analysis
  • Testing tools
    • Manual Testing Tools
    • Visual Testing Tools
    • Automation Testing Tools
    • Functional Testing Tools
    • GUI Testing Tools
    • Penetration Testing Tools
    • Performance Testing Tools
    • SOA Testing Tools
    • Accessibility Testing Tools
    • What is QTP
    • Regression Testing Tools
    • Security Testing Tools
    • Test Management Tools
    • Defect Management Tools
    • Code Coverage Tools
    • Test Coverage Tools
    • Defect Tracking Tools
    • Continuous Integration Tools
    • Install Bugzilla
    • Test data generation tool
    • Unit Testing Tools
    • Web Testing Tools
    • Stress Testing Tools
    • Performance Monitoring Tools
    • Mobile Testing Tools
    • Responsive Testing Tool
    • Cross Browser Testing Tools
    • Risk Based Testing
    • Database Testing Tools
    • WinRunner
    • What is Squish?
    • CubicTest
    • What is WinRM?
    • Bugzilla Tool
    • Code review tools
    • Penetration Testing Open Source Tools
  • Advance
    • Cyclomatic Complexity
    • Decision Table Testing
    • Decision Tree Algorithm
    • What is Continuous Integration
    • Mantis Bug Tracker
    • Equivalence Partitioning
    • Gantt Chart Software
    • Acceptance Testing Types
    • Load testing tools
    • Install TestNG
    • Install Unity
    • Defect Management Process
    • Test Plan Template
    • Testing Interview Questions
    • Testing of Mobile application
    • What is Test Automation Frameworks
    • Test Automation Framework
    • Application of Automation
    • Test Automation Process
    • Automation Testing Roles and Responsibilities
    • What is Instruction Cycle?
    • What is Cucumber?
    • 15 Best Popular Bug Reporting Tools
    • What is Automated Testing?
    • Software Maintenance Types
    • Types of Penetration Testing
    • Software Reliability
    • Best Gantt Chart Software
    • Code Coverage
    • Branch Coverage
    • Decision Coverage
    • Statement Coverage
    • What is Test Case
    • Types of Test Case
    • What is Test Scenario
    • Formal Review
    • Alpha Beta Pruning
    • What is Cyclomatic Complexity?
    • Test Coverage
    • How to Write Test Case
    • Testing Documentation
    • Performance Testing Life Cycle
    • Test Harness
    • Test Strategy
    • Software Incident Management
    • What is Debugging
    • What is Defect?
    • Listeners in TestNG
  • Inteview Questions
    • Automation Testing Interview Questions
    • Manual Testing Interview Questions
    • ISTQB Interview Questions
    • Cucumber Interview Questions
    • Software Testing Interview Questions
    • Penetration Testing Interview Questions

Related Courses

Software Testing Course

Penetration Training Course

TestNG Training Course

Typical Journey of a Software Tester

By Jesal ShethnaJesal Shethna

Typical Journey of a Software Tester

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.

Start Your Free Software Development Course

Web development, programming languages, Software testing & others

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 –

  1. The user should be able to log in successfully.
  2. Users should be able to book tickets in the system.
  3. Users should be able to cancel tickets in the system.
  4. 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:

  1. Verify that the user can enter the correct username.
  2. Verify that the user can enter a password.
  3. 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 –

  1. Verify that username; when not entered, the system throws an appropriate error.
  2. Verify that password; when not entered, the system throws an appropriate error.
  3. Verify that username and password when not entered, the system throws an appropriate error.
  4. Check that the the system throws an appropriate error message if if entering an incorrect password.
  5. 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 –

  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

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 –

  1. 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.
  2. Defect Summary – A short one-liner description of the Defect found.
  3. 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.
  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 – 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.
  7. Assigned to – Name of the developer or development lead.
  8. 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!

Recommended Articles

This is a guide to Typical Journey of a Software Tester. Here we discuss the introduction, the testing process, tools, requirements, and other explanations. You may also look at the following articles to learn more –

  1. Website Testing Tool
  2. Types of Software Testing
  3. System Software Functions
  4. Fraud Detection Software
Popular Course in this category
Software Testing Training (11 Courses, 2 Projects)
  11 Online Courses |  2 Hands-on Projects |  65+ Hours |  Verifiable Certificate of Completion
4.5
Price

View Course

Related Courses

All in One Software Development Bundle(600+ Courses, 50+ projects)
Python TutorialC SharpJavaJavaScript
C Plus PlusSoftware TestingSQLKali Linux
Price
View Courses
600+ Online Courses | 50+ projects | 3000+ Hours | Verifiable Certificates | Lifetime Access
4.6 (86,883 ratings)
Penetration Testing Training Program (2 Courses)4.9
TestNG Training (4 Courses, 2 Project)4.8
0 Shares
Share
Tweet
Share
Primary Sidebar
Footer
About Us
  • Blog
  • Who is EDUCBA?
  • Sign Up
  • Live Classes
  • Corporate Training
  • Certificate from Top Institutions
  • Contact Us
  • Verifiable Certificate
  • Reviews
  • Terms and Conditions
  • Privacy Policy
  •  
Apps
  • iPhone & iPad
  • Android
Resources
  • Free Courses
  • Java Tutorials
  • Python Tutorials
  • All Tutorials
Certification Courses
  • All Courses
  • Software Development Course - All in One Bundle
  • Become a Python Developer
  • Java Course
  • Become a Selenium Automation Tester
  • Become an IoT Developer
  • ASP.NET Course
  • VB.NET Course
  • PHP Course

ISO 10004:2018 & ISO 9001:2015 Certified

© 2022 - EDUCBA. ALL RIGHTS RESERVED. THE CERTIFICATION NAMES ARE THE TRADEMARKS OF THEIR RESPECTIVE OWNERS.

EDUCBA
Free Software Development Course

C# Programming, Conditional Constructs, Loops, Arrays, OOPS Concept

*Please provide your correct email id. Login details for this Free course will be emailed to you

By signing up, you agree to our Terms of Use and Privacy Policy.

EDUCBA Login

Forgot Password?

By signing up, you agree to our Terms of Use and Privacy Policy.

EDUCBA
Free Software Development Course

Web development, programming languages, Software testing & others

*Please provide your correct email id. Login details for this Free course will be emailed to you

By signing up, you agree to our Terms of Use and Privacy Policy.

EDUCBA

*Please provide your correct email id. Login details for this Free course will be emailed to you

By signing up, you agree to our Terms of Use and Privacy Policy.

Let’s Get Started

By signing up, you agree to our Terms of Use and Privacy Policy.

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to our Privacy Policy

Loading . . .
Quiz
Question:

Answer:

Quiz Result
Total QuestionsCorrect AnswersWrong AnswersPercentage

Explore 1000+ varieties of Mock tests View more