Software testing engineer - A beginner's guide

This article is a beginner's guide for those who want to start their career in software testing. Software testing is one of the crucial phases of the software development life cycle. Software testing has evolved significantly over time. Earlier it was considered as an inferior job type as there is hardly any creativity, learning, and value involved in it. But over time, the testing is not just limited to manual validation of the application under test.

Nowadays a lot of value addition and learning has been associated with testing as a career. Nowadays, automation testing is a mandatory skill for every person who wants a breakthrough in a testing job that involves the same programming skill as needed by a developer. Moreover, API, security, database, load are crucial aspects of a strong testing profile. After spending a couple of years, you have to be really into a developer's shoe for a long term career as a software test engineer.

A software test team is responsible for the quality of the product, and in today's world of high competition, the slightest quality compromise and the defect will lead to drastic monetary loss, a decline of the user base, and even failure of the product. Therefore, software testing is a highly demanding role nowadays.

You'll have a great career path if you broaden your profile to include a multitude of tools and technologies that covers the entire aspects of testing. Just like a full stack developer, a full stack tester is in high demand who can cover the functional as well as non-functional aspects of testing for the product. A tester is expected to think from a business point of view as well, unlike a developer who just codes as per the design documents.

Certification from ISTQB (International Software Testing Qualifications Board) is a good way to kick start testing as a career for the beginner or a newbie as it will give you an upper edge over the non certified beginners.

Software Testing Guide for beginners:

Below is the software testing guide which a beginner must go through to get an insight and understanding of the software testing fundamentals, process, methodology, and phases, moreover the below tutorial will help you in kick-starting the preparation for ISTQB certification. This article will cover:

1. Testing in software engineering
2. Types of Testing
3. Test life cycle
4. Phases of software testing
5. Bug/defect life cycle
6. Different attributes of a bug
7. Verification, Validation and V-Model
8. Software test deliverables and key performance indicators

What is testing in software engineering ?

Testing is a process of finding faults and defects in the application under test so that the quality of the product can be improved and it is made defect free before it is rolled out for the actual end users to use. The purpose of testing is to make sure that the product is living up to the business expectations i.e. all the functional requirements are fulfilled by the product. Moreover, the product is also validated for the non functional aspects. For e.g. the product should be robust enough to bear the intended user load, the product is secure enough to maintain the integrity of user data and not vulnerable to hackers, and lastly, the product should be easy to use and enhance the user experience so that the user base can be retained.

What are the types of software testing ?

The entire testing has been categorized into two types:

Functional testing: Every product in existence has some purpose to serve. The product under development is meant to serve something to its end-user. The validation of a product to ensure that it delivers the intended services to its end-users is called functional testing. In other terms, the testing carried out to ensure that the product is fulfilling and conforming to all its business requirements is called functional testing.

Non-functional testing: Non-functional testing is carried out to test the non-functional aspects of the product. For e.g. the product should be robust enough to bear the intended user load, the product is secure enough to maintain the integrity of user data, and not vulnerable to hackers, and the product should be easy to use and enhance the user experience so that the user base can be retained.

What is Test life cycle ?

The below image depicts the typical STLC phases.

Requirement Analysis: During requirement analysis, brainstorming sessions are conducted, requirements received from the business team in the form of SRS-(system requirement specification), FRS- (functional requirement specification), and BRS-(business requirement specification) are analyzed, reviewed, and understood from a QA perspective. Reviews and walkthroughs are conducted and lastly, RTM (requirement traceability matrics) is prepared by the test team. RTM is nothing but the mapping of test cases with requirement IDs. RTM is useful to make sure that the test cases have covered all the requirements and none of the requirement is missed from testing coverage.

Test planning: In the test planning phase, important parameters required for testing and conditions are identified and documented. A test plan specifies the important parameters needed for testing and defines the blueprint, approach, and road map for testing. You can refer to my in-depth article on test planning and test plan format.

Test Case creation phase: A test case is a document used to validate the features, components, and scenarios of an application under test. A test case specifies the preconditions, inputs, steps to execute, and expected result of an operation or feature to be tested. During test case creation, the scenarios, test input, preconditions, and steps to execute are identified and documented in a test case document.

Test case execution phase: During test case execution, the features and components of an application under test are validated by referring to the steps, and by applying the appropriate test data and preconditions. The actual result is matched against the expected result and the status is updated accordingly. Any mismatch in the expected and actual result along with other defects are logged in the defect logging tool during test execution.

Test cycle closure: Test cycle closure is an activity which is performed after the conclusion of test execution. The test results, test metrics, and test report have been generated and key performance indicators are shared with the stakeholders.

What are the phases of software testing ?

Unit Testing:Unit testing is done by the developer in the development environment. A standalone unit or component is validated during unit testing before rolling it out to the test team for functional testing.

Integration Testing: Integration testing is the process of validating the interfacing between the integrated components.

System Testing: System testing is testing the system as a whole. The entire end-to-end testing on a fully integrated system i.e. when all the components are integrated and the entire system is tested to ensure that the system is in compliance with all the functional requirements.

User Acceptance Testing: In layman's terms, Acceptance testing is done by the client once the system testing is concluded. Acceptance testing is done outside the QA environment typically in a client's environment usually by the business team.

There are two types of acceptance testing: Alpha testing, and beta testing.

Alpha testing: Done by the client at the client's location, under the client's environment.

Beta Testing: The product is released for the end-users to use with the beta version. The end-users start using the product and may encounter issues, defects that can later be fixed.

Retesting and Regression: Retesting and regression testing comes into the picture in subsequent iterations of integration and system testing. The bug fixes are validated in retesting, whereas, in regression testing, the side effects of code changes are validated. i.e. the bug fixes, implementation of change requests, or any activity which results in code change may result in unintended side effects on the working modules. These side effects on working components of the product are identified and reported during regression testing.

Sanity and Smoke: Smoke testing is performed by the test team every time the build (the product) is rolled out to the test team for testing. It is also called build acceptance testing. The purpose of smoke testing is to make sure that the build (product) is stable enough to go for more rigorous testing. Smoke test suite (test cases) are executed and as per the build acceptance criteria, the build is either accepted or rejected.
Sanity testing is a sub-set of regression testing, it is done to validate the rationality of the product and usually performed when there is no time for in-depth regression testing (usually in a very frequent release cycle).

What is bug life cycle ?

During the entire software testing process, the defects are continuously identified and reported. A defect has to go through different stages from the moment it is logged by the tester. These stages are called bug or defect life cycle. A defect or bug life cycle is a different set of states which a defect has to go through. The status of a bug during varied states may differ from organization to organization and also depends upon the defect tracking tool which is being used in the project. But a typical set of states remain identical as below:


New: This is the very first state in which a defect is identified by the tester.

Assigned: The defect is assigned to the development team for fixing.

Open: The open states implies that the defect is undergoing analysis and fixing. During this state, the defect may either be fixed, or rejected, or maybe deferred by the development team.

Deferred: The defect will be taken care of at a later stage.

Retest: Once the defect has been acted upon by the developer, it is reassigned to the tester for retesting.

Fixed: During retesting, if the defect no longer exists, then it is considered as fixed.

Reopen: During retesting, if the defect still persists, then it is reopened and assigned back to the development team.

closed: After the test cycle completes, the fixed bugs are closed.

Severity and priority- Important attributes of a bug

The difference between severity and priority is a very widely asked question in testing interviews. The severity of a bug is an attribute that determines how badly the bug is affecting the functionality of the product. The severity can be assigned a value of either high, medium, or low.
Whereas priority is an attribute that determines how quickly we want the defect to be fixed. The priority can be assigned as p1, p2, p3 ad so on. A "P1" priority implies the highest priority and a defect with P1 priority should be acted upon immediately.

There may be instances where the severity may be low but priority might be high for a bug. For e.g. there is a typo error in one of the passages displaying on the product description page of the application. In this case, the severity is low because it does not require a big effort to fix and can be fixed in no time, but the priority might be the highest as a typo error may cause serious business impact.

Verification, Validation and V-Model

Verification: Verification is a process in which reviews, walkthroughs, and inspections are conducted across every activity to make sure that we are building the product in the right way. It is the evaluation of the product development process.

Validation: Validation is a process in which the expected behavior of an application under test is validated against the actual behavior. The actual testing or test case execution process comes under validation.

V-Model: V-model (also called verification and validation model) is one of the SDLC models in which there is corresponding validation activity for every verification step. In other words, every development activity is associated with some test activity.

What are Software test deliverables and KPIs ?

Software test deliverables are the artifacts that are to be shared with relevant stakeholders. QA release notes, test results, test reports, test summary reports, bug reports, test cases, RTM are a few of the important test deliverables.

QA Release note: After the end of a test cycle, a QA release note is prepared which contains details of important test indicators like the modules which were tested, bug IDs that were retested, and link to test results, test summary reports, bug reports, and test cases.

Test Results: Test results are the executed form of test cases in which the status and actual results of the test scenario are updated.

Test summary: Test summary is an important artifact that contains a summary of test execution like Number of test cases executed, Number of test cases that are passed, Number of test cases that are failed, Number of test cases that are on hold, pass percentage, fail percentage. Test summary is helpful in determining the quality of the application under test.

RTM: RTM-Requirement traceability matrics is an artifact that maps the functional requirements IDs with the corresponding test case IDs. A sound RTM ensures complete test coverage and avoids any chance of missed test coverage.

Bug Report: A bug report can be extracted from the bug tracking tool. It gives the attributes and statuses of bugs that were lodged against the application under test It contains the Bug id, bug description, its severity, priority, current status, assigned to, etc.

Defect density: Defect density is one of the key performance indicators which shows the quality of code. It is the number of defects per thousand lines of code. The quality of code is inversely proportional to the defect density i.e. lower the defect density, higher the code quality. It can be calculated by dividing the number of defects by the size of the product. Here, the size of the product is the total number of lines of code written for the product.

Defect density= (Number of defects /Total number of lines of code) x 1000

This gives us the defect density per thousand lines of code.

Defect leakage: Defect leakage is another Key Performance Indicator that represents the quality of testing performed. It is the number of defects that are missed or slipped in the testing phase but caught in the UAT phase.

Defect leakage= Number of defects caught in the UAT/Number of defects caught in internal QA testing