Bloggo back to the blog
Testing waterfallacy (3 of 3)-->
In my previous entry in this series, I spoke of collaboration of testers with developers. I will start this post about the part of the company, the employer.
What ought to change in order to level the field between testers and developers, is the difference in treatment the two disciplines receive from their employer. It is still the norm in the industry, for companies to treat testing as a low entry-level profession, with a substantially lower wage than programming.
Especially in the context of agile development, a tester has to bring either strong consulting or technical skills in order to be effective.
Testing as a starting job?
In the past, many organizations treated testing as starting job, with promising individuals being selected to become programmers. Preciously few do it the other way around, setting the bar for testing so high that one first has to prove one’s self as a programmer, before being invited to become an elite tester. This might be a fair approach when building really safety-critical systems, and then for only some of the testing jobs.
In numerous situations, a case can be made for a different approach, selecting about half of the testers from the business based on their domain knowledge and communication skills. (Technical testing skills can readily be trained.) The other half ought to have a technical background. It is highly desirable if some of those technical testers have actual programming experience, but it’s not a must-have. What I’d be looking in recruiting technical testers, besides a skeptical mindset and fair soft skills, is programming affinity rather than experience. In a similar fashion, if I want my programmers to be test infected; that does not mean they need actual job experience as software testers.
On an agile team it is highly desirable if some of the team members are able to operate in multiple roles, e.g. designer or programmer and tester. How many people will choose to such a dual role, if the organization does not support this as a career path which is well rewarded? I’m not just talking about the financial aspects. In all likelihood, employees will need more time to maintain up-to-date with two disciplines rather than one. Actually giving them extra hours to do so would be a good perk for the job. Sending them to more trainings and conferences would be another.
Increased support for agile teams
With the frequent delivery scheme of agile projects, requests for “support tasks” will also be much more frequent, requiring more resources than waterfall-style development. Teams will need environments, testers will need accounts, test data, and tools. If teams cannot do all deployment tasks, or if access limitations apply on some environments, other departments in the company will need to facilitate them. The whole team will suffer, if support is lacking, or not given in a cooperative mode.
In my experience, it’s always the testers who will feel the most pain. Why? Because testing has a lot of prerequisites, and few workarounds. Some code will still be written, though testing may be blocked. Some will even act as if “Testing owns the problem” if, for example, realistic test data is missing, or if deployment on the acceptance test environment cannot be done often enough.
In most agile projects, some testing will still be on the critical path of the project, to be done after coding appears to be complete. For example a chain test or a shadow run of an application is very hard to place inside an iterative process. Of course, this may be kept to a minimum with vision and support. If the appropriate environments are available early on, and if much of the tests can be performed on a proof of concept, valuable time can be saved. For example, I have been in multiple projects where formal performance tests were executed on a proof of concept. By having a separate group outside the team execute those tests, re-running those scripts on the finished product becomes a trivial and less time-consuming exercise.
What’s the role of the organization in this? It is in their interest, to minimize the amount of time spent by testing activities on the critical path. The business case must be recognized, that lots of money (hours, weeks) can be saved by providing the necessary resources (environments, hardware, licenses) for these test levels that threaten to be on the critical path.
Does non-agile testing have to be on the critical path?
People frequently ask me, how they can apply or introduce agile testing practices in a non-agile project. In my opinion, all it takes is some creativity, and a pro-active attitude. For example, how can you determine whether your test environment is configured properly, if you sit and wait until the delivery of the product to be tested? Isn’t that a good argument to use to get a preliminary delivery of the product? And if you’ve got that, all you need to do is to ask which features are already testable…
In a similar fashion, it is very important to facilitate agile acceptance testing. In the ideal situation, most acceptance testing takes place during (or prior to) the iteration. If the team manages to involve the right people, and obtains accurate acceptance criteria (examples == tests) early on, then two things are ensured. The team will deliver the right product, and most of the emotional acceptancewill be off the critical path.
What the business needs to do here, is merely to acknowledge the importance, and free people from other tasks. If the right people from the business can devote enough of their time to the team, a project delay might be avoided. If the people who want to be involved in the process (end users, for example) are given the opportunity to do preliminary acceptance testing during or between the iterations, then such tests will be taken off the critical path. If the end users get to test the product as it is being developed, some of the changes they will ask for can still be realized on time.