Certifications in software testing in Denmark

certificationIs software testing certifications necessary?

These two arguments I hear often:

1) In order to get a job in Denmark within testing. Employers (read: HR) needs to see your certificates otherwise they can be very difficult to convince that you could be their new tester. Not all but most of them.

2) Employers (read: sales and marketing) needs your certification in order to be in compliance with public and sometimes private tenders of projects and services. Otherwise the confidence in your employers skills as a supplier will be questioned and you could loose the race for that big software development contract.

How do you get your certificates in testing?

Taking testing certifications at your own expense is rarely seen in Denmark. It is expensive and can be time consuming (if you have family, job, etc.) so it is in reality not your first option.

So the normal way is to get the certification when you have a job. A testing job. And your employer will then have to support your ambitious dreams about getting a testing certification. This is not always easy.

Many employers will be hesitant about signing you up for a course with an exam due to: costs, time spend on non- billable activities, important tasks or projects etc. [insert further excuses here].
Also the risk of losing money on educating you for your testing job if you later take a new job at another employer.

What happens often is that the employer tries to arrange a “special” tailored in-house course at your company where also the number of days have been reduced to approx. 50 % of the original course. Still with the same curriculum, of course.
Or even worse; the employer will pay for the exam and studying material and then you must use your own time to get ready for the exam.

Now you take the exam and barely pass (who needs those extra points, right?) and on top of that you fell utterly exhausted due to a short period of time with a lot of information to process.
And you get your certificate – hooray!

… then 14 days later you have forgotten most of the things you have studied up to the exam. But that doesn’t matter now you got the certificate!

… and then 90 days after you hardly remember taking the exam or the things you studied presuming you do not use everything you have learned all the time.

Your certificate is like a driver license – you have learned some rules, techniques and guidelines and passed the theory – after that you really need to learn what it is all about in the real world.

Your certificates do not make you an excellent tester – however practice, experience and learning from others on real testing tasks will help you much better than any education you can ever take.

Do you really need a certificate? – well no, in my opinion. I have meet many talented testers without any certifications. But if you want a job in Denmark today within software testing then you do need it. It will make everything easier in your job hunt.

“Something is rotten in the state of Denmark”
– Hamlet (1.4), Marcellus to Horatio

Towards a culture of test performance

I still today meet many people in Denmark in projects and organisations (usually non-tester but also tester) that have very specific ideas about what testing is all about – and yes the words “test cases” do come up in almost every conversation.

I hate the fact that my chosen professional career is regarded as something simple and easy to do and the fact that I have to provide answers for questions like “Why do you need so much time for testing?”, “Is this tool really necessary?”, “Why don’t you just automate the test”, “Why do you need design documentation?”, “How many test cases do you think is needed for this project?”, and so on.

In Testing Trapez issue February 2014 you can find a very important article that I suggest you read if you are a Tester.

TEST CASES ARE NOT TESTING:  TOWARDS A CULTURE OF TEST PERFORMANCE (page 30)
By James Bach, Washington, USA and Aaron Hodder, Wellington, New Zealand

Testing is the evaluation of a product by learning about it through experiment; by seeing it in action. The reason we test is to analyse product risk: the danger that the product will cause trouble for its users or otherwise fail in some way to fulfill its purpose. In other words, we look for anything about the product that might significantly impair its value. We are looking primarily for “bugs.” We want to find every important bug, although there will be no way to know for sure that we have succeeded.

Test of IT infrastructure – the firewall

First draft of my post: So you have to test (or check) a firewall in a new or existing it-infrastructure?

Firewall

 

The beginning

This question is what the test approach should be and this can partly be clarified if you can answer the following questions:

Is it a test of the firewall product? Is so then plan a test as you would for any other software product based on requirements, design, risks, etc. Because basically a firewall is a server running a OS and a application with some management interface. This test approach is out of scope for this post.

Is the firewall a part of a for example an enterprise infrastructure? Is so then plan a test that explores the firewall customization to the it-infrastructure that it is a part of. This test is what is described in the rest of this post.

Now, as a basic assumption for the test approach I assume that the firewall product is reliable and stable is operation. I know “assumptions is the mother of all fuck-ups”, however this is a risk I take at this stage. It will be at the top of my list of risks. Continue reading →

Reviewing user stories

review

Mnemonic: CIRCUS MATTA

Use to determine whether the user story meets ”Definition of Ready”. Remember you have to define Definition of Ready for your team.

Completeness – Does it have all the information it is supposed to? Does it have traceability from previous documentation or discussions?

Independent – Try to keep stories as independent as possible, one customer centric. Dependencies lead to prioritisation and planning problems.

Realisable – Does the requirement make sense and is it possible?

Consistency – The way the specification is formatted, the language used and the way the requirements are presented should be consistent throughout the document.

Unambiguity – Is it free of statements such as ”Conversational speed” and ”timely manner”?

Specific – Has all of the information been included in order to deliver the product and that it does not contain general statements?

Measurable – How are you going to measure if the requirements have actually been delivered and are operational to specification?

Acceptable – Is the use of calculations, language, logic and formulas correct?

Testable – This is also known as Verifiable, if the requirement is not testable it cannot be built.

Traceable – Who wants this requirement, why is it needed and what Business strategy does it support?

Achievable – Is the user story achievable within the iteration, consideration may need to be given to splitting the user story (Epic)?

TestExpo 2016 coming very soon

This years TestExpo 2016 is on thursday the coming week and I look forward to meet some brilliant people and talk about testing.

The program for this event is divided into 3 tracks: Go Digital, Be Agile and Stay secure. Also the TestExpo Hackathon will be held to find the best testing team in Denmark.

As usual I can find things in all 3 tracks that have my interest. So I will have to choose… I will write a post about the event later.

Information about TestExpo 2016

Testværktøjer

“A fool with a tool is still a fool” – Grady Booch

31-super-tool-300-eodVigtigt: Hvis du bruger et værktøj, sørg for at det er det rigtige værktøj til den rigtige opgave, og sørg for at du behersker værktøjet.

Udarbejd en værktøjsstrategi og hav en organisation der er entydigt ansvarlig for testværktøjet. Sørg for at få forankret værktøjet i en driftorganisation og sørg for en værktøjsansvarlig der definerer funktionalitet og stiller krav til driften.

Testværktøjet skal understøtte arbejdet. Der er ingen værktøjer der fungerer optimalt lige ud af boksen. Alle værktøjer skal tilpasses og indpasses.

Det er et faresignal, når man begynder at omgå mangler eller svagheder ved værktøjet. Eksempelvis, hvis man er nødt til at foretage supplerende dataopsamling i et regneark ved siden af eller hvis der skal et andet værktøj i brug for at flytte/udtrække data. Det kan medføre fejl i registreringer af resultater eller ved fortolkning af resultater. Resultaterne kan være mangelfulde. Hvem kender til omgåelserne? Hvem ved hvordan værktøjer nu skal vedligeholdes?

Hvis testværktøjet ikke længere understøtter det der er brug for, så smid værktøjet ud og erstat det med et andet!