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 You Will Learn:
With all my experience I have tried to summarize testing in the below points:
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
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.
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.
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.
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.
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.
Testing is an activity which cannot be performed all alone.
It always has to be in collaboration with the other teams like requirement, design, development, process etc.
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.
Documentation plays a major role in testing phase.
Document the test scenarios, test cases. Prepare traceability matrix. Prepare checklist of test activities done. Prepare checklist of UI testing done. Capture all the screenshots/evidences.
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.
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.
=> Here are more tips on time and project management.
This may not be the last point, but surely attitude is a must for a good tester. You should have the right attitude in a right way to do your job right.
In the current competitive world, we need to keep ourselves updated. But having grip on the subject basics is important too.
All the hard work goes into vain if the base and approach is not correct.
Many people think testing is a monotonous and boring activity. But I myself being into Software testing for more than 9 years now, can surely say that it’s actually a very challenging and enjoyable work.
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.
Enjoyed reading? Do let us know your thoughts in comments below.