Testing Software

The testing process is a continuous process to improve the quality of the end product.

We carry out two types of testing ( Manual as well as Automated )  during STLC since both these testing types needs the specialized skill set to accomplish the task.

The goal of testing software is not to find bugs or to make software better. It’s to reduce risk by proactively finding and eliminating problems that would most greatly impact the customer using the software. You can never find all the bugs or defects in a piece of software and you can never test every possible input into the software.

The focus and main idea behind software testing are to reduce the risk that the customer is greatly impacted in a negative manner when using the software.

Typically this is achieved by first prioritizing what areas of the software are likely to have the biggest impact (i.e. risk), and then deciding on a set of tests to run which verify the desired functionality in that area.

When the actual functionality deviates from the desired functionality, a defect is usually logged and those defects are prioritized based on severity. Some defects get fixed, other defects are low enough impact that they are just noted and left in the system.

Common types of software testing are-

Black Box Testing- Black-box testing is simply testing as if the software itself was a black box. It’s one of the most common forms of testing and really a way to describe a whole category of testing is black-box testing.

When you do black-box testing, you are only concerned with inputs and outputs. You don’t care how the actual outputs are derived. You don’t know anything about the code or how it works, just that for a given set of inputs into the software, a given set of outputs should be produced.

White Box Testing- White-box testing is when you understand some of the internals of the system and perhaps have access to the actual source code, which you use to inform your testing and what you target. White-box testing is pretty much the opposite of black-box testing.

With white-box testing, you have at least some idea of what is going on inside the software. Oftentimes, unit testing is called white-box testing.

Acceptance Testing- The basic idea of acceptance testing is that you have some tests which test the actual requirements or expectations of the customer, and other tests that run against the system as a whole. Sometimes it’s called user acceptance testing (UAT).

Sometimes it’s called system testing. This kind of testing could be testing the functionality of the system or it could be testing the usability of both. The idea is that acceptance testing tests what is expected versus what actually happens.

Automated Testing- Automated testing is any testing in which the execution of the test and the verification of the results is automated.  You can automate the testing of a web application by running scripts that open up a web page input some data push some buttons and then check for some results on a page.

More and more of testing is moving towards automated testing because manually running through test cases over and over again can be tedious, error-prone, and costly–especially in an Agile environment where the same set of tests may need to be run every two weeks or so to verify nothing has broken.

Regression Testing- This testing is done to verify that the system still works the way it did before. The purpose of regression testing is to make sure that the software doesn't regress in functionality.

This is extremely important with Agile development methodologies where software is developed incrementally and there is a constant potential that adding new features could break existing ones. Most automated tests are regression tests.

In fact, you could really make the argument that all automated tests are regression tests since the whole purpose of automating a test is so that it can be run multiple times.

Functional Testing- Functional testing is another broad term used in the testing world to refer to testing activities where what is being tested is the actual functionality of the system.

This might seem obvious. But, it turns out that you can test all kinds of things that aren’t related to functionality, like performance, usability, resilience, security, scalability.

So, functional testing is the kind of testing where you are really concerned with the system doing what it is supposed to do from a functional perspective.

Exploratory Testing- The idea behind exploratory testing when done correctly is that you have some guidelines and a basic plan of which application areas you are going to test and the ways you are going to test them.

Oftentimes, exploratory testing sessions are recorded, so that if an error is found, the problem can be reproduced by retracing the steps taken by the exploratory tester.

Acknowledge its merits, as exploratory testing can often uncover bugs that no rational test case would have ever been designed to exploit.

Others forms of testing-

• Performance of the application based on certain scenarios
• Load testing how an application performs under a heavy load
• Recovery testing- Recovery from error conditions or hardware issues
• Security testing- The security of the system
• Stress testing
• Usability testing
• Accessibility testing

 

Manual testing is the foundation to start the automation, it cannot be ignored for automation testing.

 

We follow different types of tests as a part of the testing cycle - 

1.  Functional tests
2. Business rule tests
3. Navigation tests (links, buttons, etc.)
4. Integration tests (integration with other modules)
5. Security tests
6. End to end tests
7. Negative tests
8. Load and performance tests

Our Testing Strategy is- 

a. Alpha Testing( Unit Testing )

b. System and Integration Testing

c. Performance and Stress Testing

d. User Acceptance Testing

e. Batch Testing

f. Automated Regression Testing

g. Beta Testing