The golden rules of Software testing in STLC
by, 07-22-2013 at 06:17 AM (6860 Views)
The Golden rules of Software testing:
I have listed the golden rules of software testing based on my practical software testing experience and are as followed below.
Golden rules of software testing is all about finding the bug as early as possible in STLC:
Start the software testing process by analyzing requirements quite prior to development.
Make sure you have the below mentioned 3levels of software testing is followed:
Integration testing (performed by the configuration engineers and sometimes by the testers. Integration testing @ what is an Integration Testing? & Unit Testing & Integration Testing -- Developer or Tester )
System testing (performed by professional testers. System testing @ System testing )
Acceptance testing (performed by business users. This again has two levels: Alfa and Beta testing. You find the difference between Alfa and Beta testing @ What is the difference between alpha testing and beta testing? )
As a tester, dont expect too much of automated testing:
First let me state this : automated testing can be extremely useful and can be a real time saver. But it can also turn out to be a very expensive and invalid solution. More on this @ what type of test cases are used to do Automation Testing? & What do we lose with Automation compared to Manual Testing? .
Deal with resistance:
If you like to be instant popular, dont become a software tester! You'll find out that you are going to meet a great deal of resistance. It is very likely that you will end up being the sole defender of quality at a certain point. Other participants in the project will be tempted to go for the deadline, whatever the quality of the application is.
You should deal with this by reporting facts and figures instead of opinions. It might take a while before your work colleagues appreciate the great job you're doing!
Do regression testing every new release:
You've tested your new development successfully. Great!! But do the features of the application that you didn't change still work? You really should test this before going live. Regression testing @ Re-Testing and Regression testing .
Let real users test with real data:
This one is obvious but who does it? This can sometimes be done with real users of the product with their angle of usage and volume of data.
Yes You cannot always beat the real time data.
Give defects a test severity status:
Critical (must have, no work around).
High (must have, work around possible).
Medium (not business critical, but wanted).
Low (nice to have). Bug reporting @ Bug reporting .
Let product owners decide if a defect is to be fixed based on business priority:
A bit obvious, but I've seen testers make this decision and assign business statuses
Actively use these statuses for reporting and follow up! You also get more on the golden rules of bug reporting @ http://queforum.com/blogs/mikeh/5535...reporting.html .
This might be the most difficult goal to achieve:
You should talk about exit and entry criteria with IT. When is software good enough to deliver to a test team ? Think about server errors, certain level of IT testing achieved, when and how to build.
Same goes for business. What quality do they expect ? Who is going to make decisions on when to go live ? Make sure it is not you. Your role should be advisory.
Focus on the software testing process, not on the tools:
Theres a lot of talking about test management software. Sure, they can be very helpful indeed. These tools probably will take a lot of work out of your hands. But don't forget : its you who has to define the testing process. No tool is going to do that for you ! Think thoroughly about how you 're going to organize your testing. You can be very successful by using basic tools like MS Excel.
All the above said stuff in purely based my experience and you all can add more on this always