Med jämna mellanrum dyker det upp nya utvecklingsmetoder. De senaste jag känner till är Unified Process och Agile. Det är därför något förvånande att utvecklingen inom test verkar stå relativt stilla. Vi har standarder som IEEE-829 som har 24 år på nacken och numera ISTQB-syllabus som bygger på IEEE 829 och redan när den kommer ut känns gammaldags. Medan utvecklarna och kravskrivarna fokuserar på att dokumentera allt mindre så fortsätter test att köra i samma gamla hjulspår. Jag brukar fråga de som har gått ISTQB-foundation kursen och certifierat sig om de har någon nytta av det de lärt sig. Svaret blir att tentan är mest ordförståelse men att kursen i sig var delvis intressant. Frågan är då om det är bra att gå en grundkurs eller om det är skadligt att bli itutad att det här är det som gäller? Det jag själv blir mest trött på är att det är så svårt att försöka få andra att börja fundera i mer kreativa banor som att använda utforskande testning eller testverktyg på annat sätt än plug-and-play som bevisligen misslyckats betydligt oftare än det lyckats. Vi borde ju använda det som fungerar bäst istället för det någon annan säger till oss att göra. Jag är inte alls säker på att en certifiering är ett bra sätt att höja statusen på testarna. Mitt råd till alla er är att fundera på : Är det jag gör nu effektivt? Vad kan jag göra för att det ska bli bättre? Är det roligt att följa detaljerade instruktioner eller att jobba mer kreativt? Är det ibland betydligt mer effektivt att testa friare än att bestämma allt i förväg? Hela iden bakom agile är ju att vi inte vet allt från början. Lägger vi alldeles för mycket tid på att producera text då vi istället kunde köra tester eller analysera krav? Utan att ifrågasätta kommer vi inte framåt. Bli en testrebell!
Det pågår en diskussion på Yahoo om den nya versionen av standard IEEE 829. Här ett par inlägg av Cem Kaner: Citat
"My own opinion of the latest revision is strongly negative. I think that 829 has encouraged people, for 24 years, to overdocument their projects and that this problem could and should be mitigated by guidance within the standard on some of the tradeoffs / decisions that might be made if we were willing to consider the project's context.
I am also unaware of any empirical evidence that following this standard does improve quality or project success. For a standard that has been around since 1983, with the number of people who teach it as a best practice, I think the time is well overdue for scientifically sound demonstration of value (to the extent that it exists) that Standard 829 actually provides substantial enough value to  justify adoption as a standard engineering practice."
"What failed to get into the standard is the idea of context. It is important to tailor what you do to the circumstances. A document that is good for one situation is a waste of effort for another and should be substantially modified for a third. What failed to get more than lipservice was the idea that we spend a fortune on test documentation and so we should think carefully about requirements for that documentation, spending the minimum needed to satisfy the needs of the project. Somehow, it seems that software engineering standards should take seriously the idea that it is good to have requirements in mind when you design, budget and execute a significantly expensive task. This document fails utterly to provide guidance for doing the requirements analysis.
We still have a document that pushes the notion that the bigger the bloat in paperwork, the better. We still have a document that claims to present an engineering standard that cannot (or at least does not) reference any scientific studies, after 24 years, that heavyweight test documentation does less harm than good. Or even--not much more harm than good. We have a document that demands more bloat for safety-critical systems (the only context mentioned is that critical systems need to max out on the bloat) but without evidence that max bloat improves rather than detracts from safety.
It is one thing to deal with a standard in place and say, drat, this has done a lot of harm, and is the excuse for a huge zone of braindeadness in testing education, but it's what it is. It is a different thing entirely to say, gosh, this is what we should embrace going forward. Let's use this opportunity to reaffirm the status quo.
In practical terms, we have a document that:
1.     pushes to maximize the income to consulting firms and outsourcers for low-skill clerical work while minimizing the time left for actually assessing the quality of the product.
2.     simplifies the documentation-related judgments in ways that will make teaching easy, mainly because no one will have to do any critical thinking as part of the teaching or the (I hate to call it) learning
If testing is about critical thinking, why shoot ourselves in the head?"
-- Cem Kaner
Â
 Â