Comments on: ISTQB Certification is not a qualification

By: Henrik Emilsson

Henrik Emilsson — Sun, 10 Jan 2010 14:17:07 +0000

@Tony. No problems with the delay!
I hear you on this. The issue with what you propose, as I see it, is that in order get everybody to understand your language you need to be able to explain what words mean. And in order to explain what they mean you have to deal with the fact that there are disputes regarding the meaning of certain terms, methods, etc. I.e. in order to present a [simplified] language you need to decide upon which interpretation that is valid; and then we are back on square one again.
I do not think that simplifying is a solution. Instead we should realize that it is more complex than what could be taught on a two and a half day course.
Of course it would be nice if we could speak a language that everybody understand, but see what happened with Esperanto that was partly developed for the same reason…

By: Tony Bruce

Tony Bruce — Fri, 08 Jan 2010 14:55:45 +0000

@Henrik, Apologies for the delay. What I mean is that there are comments here that talk about standards, language standards, etc. We all know that certain phrases mean different things to different people and organisations which can sometimes cause confusion. However being aware of it should mean that we are clarifying what is meant.
There is however a……….I’ll call it a growing movement to bring in more people who are not testers, not developers but users, BA’s, etc and bring in them as part of the team. Things like agile and BDD and these people who will be working with us will not be aware of the industry ‘confusion’ so perhaps instead of trying to sort out that confusion there should be a move to simplify language used (as BDD does) so that everybody (including non testers and developers) understands.

By: Torbjörn Ryber

Torbjörn Ryber — Sun, 03 Jan 2010 17:59:32 +0000

One of the BIGGEST problem with the certification as of ISTQB is that in order to be able to cover so many subjects in such a short time 2,5 days – matters are so simplified that they become ridiculous.

Look at boundary value testing – it is taught in such a rote manner that people are made to believe that you need to find the obvious simple partitions and then you take the least number and one below etc – which is hardly learning how to test.

State graphs are also taught in such a manner that you always start with a simpe table or a graph and look at what transitions are possible. The hard thing is to create the table or graph and the ones I create are almost always updated continually during test execution.

Having a common vocabulary would be OK if it was a decent – not perfect one – but really bad if it it stops people from learning. It is also different from teaching poeple what is best and second best when it comes to solving certain problems. Take a look at a practice exam question and try to find situations where ANY of the four alternatives are valid – it is not that hard. To say that one answer is better than another is to totally forget the idea of context. I recommend Jery Weinbergs Exploring Requirements for anyone that wants to learn more on meaning and context.

I am certified at ISEB practitioner level since 2004 – that has since been reduced to simple multiple choice questions because to few people passed it. Lack of skill or to hard to grade when thining of context? I have had to de-learn a lot of test theory since then.

By: Henrik Emilsson

Henrik Emilsson — Mon, 21 Dec 2009 17:17:59 +0000

@Tony.
I am not sure I understand what you mean. Could you try to clarify a little bit?

By: Tony Bruce

Tony Bruce — Mon, 21 Dec 2009 14:10:40 +0000

There’s an aspect that hasn’t been mentioned yet, and that is that growing attempt at collabrative team environments in which case, we want to be using language everybody understands.
Our we going to try make everybody speak our language or speak in a language everybody understands?

By: Saam

Saam — Sat, 19 Dec 2009 21:53:35 +0000

I agree with you Martin. And, as you say, the resistance to change is maybe not the problem. However, change on a higher level still needs the approval and enabling by management (money and prioritization power) and for a decision to be made people often want “some kind of insurance” it will work.

By: Martin Jansson

Martin Jansson — Sat, 19 Dec 2009 20:30:35 +0000

@Saam,
I find it strange that it is so common that test experts within an organisation must point to industry standards, IEEE, ISO, CMMi and consultants in order to get the attention. I often wave Cem Kaner (as professor) in peoples eyes to get the attention, but it is usually a last resort. I recommend that you get the consultants behind you, to support what you want so that it is clear that it is you that have the driving seat.

I think resistance to change is overrated. If you work by example before writing the process or document there is a bigger chance you will succeed, as I see it. This will win those who will be affected by the new way of working. Still, documenting how you do work in order to make it easier for everyone to understand is best in the end.

By: Saam

Saam — Sat, 19 Dec 2009 20:04:41 +0000

Thank you for thorough feedback to my comments! Yes, as I see it, even if it is hard to change the environment I thing the long-term-vision should always include that, at least as an option to explore. But first of all one needs to adopt to the current environment. I agree with you regarding the ways to go about getting commitment and the need to point to an “industry standard” is limited. However, sometimes you tend to get peoples attention when you include references to e.g. IEEE, ISO, or e.g. CMMI or other similar entities (that the reciever of your message knows and respects) as they percieve it as there is a certian level of “confirmed” professionalism and weight behind your words. Thats my experience.

By: Henrik Emilsson

Henrik Emilsson — Sat, 19 Dec 2009 00:41:08 +0000

OK, I think I see what you mean.

–
Changing the environment is sometimes a hard thing to do, and it is sometimes even impossible. But it is not completely impossible!
In order to prove that your new approach is a more efficient way I think that you need to investigate what kind of service you should provide as a tester in your project. One start is to investigate what kind of information the stakeholders are interested in, and come up with ways to address that mission. If you then find a more efficient way to elicit that information other than what you do today, you now have an incentive and a motivation to do it. If you are patience and start in a small scale, you might reach far after a while.
Another thing to do is to question the company requirements and ask why and if parts of “what we get” are really needed. This way it might become obvious for the executives that the current way is not the preferred way. But be prepared to fight some battles… When you question those type of requirements in a company that has a long history, you are attacking the company culture; you need to be aware of that people might have built their careers on this culture and others have been hired and adopted to roles that they hardly want to get rid of.
–
As you mention it is really important to get people committed, but I have rarely seen that work by first implementing an approach and then try to convince and persuade about the efficiency. Simply because of politics and the fact that people have a hard time admitting that they are wrong (me included)… Instead, my experience is that you need to get a commitment on the mission first, then design an approach that meets that mission. This way you act in the spirit of the executives since they have been with you all the way.
–
If you still want to point to an “industry standard”, you need instead to point to a practice that has been good or promising in a similar environment and context as yours. To me it looks like it would be impossible to describe an “industry standard” that would be suitable for the full range of contexts that our “industry” covers (if we even could say that we are an industry!?). To illustrate what I mean I could mention a few very different products that would be hard to develop using the same test approach (or a standard approach): pace-maker, web site, open source plugin to WordPress, financial/banking system, airplane, Microsoft Word, web browser, compiler, cell phone, booking system. And have in mind that the context might differ between companies/organizations that develop the same type of products listed above.

By: Saam

Saam — Fri, 18 Dec 2009 21:41:03 +0000

Firstly, no problem, I love the links, keep them coming! Ok, I’ll try to explain how I see this. One can either adopt to the environment or try to change the environment. Or both. As I interpret “Ultimately, context-driven testing is about doing the best we can with what we get” it is about adopting to the environment, please correct me if I am wrong. I think this is the best starting point, one needs to adopt. However, if you work in the same type of environment for a longer period (same type of product, projects, people) you might start to question certain things. Why do we get “what we get”? We might see a possibility of incresed effeciency if we would be able to apply a different type of approach but it would not be effecient in our current context. Lets say this is due to some corporate requirement or due to the lack of a certain type of information. If we could achieve a change in our environment that would enable that type of information or discard that requirement then we could switch our approach and hopefully become more efficient. I consider this as changing our environment rather than adopting to it, and in order to achieve this change we must get people commited. To do this we can show them our anticipated increase in effeciency. But to fully win them over we might need to also show them that the approach we want to enable is a proven concept as it is considered industry standard. (Even if it is not proven in our context or the slightly modified context we want to create.) I am not sure it became more clear?? And also, it is probably not a very good reason for creating a standard…