I have been in many companies, and if there is a cohesive experienced Agile project team, things can happen, with or without formal process. And majority of the time, it’s contractors providing this level of skill. If all know their roles, observe good Agile development practice, and happy to extend beyond their remit when necessary, that is a good start in any Agile methodology. Agile testing … is it different? The fundamentals should remain – strategise, plan and script. But there are other focus areas such as test automation and exploratory testing* which are essentials.
Don’t make the same mistake development did, and throw out good fundamental software engineering principles. Too many took Agile as call to throw out everything that had gone before. It led to a slew of half-baked developers, who baulked at idea of unit testing, and even testers.
Where do Test contractors fit in to this new structure? (the Test contractor being a Tester, Test Manager or QA Manager). Given testing on Agile projects, is commonly a role regularly palmed off to permanent individuals that show a vague interest, or express interest in development, the need for tester professional is even greater. I have been in many test contracts over the years, which are damage limitation exercises. So generally the role of Agile test contractor is to come in and address the problems that the above approach brings. Though not everybody on a project needs to be an expert, you need key individuals who will lead the way for others. In testing, this has increasingly been the role of testing contractor.
How can QA help when all testing is outsourced? This does not remove the need for internal QA, or you will be beholdent to the offshore company’s process. Too often I hear of situations where releases are passed, when plainly no testing has taken place. Or products are delivered that have been veyr poorly tested. Yes, you can simply not use the company again, but an even better approach is to define your own set of standards of delivery. Remember, your company is paying for a service so you are within your rights to assert your own processes for accepting offshore testing work. As trust builds, this QA process can become lighter. An offshore testing company will not work to your company culture by default, so educate them, so that they can accommodate that into their process.
Test frameworks are imperative for Agile. What these test frameworks are doing is building up test suites of unit tests, which can be executed on their own or as part of large suite (to cover a scenario, for example). This obviously isn’t UI driven, which is important testing perspective. Functionality is separated from design. Now testers can use these test cases with another product, such as Selenium (though does still require some coding knowledge). You can follow a purist route and stick with recording test tools, but maintaining those kind of test suites is lengthy and arduous, as they have a heavy dependency on UI elements to execute. Testing from UI is important but these types of tests can be reduced by careful application of ATDD.
You are not going to get people who do testing as task, rather than role, getting their hands dirty on this – this is where true testing skills are proved. Contract Testers do need development skills for the future, or we will see an unhealthy new breed of developer/tester combinations. But I would say that you are more likely to get a tester who wants to code, than a developer who wants to test. So Testers, step up to the mark!
I came across this article from 2006, and the whole article is worth a read, though a little too vitriolic for my liking. One particular part caught my attention.
Knowledge Monopolies. The ‘dictators’ detailed in (b) also, in the absence of documentation, had absolute control of the code should the developed system ever be launched. They would be the only people in the organisation with the knowledge to maintain and enhance the code going forward, thus maintaining their job security, and guaranteeing pay rises above the market rate. I really noted some serious arm bending on pay by these guys – squeezing in one case the budgets to such extent that previously turned down outsourcing deals were back on the burner.
Agile methodology, as with any other methodology cannot account for individual remits of human beings. Along with our weaknesses, strengths, communication skills, team skills … the list is both endless and almost infinite in permutations. I have long been convinced that permenant work, the concept of being a “permanent” member of a work society, with all the strange family-like behaviours, was fundamentally at odds with Agile. Generally, people in their jobs are always conscious of keeping their jobs.
Main reason for resistance to change in the business, is that people are comfortable with things a certain way. They don’t care if lack of change hurts the business – even if it could break the business, ultimately individuals have their own life remits, and are not as emotionally attached to a company as their daily behaviour would lead you to believe. This is where a contractor/consultant becomes very useful – we have no real agenda beyond providing a service. We are not interested in the inner workings and politics. We, in fact, delight in pointing out issues that permanent employees would prefer to hide. Because we want to do things right, it’s not about climbing the corporate ladder.
*Exploratory testing is broadly testing out of scope, but still relevant. ET pushes the boundaries of scope and scenarios, to uncover potential holes, needed improvement, or even a scenario not yet contemplated. This is no new exercise – testing generally has had broader remit beyond defined scope of requirements. Stakeholders get a bit agitated if they don’t understand the full benefit of this kind of testing.
jaffamonkey 