Software Testing Tutorial: How to Perform Testing

No software can ever be completely perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify the quality. In order to increase the quality, it is very important to ensure the effective performance of software application. Software testing is required to ensure that applications run without any failures. In this article, we will tell you everything you need to know about different aspects of testing. In continuation to the previous blog on what is software testing, here I will dive deeper and cover the most important topics in software testing.

Introduction to Software Testing

Today's world of technology is completely dominated by machines, and their behavior is controlled by the software powering it. Software testing provides a cost-effective solution to all our worries.

Software testing is the process of evaluating the functionality of a software application to find any software bugs. It checks whether the developed software met the specified requirements and identifies any defect in the software to achieve a quality product. It is basically executing a system to identify any gaps, errors, or missing requirements contrary to the actual requirements.

It is also stated as the process of verifying and validating a software product. It checks whether the software product:

• Meets the business and technical requirements that guided its design and development
• Works as per the requirement
• Can be implemented with the same characteristics

Now, let's move further and gain some insights on the basics of Software Testing.

Software Testing Basics

First, I will answer the question: what is the software development life cycle?

Software Development Life Cycle

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop, and test high-quality software. The SDLC aims to produce high-quality software that meets or exceeds customer expectations and reaches completion within time and cost estimates. The following diagram depicts various phases involved in SDLC.

Fig: Software Development Life Cycle - Software Testing Tutorial

Requirement Phase

Requirement gathering and analysis is the most important phase in the software development lifecycle. Business analyst collects the requirement from the customer/client as per the clients business needs and documents the requirements in the business requirement specification (document name varies depends upon the Organization).

Analysis Phase

Once the requirement gathering and analysis is done, the next step is to define and document the product requirements and get them approved by the customer. This is done through the SRS (Software Requirement Specification) document. SRS consists of all the product requirements to be designed and developed during the project life cycle.

Design Phase

This phase has two steps:

1. HLD — High-Level Design — It gives the architecture of the software product to be developed and is done by architects and senior developers
2. LLD — Low-Level Design — It is done by senior developers. It describes how each and every feature in the product should work and how every component should work.

The outcome from this phase is the High-Level Document and Low-Level Document, which works as an input to the next phase

Development Phase

Developers of all levels (seniors, juniors, freshers) are involved in this phase. This is the phase where you start building the code for the software.

Testing Phase

When the software is ready, it is sent to the testing department where they test it thoroughly for different defects. They either test the software manually or using automated testing tools, and they ensure that each and every component of the software works fine. Once the QA makes sure that the software is error-free, it goes to the next stage, which is the implementation.

Deployment and Maintenance Phase

After successful testing, the product is delivered/deployed to the customer for their use. Deployment is done by the deployment/implementation engineers. Once when the customers start using the developed system, then the actual problems come up and needs to be solved from time to time. Fixing the issues found by the customer comes in the maintenance phase.

 If you wish to learn more about different stages involved in the software testing process, then you can read this blog on Software Testing Life Cycle. Having understood this, let's move further and learn more about the V & V model.

Verification and Validation Model

V model is now one of the most widely used software development processes. Introduction of the V model has actually proved the implementation of testing right from the requirement phase. V model is also called a verification and validation model.

What Is Verification and Validation in Software Testing?

Verification: Verification is a static analysis technique. In this technique, testing is done without executing the code. Examples include: Reviews, Inspection, and walkthrough.

Validation: Validation is a dynamic analysis technique where testing is done by executing the code. Examples include functional and non-functional testing techniques.

In the V model, the development and QA activities are done simultaneously. There is no discrete phase called testing, rather, testing starts right from the requirement phase. The verification and validation activities go hand in hand. To understand the V model, let's look at the figure below: Fig: Verification & Validation model – Software Testing Tutorial

In a typical development process, the left-hand side shows the development activities and the right-hand side shows the testing activities. It should not be wrong if I say that in the development phase both verification and validation are performed along with the actual development activities.

LHS

As mentioned earlier, left-hand side activities are development activities. Normally, we wonder: what testing can we do in the development phase? But this is the beauty of this model, which demonstrates that testing can be done in all phase of development activities as well.

RHS

Right-hand side demonstrates the testing activities, or the Validation Phase.

As you have gained some insights on this, let's move further and see the different methods in which software can be tested.

Software Testing Methods

There are three methods for testing software, and they are as follows:

• Black-Box Testing
• White-Box Testing
• Grey-Box Testing

Black-Box Testing: It is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester.

White-Box Testing: It is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.

Grey-Box Testing: It is a testing technique performed with limited information about the internal functionality of the system.

Software Testing Levels

A level in software testing is a process where every unit or component of a software/system is being tested. The main goal of system testing is to evaluate the system's compliance with the specified needs. There are various testing levels, which help to check behavior and performance for software testing. These testing levels are designed to recognize missing areas and reconciliation between the development of lifecycle states. In SDLC models, there are characterized phases such as requirement gathering, analysis, design, coding or execution, testing, and deployment.

All these phases go through the process of software testing levels. There are mainly four testing levels and they are:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

Basically, it starts with the unit testing phase and ends with acceptance testing.

Software Testing Documentation Artifacts

Documenting the test cases will facilitate you to estimate the testing effort you will need along with test coverage and tracking and tracing requirement. Some commonly-applied documentation artifacts associated with software testing are:

1. Test Plan
2. Test Scenario
3. Test Case
4. Traceability Matrix

Let's discuss each of them in brief.

1. Test Plan: Test plans provide the outline strategy that will be implemented for testing the application.
2. Test Scenario: Test scenario can be considered as a single line statement that notifies the area in which your application will be experimented. This artifact is needed for ensuring the overall procedure tested from the very start to end.
3. Test Case: It is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application. Many types of test cases are being checked during testing. They are:
   • Functional test cases
   • Negative-error test cases
   • Logical test cases
   • Physical test cases
   • UI test cases
4. Traceability Matrix: It is also known as a Requirement Traceability Matrix (RTM). It contains a table which sketches the requirements when your product's SDLC model is being created. This documenting artifact can be implemented for forward tracing, which is to go from designing to coding or can be implemented for backward tracing as well which is the reverse of the forward tracing.

What Is the Defect Management Process?

Generally, defect management can be defined as a process of detecting bugs and fixing them. It is necessary to say that bugs occur constantly in the process of software development. They are a part of the software industry. That is because of the fact that software development is quite a complex process. The team members are usually placed in strict time frames. They must write large pieces of code every day, and they usually don't have time to think about how to avoid bugs. Hence, every software development project requires a process that helps to detect the defects and fix them.

The process of defect management, or bug tracking, is usually conducted at the stage of product testing. Without realizing this, it would be hard to understand the nature of defect management. Software testing can be conducted in two different ways. Usually, the developers test their product themselves. However, there is also a type of testing that is based on user involvement. The final users are often provided with an ability to report on the bugs they have identified. Nevertheless, this is not the best way of testing, because the users might not be capable of finding all the bugs.

The defect management process usually includes four steps.

1. The first step is the stage of the defect detecting
2. The second step of the bug management process is dedicated to the formulation of bug reports
3. The third step is the stage of bug fixing
4. During the final step, the bug list is created

Bug Life Cycle

A defect life cycle is a process in which a defect goes through various phases during its entire lifetime. It starts when a defect is found and ends when a defect is closed, after ensuring it's not reproduced. A defect life cycle is related to the bug found during testing.

It can vary from organization to organization and also from project to project based on several factors like organization policy, software development model used (like Agile, Iterative), project timelines, team structure etc.

Bug or defect life cycle includes the steps as illustrated in the below figure:

Fig: Bug life cycle – Software Testing Tutorial

1. New: When a defect is logged and posted for the first time. Its state is given as new.
2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to a corresponding developer and the developer team. It’s state given as assigned.
3. Open: In this state, the developer has started analyzing and working on the defect fix.
4. Fixed: When a developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to the testing team.
5. Test: At this stage, the tester does the testing of the changed code which the developer has given back to him to check whether the defect has been fixed or not.
6. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.
7. Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.
8. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
9. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate”.
10. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.
11. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are the priority of the bug may be low, lack of time for the release or the bug may not have a major effect on the software.

This was all about the Bug Life Cycle and Defect Management Process. Now, let's see what are the challenges with Manual Testing.

Challenges With Manual Testing

Manual testing means the (web) application is tested manually by QA testers. Tests need to be performed manually in every environment, using a different data set and the success/ failure rate of every transaction should be recorded.

Look at the above image of a poor chap who manually verifies the transactions recorded. The challenges he is facing cause fatigue, boredom, delay in work, mistakes, and errors due to manual effort. This leads to the invention of automation testing.

Now, let's delve into the last topic of software testing — how automation testing beats manual testing.

Automation Testing Vs. Manual Testing

Automation testing beats manual testing every time. Why? Because it is faster, needs less investment in human resources, is not prone to errors, frequent execution of tests is possible, and supports regression and functional testing.

Let's take a similar example to the one mentioned earlier. Suppose there is a login page and we need to verify if all the login attempts are successful, then it will be really easy to write a piece of code, which will validate if all the transaction/ login attempts are a success or not (automated test case execution).

Moreover, these tests can be configured in such a way that they are tested in different environments and web browsers. What else can be done? You can automate the generation of result file by scheduling it for a particular time during the day. Then, you can also automate the generation of reports based on those results and what not.

The key point is that automation testing makes a tester's job a whole lot simpler. Check out the image above that shows a more relaxed environment in which the same tester is working. If you wish to know more about automation testing and the widely-used automation testing tool, Selenium, you can refer to this Selenium tutorial.

This is all for now about how automation testing is sparkling its way in the field of software testing! I hope you found this article informative and that it has helped in adding value to your testing knowledge.