Switching from Waterfall to Agile is known to directly impact testers.
It's true; the change can be difficult for some of us. However, fear not, some things 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.

Read these simple golden rules for software testing based on my own experiences.

It’s all about finding the bug as early as possible:

• Start the software testing process by analyzing requirements long before development.

Make sure you have these 3 software testing levels:

• Integration testing (performed by IT)
• System testing (performed by professional testers)
• Acceptance testing (performed by business users)

Don’t 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 an invalid solution.

Deal with resistance:

• If you like to be instantly 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 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:

• 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.

Let real users test with real data:

• This one is obvious but who does it?
• You cannot beat real 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)

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.

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:

• There is a lot of conversation 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 organize your testing. You can be very successful by using basic tools like MS Excel.

Ray Claridge is a Product Manager at IPC Media in the UK. He specializes in project and product managing; web, search; SEO; Oracle; CMS; Automation; UAT Management; E-commerce; Scrum Master and Episerver. Read more of Ray’s blog at: http://www.testertroubles.com/ Connect with Ray via LinkedIn: http://www.linkedin.com/in/rayclaridge/