Do you still only do UI focused manual testing? Covering large area’s every release over and over again? Then read on…
Here’s the REAL BASICS on what you should be doing:
- TDD – Your development teams should practice TDD as a standard, see my other post for where to start.
- ATDD – The newest kid on the block is moving the specification into the code itself, this means that developers and testers and product owners can get together and write business flow language in your code from your acceptance tests. Some of the most advanced techniques are being done by Gojko Adzic.
- Load Testing – LoadRunner is the market leader however there are new tools being created such as MSLoad in Visual Studio.
- Security Testing – SAST and DAST means Static Analysis Security Tools and Dynamic Analysis Security Tools. Testing the security of the code whilst it’s in source code (SAST) or testing it whilst it’s running (DAST). This can save sending it off to a third party company but be warned there is no magic bullet for security testing as threats are always evolving.
- UI Testing – QTP \ Selenium etc. – There’s still a place for automated end to end testing, QTP is still the market leader in this space and can do modularized testing however there are questions around its multi-browser \multi device capability (these are being addressed in later versions).
Run the tests as often as you can:
- The faster the feedback the better, the code is still fresh in the developers mind, the business users remember their specification and the defects don’t get fixed at the end of your release raising everyone’s stress levels
- If you can, put the tests in the developers Continuous Integration build (CI)
- If you can’t, consider running the tests overnight
- If you can’t, consider running the tests at the end of each sprint
- … you get the idea!