Golden Rules of Testing
In a previous post I've blogged about switching from waterfall to agile and how this impacts us testers.
It's true, the change can be difficult for some of us. However, fear not, somethings never change regardless of the development approach.
I've put together, what I think are the golden rules of testing that still apply. So when someone says "that's not how we do it in agile" (and believe me - they will) don't take none of it and stick with the basics.
- Start the software testing process by analysing requirements long before development.
- Integration testing (performed by IT)
- System testing (performed by professional testers)
- Acceptance testing (performed by business users)
- 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.
- If you like to be instant popular, don’t 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 in stead of opinions. It might take a while before your work colleagues appreciate the great job you're doing !
- Okay, 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.
- This one is obvious but who does it ?
- You cannot beat real data.
- Critical (must have, no work around)
- High (must have, work around possible)
- Medium (not business critical, but wanted)
- Low (nice to have)
- 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 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.
- There 's 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 : it 's 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 organise your testing. You can be very successful by using basic tools like MS Excel.