What is Software Testing All About? (Read This 10 Point Summary Carefully)

People have different definitions about testing. Some say testing is just about UI verification. And some say testing is just finding defects. But I tried to categorize the whereabouts of testing in the below 10 points.

Read each and every sentence carefully till the end. It has deep meaning that will be useful in every stage of testing life cycle in your project.

Quality should be the prime intention of every tester whether it is manual or automation. A good tester will always focus on improving the quality of the product and not just on finding defects.

What is Software Testing All About?

With all my experience I have tried to summarize testing in the below points:

#1. Testing is about quality

Testing is about providing a quality product to the customer Quality in terms of usage Quality in terms of look and feel Quality in terms of data integrity Quality in terms of security

#2. Testing is about ideas

Any given application can be tested in many ways. If you try out, each individual will propose a different approach and idea. We as a tester have to analyze and pick the most suitable approach.

For some cases a planned testing is very much required. For few cases random/ad-hoc testing helps to uncover issues. Evaluation of approaches should be done prior to testing. Applications which deal with huge amount of data should be tested in a different way than the ones which deal with huge number of users.

#3. Testing is about thinking like a customer

This is one of the common saying that we get to hear almost every day :).

When we test an application, we should always think from a customer (who will use the application) point of view. Relate the flows which ideally the customer would perform on the application. Check to see if the labels/text for messages and warnings are user friendly so that the customer understands the issue if any.

The application should be designed in such a way that user should flow through the process with ease. Negative combinations are equally important when testing from customer point of view. Not all end users will be well versed with the application and are prone to commit mistakes. Negative scenarios should be well handled within the system.

#4. Testing is about coverage

More coverage means more improved quality product.

List and execute all the test combinations. Try to uncover all the odd combinations that the customer is likely to do. Prepare requirement traceability matrix. I am sure not all do this, but prepare one formally or informally. List down all the boundary conditions and negative test cases. Prioritize all the test cases. Do at least one cycle of regression of Priority-1/Priority-2 test cases before completing the QA cycle.

#5. Testing is about finding defects

Defect is described as a deviation of actual result from the requirements. This holds very true in case of testing against requirements. When checking for negative scenarios or doing ad-hoc testing we still find defects.

Defects should be raised as soon as they are found and with all relevant data. People tend to miss out raising defects assuming that they are minor or just UI. Every valid defect which gets fixed adds to the quality of the product.

#6. Testing is about simplicity

There is no point in building an application which is of high complexity and of no use. Rather we should suggest for simple design which even a lay man can use.

Suggest for enhancements in the system. You can suggest improving the layout, labeling, button names and messages. Users will always prefer using a system which is less complex and easy to use and understandable. Simpler the better.

#7. Testing is about collaboration

Imagine we raised a defect and could not convince other team to get that fixed though it is valid. In this case we did not do our job completely. We should not be easily convinced with any justification from other teams unless it is documented and reviewed by stake holders.

These documents will be very useful in future for reference in case someone has to do a round of testing again. Document all the defects in any means Microsoft Excel or defect management tool. Document the test data, environment details etc. as well.

Some will argue here on how much documentation is sufficient. It depends on project to project. Keep above points in mind on any project other than Agile. For agile projects you can have different documentation approach. But avoiding documents is not recommended at all in any case.

#9. Testing is about time management

Defect found later in test cycle impacts the cost and time. If we can uncover more critical defects initially in the test cycle, the more time we get to test it better.

Testers always have a challenge in time management. We have to prepare the test data upfront, recreate the test data in case of failures. Track defects, test case status, check for regressions all in parallel. This makes time management really a challenge for us.

Challenges can be in terms of understanding requirements, testability of the requirements and feasibility of implementing the requirements in the current framework/architect. Challenges also can be in terms of defining environment for testing, coverage, dependency on other external components during testing phase.

But it’s important how you successfully overcome these challenges.

Remember, if you enjoy your work then only you can give your 100% to it :)

About the author: This awesome helpful post is written by STH author Sandhya Rani N. She is having 9+ years of extensive experience in software testing field on various manual and automation testing projects.