Jan Jaap Cannegieter
09 Feb

Why every tester should have an IREB certificate

09 February 2012 by Jan Jaap Cannegieter

Our world is changing all the time. When I had my first job interview as a tester I just had to answer three questions with 'yes' to get the job (I see in your CV you did a course on testing, it that so? And you want to be a tester on our project? Are you serious about this?). By now we don't get away with a three day testing course. We need to have at least one certificate on testing, we need to have knowledge of software development, we need to have good personal skills and preferably we need to have knowledge of the business processes of the organization where we work. And still clients are asking for more and more knowledge and skills. When we work in agile teams we need to have collaboration skills. As test managers we need to have managerial skills. As test consultants we need to have persuasiveness and political skills. So we need to work on our soft skills. But what about our hard skills? As Erik van Veenendaal stated in Testing Experience 04/11 we need to specialize (e.g. security testing, performance testing, chain testing) to broaden. But how can we broaden? In which direction should we broaden?

In my personal opinion we should broaden our knowledge and work field in the direction of requirements engineering. For a couple of years now I have the vision that requirements engineering and testing can be combined in one person, since a year or two different testers showed in practice combining requirements engineering and testing is very well possible and has a lot of benefits. In practice we have shown that combining requirements engineering and testing lowers the need for communication and coordination, saves time and money and makes sure testers are involved early in the project. And it can very well be a possible future for testing. This way the testing phase is death (Gojko Adzic, Eurostar 2011) and we don't have to call ourselves testers anymore (James Whittaker, Eurostar 2011).

But what has IREB got to do with this? Well, it's the biggest and best known requirements engineering certificate. Having your IREB certificate is surely a precondition for making the step from tester to requirements & testing engineer. And even when you don't become a requirements & testing engineer you learn a lot about ICT-project by doing an IREB foundation course. Another vision I have is that we talk and learn too much about testing. By now we know enough about testing techniques, test strategies, test approaches, test methods et cetera. I think we should not deepen our test knowledge but we should broaden our knowledge.

Some last words on the criticism concerning certification. Of course, ten years experience is worth more than a foundation certificate. And of course, just having your foundation certificate doesn't make you a good requirements engineer. But having a certificate surely shows that you have the basic knowledge and people who don't are not interested in the subject won't invest the time and money in the certification. So it proves at least something.

I hope not every tutorial and every presentation on Eurostar 2012 is about testing.




13 comment(s) for “Why every tester should have an IREB certificate”

  1. Gravatar of Ola Hyltén
    Ola Hyltén Says:
    I'm sorry but I deeply recent your statement that those who don't have, or don't get, an IREB foundation certificate don't care about the subject and are not interested in it!
    I have never heard such a preposterous thing in my life and it sounds like you're selling this, and perhaps making some money doing that. I have no intention in getting this certification and if you can prove that this means that I have no interest in the field of requirements then you know more about me than I do myself. I seriously doubt that!
    I have a lot of experience from a number of different fields, in testing and software development and in many other walks of life, and my interests are broad. I don't need a certificate to prove to anyone that I have knowledge and skills since most certificates don't say anything about actual skills or knowledge beyond being able to learn what check boxes are supposed to be checked to pass a particular certification test.
    The IREB test is multiple choice so it all about giving the expected answer and not about thinking for yourself and using your own words. I also read about IREB and the, at least to me, strange idea about "a single, universally accepted, qualification scheme". To me that translates to "You do as we say and we all come out making a good deal of money". It's obvious that there are people in this world that believe in silver bullets and easy solutions to complex problems.
    In my experience I have never come across a silver bullet. I seriously doubt that that what you are proposing is one.

    The thought of broadening our knowledge as testers, and skills I presume, is a good one. There is a lot to be learned from a wide variety of fields that can be useful for testers. Psychology, sociology, scientific theory, music, art and more. Only imagination will set the limits for learning. Learning and developing our skills, both broadening and deepening them, is needed if we are to become better testers and the drive to do that for me is simply that I am passionate about what I do and believe that if I can learn more I will be a better tester and have even more fun testing. It will help me get cool jobs in cool projects and I can hopefully also spread some of my experience and knowledge to others and help them get better.
    The difference between me and IREB is that I don't say that what I do and say is gospel and "universally accepted" but I welcome discussion and debate. I also don't charge a bunch of money, I regard it part of my job in any project I'm on. Should I organize a course I would need to charge some money to cover whatever I'm losing from my pay-check. I like making money. It helps keep the house warm and my children fed :)
  2. Gravatar of Ajay Balamurugadas
    Ajay Balamurugadas Says:
    >> But having a certificate surely shows that you have the basic knowledge and people who don't are not interested in the subject won't invest the time and money in the certification. So it proves at least something.

    What do you want to prove? Having a certification shows that you are interested in the subject? Those who don't are not interested? How can you generalize?

    I agree with your one sentence:
    >> I think we should not deepen our test knowledge but we should broaden our knowledge.
    To add to it, I will add the words 'and use them in testing' after your sentence.

  3. Gravatar of Petteri Lyytinen
    Petteri Lyytinen Says:
    I can only be interested in the field of testing if I possess a dodgy certification that I can get by passing a multiple choice exam which requires memorizing but not understanding? Are you serious? Really?

    I /utterly, completely, and absolutely/ disagree with that claim and making it could be taken as an insult belittling and trivializing the professionalism and expertise of every critically thinking tester in this world. Even the new ones who are just now taking their first steps into the world of software testing.

    Context awareness rules and case-by-case evaluation of the situation at hand sounds far better (to me) than resorting to some vague standard that, necessarily, has zero knowledge of my context. Unique problems require unique answers, not one-size-fits-all solutions.

    In the world of software development there are no conveyor-belt factories where repeatability and uniformity are desired qualities since the goal is to create an identical product every time. Software development just isn't like that. Each end result is unique so conveyor-belt factory rules do not - can not - apply.

    Yes, there are likely certain similarities in each project but IREB is not an answer there any more than ISTQB is, for exactly the same reasons.

    I would recommend reading, for example, Michael Bolton's EuroSTAR presentation "Why I Am Not (Yet) Certified" from 2007: http://www.developsense.com/presentations/notyetcertified.pdf

    I do agree on that testers would likely benefit from broadening their knowledge and skills but, above all, a tester is supposed to be testing so I would not ignore the importance of also honing and deepening your testing knowldge and skills.
  4. Gravatar of Rahul Gupta
    Rahul Gupta Says:
    Please stop misguiding people Mr Cannegieter. Having Certifications like ISEB or IREB doesn't mean that one has basic knowledge (because knowledge is more than knowing some definitions from some Standard Body of Knowledge). I see it as a money spinning mill/strategy of some people (like you?). Do you think the basic knowledge required for testing a website for a bank is same as the basic knowledge required to test an embedded system?
    Your post is misleading for starters in Software Testing field. Think about it and probably in your upcoming posts, we can appreciate your changed thinking.
  5. Gravatar of Oliver Vilson
    Oliver Vilson Says:
    In this matter I agree with Ola. I know wikipedia isn't much of an reference point, but "As of October 2011, there were over 6,000 IREB Certified Professionals for Requirements Engineering worldwide" so I can't agree it is well-known around the world.

    I would also like to state that since whole software project development has changed alot, we are not talking nearly enough about various aspects in testing. Some major changes I've seen in last few years that affect testing:
    - More and more web-based software should be compatible with tablets and smartphones as requirements. That pushes the expectations for testers performance to be capable of testing both on computer browsers and in tablets and smartphones.
    - Development moves closer to business. Due to agile development methods are becoming more popular then demands for more rapid testing is also needed. I've actually seen companies giving up (in full or partially) Scrum or Agile approach, because testing couldn't keep up and thus the quality of out-going software dropped.
    - Huge growth in integrated/embedded software development (like software that runs your house heating system). Since that kind of development is moving out of niche and more into so-called "mainstream", it leads to various problems in testing since it combined with agile development requires much-much more from testing in aspects of risk-aware effective testing. There even has been full evacuation of large office building due to software error in ventilation system. Lost of money isn't relevant? How about when your own houses heating system shuts down in the middle of the night during -30C and your wife is home alone with 6 months old baby? Something similar actually happened to friend of mine.

    All which in turn means that what we knew 5-10-15 years ago is moving to "not as useful anymore" category. Who still test web application assuming the statistically only browser in use is IE (like it was in 2002/2003)?

    Even though I agree that it is good if testers know more about development side, but I actually see greater lack with (even) decent communication skills. Lack of testers who can explain, present, show and advocate what they have tested. What's the use of all that knowledge and skill if you can't tell me what you have done and how?

    "But having a certificate surely shows that you have the basic knowledge" - I've talked with some QA Managers about ISTQB cert. They tend to say: "it helps to make sure everyone have basic knowledge and same syllaby of testing". Pushing the topic deeper then even Managers have realized that nothing has actually gone better. Different testers still have caps in their knowledge base, but because they have the cert, they don't tend to critically evaluate their knowledge ("because some certificate says you know it"). And only thing a cert shows is that you studied materials of specific certificate for the time of exam to pass it.

    Also in more personal note I agree partially about what you are saying, but I consider it low ethics to promote just one specific certificate by saying "this is a must because it is most well-known".
  6. Gravatar of Jan Jaap Cannegieter
    Jan Jaap Cannegieter Says:
    Wow, I started a discussion here! I like discussion so I'm happy with that but before I react on some comments I want to make two things clear. First, I don't make any money when you do an IREB or any other exam, I'm not trying to sell anything. My employer can earn some money when we deliver a requirements course, but I don’t get any of that. Second someone said he felt insulted. I don't want to insult anyone, if I did I apologize. But the problem is I really think getting your IREB exam can help a lot of testers further.
    In some of the reactions people say they don't have to prove anything to themselves. I surely believe that it proves something for yourself, but that’s not what I'm saying. You prove something to the rest of the world, for instance to possible clients or employers. In The Netherlands most of the organizations that hire testers see a TMAP or ISTQB certificate as a must-have. When you consider yourself a professional tester you should have your certificate(s) is the thought of most clients. And I agree.
    This is a story about test certificates. In most of the comments I read that there is an agreement that we should broaden our knowledge. More and more projects use agile methods which means multi functional teams which means we have to be prepared to do other work than testing. With an IREB certificate you show to the rest of the world you take the broadening of your knowledge seriously.
    Someone said it doesn't say anything about experience and knowledge. I agree that it doesn't say anything about experience, but it surely says something about knowledge. I've seen so much communication problems (is that good english) due to the fact that someone used term and someone else explained it differently. So yes, a universally excepted set of terminology and techniques helps in ICT-projects. And we can wait till everybody learns our terminology but I think we should learn the terminology and techniques of other disciplines in ICT-projects.
    Then about the examination thing. Based on the work of Sousa (learning pyramid about didactics) is doing an exam much better compared to a lecture or reading. I would welcome a good discussion about this would take to much text. And yes, I know Michael Bolton’s presentation, I was there. I admire Michael very much and agree with 90% of what he says. But since 2007 the number of certified testers exploded, by now there are 10.000 persons certified by IREB and the number is growing by 250 per mounth (read on a LinkedIn discussion group). Are they all crazy? I don’t think so, but I agree with you that a certificates says everything.
    I’m working at a contracting an consultancy firm with requirements analysts, QA officers, testers and process improvement consultants. And the requirements analysts have (beside their IREB certificate) a test certificate on foundation level and it makes them better requirements analist. And our testers have (beside their test certificate(s)) an IREB certificate and it makes them better testers, especially testers in agile teams.
    By the way, I agree totally with Petteri Lyytinen that we should we context driven and agree with him that testing knowledge and experience is most important. And I agree with Oliver Vilson that in some cases a focus on communication skills can be more relevant.
    Did the responses change my opinion not at all? I’m still convinced that we should broaden our knowledge, based on the didactical argument (Sousa) and the use of one set of terminology I think certification is the best way to do that. But you convinced me that there can be exceptions, based on experience for some a certificate has no value. So may I reformulate the title in: The relevance of requirements certification of testers? And this is surely no misleading call. I’ve seen testers improve their performance this way.
  7. Gravatar of Oliver Vilson
    Oliver Vilson Says:
    to Jan Jaap Cannegieter:
    As far as I see you made one small mistake - you generalized the situation in Netherlands to everywhere. I don't know the reason why Netherland companies see ISTQB or TMap as "must-have" for testers, but none-the-less it creates you a context from what you oriented while making the arguement. Almost similar problem of context as one my colleagues brought out in "The Context Problem" http://www.testerstower.com/?p=154 in which he talks about Alberto Savoia's "Test is Dead" presentation after discussing it with several local testers.

    "When you consider yourself a professional tester you should have your certificate(s) is the thought of most clients. And I agree." - I have to disagree loudly. Most of my customers think of me as professional because of what I've done and what I've said. They follow references of my work instead of some paper that says that I'm qualified to talk and act. Even various academic universities want me to come, talk and teach about various aspects of testing even though I haven't graduated yet. So would you say I haven't proven myself as serious testing professional? Because I don't have a certificate? I know at least several dozen people who would disagree with you... And I'm not the only one...

    About broadening our knowledge - I have quite an experience in both System and Business analysis even though I don't have IREB certificate. I did Business and System analysis (and later participated in successful implementation) of a third-party software integration that was considered impossible by Lead Analyst of Business Unit. After that project I was considered as back-up analyst for Lead Analyst (and he was one of the best I've ever worked with) and was almost always consulted in the future during analysis phase of any product. I did it without any certification or formal training. I was capable of doing it at that time because I understood the product and the problem due to my background as tester. Now I've actually evolved and learned some new tricks how to be even better whenever I have to write analysis.

    Cross-functional teams - It's nice little buzz-word (for me at least) since I haven't seen such thing as highly effective cross-functional team where everyone are capable of doing everything to the highest possible effectiveness. It's great when testers understand project management (it helps them to consider risks involved and increase efficiency in testing), analysis (it helps them to understand the problem better and increase testability in sense of business logic) and programming (it helps to understand the language specific problems and increase testability through being able to make suggestion how to implement something). Same goes to Analysts, Programmers and Project Managers. Cross-functionality doesn't mean you have to be able to do everything everyone else are doing. For me it means that you understand enough to be more efficent in your area of expertise. It's meant to reduce communication issues through reducing "language barriers". It doesn't come from certification. It comes from constant learning and communication with other team members. To study what they are doing, why and how. As far as terminology - What would you do if someone asks you: "What do you think about our new unicorns? Should we implement them as pink or as white?". Main issues about differences in definitions comes from false-shame of fear about looking stupid when you want to clarify some term or phrase or definition. Also according to my experience it's nearly impossible to get "universally accepted terminology" since there is always some edge or corner-case that you have either forgotton or never learned (and thus haven't acquired it fully) or someone is using approach you haven't encountered before (especially when language used isn't your native language). Anyone who has taken few sessions with James Bach have probably bounced into that issue.

    About examination - As someone wise once said (have to find the quote) "It's not about the destination, it's about the journey that'll take you there". If people do the examinations because their jobs depend of it... Then it tends to be more about the destination (to get the paper of proof not to loose their job) instead of the journey to learn new things. I've seen it more than once. The number of certified testers have exploded because someone told the testers (or at least left that kind of impression) that they would be out of job if they wouldn't do the certification and/or also said to employers: "we promise that people who have this paper are fully qualified to do the job". For example - weren't there NO testers at all in Netherlands before ISTQB and TMap showed up? If there were, then how was it possible? How were they evaluated and hired without any certificates?

    About didactical arguments of teaching - the multiple choice question tests are currently considered as one of the worst possible cases of evaluating if someone is capable of doing something tanglible. It is used to determine if someone has acquired that very specific knowledge for that specific time he or she takes the exam. Not to determine if they can actually use that knowledge. Huge difference. Would you be willing to trust a surgeon who has only taken multiple choice test in brain surgery to remove a tumor from your brain? Or taxi-driver who is driving you through the city? Why are we then assuming that multiple-choice tests are suitable for determining level of competence of people involved in ICT development? Someones life may depend of that one person who tested software for medical device keeping you alive after serious surgery or software used in your self-phone to call 112 (911 in US) to access other networks or tested electronical brakes (or accelerator) for your car.

    The relevance of using specific knowledge is highly context-specific. It might be relevant AND/OR useful or it might be not only useless, but also destructive for some contexts.
  8. Gravatar of Edward van Deursen
    Edward van Deursen Says:
    What a nice discussion! I think that everyone is right and wrong. The job title ‘Tester’ and the role ‘tester’ are mixed up in the discussion. The most of you are right about the IREB certificate, it isn’t useful when you are 100% in the role of a tester. I think that Jan Jaap is talking about the job title ‘Tester’. And then I agree with Jan Jaap.

    First of all: I have been a tester and I wasn’t that good as you all are. Reason: I have been a programmer and a designer for more than 14 years before I became a tester. And it was hampering me to get an expert as the role ‘Tester’. Nevertheless I was quite successful as a tester because of the knowledge and experiences of designing and programming. It helped me to be a picky person, a pain in the ass for the designers and programmers I worked with. My goal was not to find defects in the software but to prevent them to occur.

    Now I am a Quality Manager and have the responsibility of a chain of systems. My test team consists of several persons with the job title ‘Tester’. And what do they do the most of their time?
    Reviewing documents from Business Request till test cases, witnessing System Test, Model Based Tests of Use Cases, and so on. I think that more than 50% of their effort is on ‘testing’ documents. 30% looking what System Test teams already did. Test execution (most regression) of software about 20%.
    Chain testing is the last defense before we go live. And as everyone knows: always on the critical path. And to be sure that we don’t find a defect during the chain test we review, review and review all documents, including the requirements. Especially the requirements. It will save the most, in time and money. I think that everyone involved in QA knows Boehm.

    Who can tell me the use of testing 100% a requirement that doesn’t fulfill the need of the customer?
    Let me explain it the following way: A surgeon can execute the operation successfully, but is it successful when the patient passed away? Wasn’t the goal that the patient stayed alive and recovered?
    It depends on the goal of the surgeon: to exercise the steps of an operation or to keep the person alive. And what was the goal of the patient? To help the surgeon? Could be.

    What do you do when you get a design that will do functional what is needed, but will not be secure or will have bad performance? Do you start making your test design and test preparation or start you asking questions about the bad design?
    A test can be perfect without reaching the original goal: give the customer what he need. And most of the time it is something else than what he is asking for…
    If the person with the job title ‘Tester’ understands the requirements process and can ask the right questions to the requirements analyst, a foundation certificate in requirements will certain help to ask him the right questions. Aren’t requirements the start of our test base? What if the requirement is wrong, the derived documents will be wrong as well. Of course can we point at the requirements analyst that he did a lousy job. But will it help to make the project to a success? Aren’t we all responsible for the result in an agile project?
    And your tests? Spending all those hours on making your tests to prove that the software is exactly doing as designed: Useless as well!
    Think about that!

    My team consists of testers with several roles and they change from role to role several times a day. Tester, peer review designer, performance expert, business consultant, functional and technical maintenance, programmer, DBA and more and more: requirements analyst. And for all those roles a common understanding of these expertise is welcome. Certificates of ITIL, BiSL, ASL, TMap, ISTQB, IREB and so on are valuable for me when I hire a person with the job title ‘Tester’. He or she is responsible for all the quality within the project, from the start till the moment of delivery. And when you see that agile is (becoming) the standard, a tester need to transform.
    And sometimes? Sometimes I need an expert in testing, most of the time a Transformer…

    My testers transform several times a day. Isn’t it exciting?
    What a nice job/role we testers have!
  9. Gravatar of Oliver Vilson
    Oliver Vilson Says:
    from Jerry Weinberg:
    Question : "If a dog has four legs and you call its tail a leg, how many legs does the dog have? "
    Answer : "Four, of course. Calling a tail a leg doesn't magically make it a leg. "
    Same thing has been covered by Fiona Charles in this article http://www.stickyminds.com/pop_print.asp?ObjectId=14305&ObjectType=COL
    Same way calling tester "Analyst" doesn't magically transform him/her from Tester to Analyst. The skill of reviewing and questioning doesn't come from acquiring certificate. It comes from practice and skill of critical thinking and analysis.

    Again there is difference of definitions what testers are supposed to do. Difference of testing schools. I see testing as means to provide information about the software to make more informed decisions. You define testing as a way to prevent bugs and issues. But it's not always necessary to prevent every possible bug. The decision to fix/no-fix specific bug should come from business-side since after all it's business decision how much time/money is spent for solving that specific issue.

    If your documents reviews/testing has been so good that you won't find any bugs during prerelease testing, then from my experience the testing is flawed. Because in that case you would have something called totally bug-free software.

    Doing 100% coverage for requirements - it's simply not possible. You can't cover every possible scenario for every specific requirement. For example is presence of electricity in requirements? Usually not. But what happens to the solution if there is a power loss? For example - client-server software, suddenly server goes to back-up power from generators. Would it be shown out for client side or not? If not what would happen if generators run out of gas? Does the software just crash? If server comes up after power returns, does the software come up on it's own and allow user to continue where he/she was left off? These requirements are rarely described in any documentation, but it's important to know their relevance to customers during testing. These small details affect how to test and what to test. There are usually more questions than there are requirements, so how can any tester do any level of test design or test planning and be certain of their activities without questioning. If interested, contact me and I could send you an exercise I've used to train testers. If you actually succeed covering 100% requirements and make the software match for needs, then you have done by far better than everyone else who have ever done this exercise. Including creators of it. The issue comes from the aspect that all models are wrong (though some are useful). Every specification, story, note or picture is just representation of model and thus is fallible by itself.

    Also how do you know from reviewing the model if the model represents exactly what customer wants? You can challenge the model and find controverses or unmentioned aspects of requirements, but these aren't telling you what customer actually wants. It only models customers needs and thus is insufficient.
  10. Gravatar of Ola Hyltén
    Ola Hyltén Says:
    I have read all that followed since my first comment and I still stand by every word I wrote.
    I don't fell I need to comment any more on the rest of the discussion I just want to point out that I agree with Oliver Vilson on all he wrote.
  11. Gravatar of Fiona Charles
    Fiona Charles Says:
    It's always useful to acquire new skills and broaden one's knowledge, and I agree that acquiring requirements expertise is a useful thing for a tester. But you say:

    "By now we know enough about testing techniques, test strategies, test approaches, test methods et cetera. I think we should not deepen our test knowledge but we should broaden our knowledge."

    I disagree utterly with this. The practitioner of a genuine craft can never know "enough" about that craft. (And what do you mean by "enough"? Enough for what?) A true craftsperson will always seek to grow his/her skills with deepening craft knowledge and understanding. That's how a craft advances. And there will always be advances to keep up with.

    Broadening your knowledge across specialties does not preclude deepening your skills and knowledge in your own specialty -- nor should it, if you want to be really good at what you do.

  12. Gravatar of Richard Brown
    Richard Brown Says:
    Simplilearn is providing an excellent opportunity for you to become a ASTQB(American Software Training Qualification Board) Certified Tester where you can learn the Fundamental of Software Testing,Testing through the Software Life Cycle, Static Techniques, Test Design Techniques, Test Management & Tools Support for testing just by attending a 3 day classroom workshop .

    Please call us on 281-816-4724 to avail great discounts on the workshop

    Accredited by ASTQB to conduct the training and an authorized exam center.
    98.7% of participants clear the ASTQB exam on the first attempt when attending the training with Simplilearn since we provide 2 complimentary test for practice. You can write the exam for free at no extra cost.
    We offer you 60 hours of PMI PDU certificate upon successful completion of workshop and exam.
    We provide a 30 day complimentary access for any one course with 6 different domains to choose from such as Project Management, IT Service Management, IT Security Management, Quality Management, Technology Certification, Finance Management.
    We provide 90 Days E-Learing Access of the course.

    Email Address : richard.brown@simplilearn.com
    Call us on : 281-816-4724
  13. Gravatar of Radu
    Radu Says:
    In my opinion, I agree with Jan Jaap Cannegieter and I have recently got the IREB certification. A certification in every domain proves that someone is really interested in that area. About the relation between testing and requirements engineering, we have to admit that after few years of experience, each tester is quite familiar with the entire testing process from planning to execution and he has got a critical eye regarding the application. But requirements engineering means something a bit different, namely understanding the requirements from the conception phase. In this way, one could prevent some issues to arise later. For those who think that getting a certificate is waste of time, I have a counter argument. Before studying in detail about requirements engineering, I belived that this activity means only to clarify the requirements with the customer, but afterwards I gained some knowledge about all phases involved in the requirements engineering process. Furthermore, the IREB certification exam doesn't comprise many definitions or things like these, so it's a wrong assumption to believe that we have to memorise a lot for this exam. There are a lot of questions related to different contexts. In conclusion, I think that this certificate could be usefull for testers, since it broadens the area of expertise and furthermore is a proof of interest in a certain area, quite closed to the testing domain.

Leave comment: