Depending on your technical skills, technical design meetings may be painful for you. Try to attend them anyway, if you have the opportunity. If you can even ask one question or make one comment that leads to a more testable design, you’re way ahead of the game.
XP has the wonderful benefit of making everyone on the development team conscious of testability. If you have to automate and perform acceptance tests, and it’s hard to do because your GUI is thick or hooked up to the back end in a way that you can’t test much behind the GUI, your next application is bound to be designed to be more testable. Unfortunately, your traditional development project won’t give you this golden opportunity. You can still raise these issues yourself (tactfully, of course) at design meetings. You can also continue to help facilitate communication between the business stakeholders and the programmers. You understand the application pretty well by now, and you probably are more familiar with the technical issues than the folks on the business side. Remember that communication value!
Hopefully, you had the opportunity to write executable tests. If so, when code is delivered to you for testing, you’ve got a major jump on the test automation.
You’re not on an XP team, but maybe there are still ways you can benefit from the advantages of ‘pairing’. Collaborate with a fellow tester to spike some test automation solutions. Engage a programmer in brainstorming automation solutions.
The refactoring practice, changing code for the sake of maintainability or efficiency, is important for test automators. Take a little time every day to make little changes to your automated test scripts that will help you maintain them and run them effectively in the long term. You never really get the chance for that big modification, so take tiny steps as you go.
Can the developers give you little bits and pieces to test? If you were able to convince them to take an XP-style approach to planning, this part is easy. They’ll develop testable chunks in short iterations and you can race along. If not, see what you can get delivered to you early. Maybe a programmer has a solution in mind but isn’t sure if it will scale well. Help by doing a performance test.
Involve the business experts as much as possible in testing. Keep simplicity in mind: What’s the simplest way to execute these tests? I hate to have to say it, but automation isn’t always the answer. You may have a one-time test, or you may need intelligent exploratory testing by a subject matter expert. Just remember to keep it as simple as possible! In most software projects, no matter what the methodology, you only have time to test the minimum.
Let Worry Be Your Guide
Risk assessments will help you and your stakeholders from worrying. Take a deep breath and determine what the minimum amount of testing will prove to the customer that the system behaves as specified. Lots of people have a negative view of the word ‘minimum’, but if it weren’t ‘good enough’, it wouldn’t be the minimum. Have courage: in most software projects, if you pull off the minimum testing, you’re golden.
XP builds risk assessment into the system with the planning game. The programmers always estimate all the stories and state their potential velocity, and the business experts or customers choose the ones most important to them that will fit into each iteration. With a more traditional project, look to a traditional risk assessment to help you. Identify risk areas, assessing the probability and impact of each. Work to mitigate the top one or two risks, then tackle the next one or two.