Pages

Thursday, May 30, 2013

Markus Gaertner has been a software tester since 2006 and is located in Germany. Personally committed to Agile methods, he believes in continuous improvement in software testing through skills. Occasionally he presents on Agile and testing related conferences. He is a black-belt tester and instructor in the Miagi-Do school of software testing, and a co-founder of the European chapter of Weekend Testing.

Tuesday, May 28, 2013

Software Testing - The Hidden Profession

After working at Assurity for a few months, I decided to catch up with some friends in Auckland. Given that most of my friends have left uni in the past few years; it’s safe to say that our lifestyles have changed; and a major topic that would arise would be what we’re doing with ourselves these days. That is, what exactly are we doing 40 hours a week?

The other person would start it off and go into how they’re enjoying their job as a lawyer/accountant/marketing co-ordinator. I’d ask about what their typical day is like; do they miss uni (and everything that came with it such as lectures and exams); do I know anyone who works at their company; and so on and so forth.

And then it would be my turn.

I’d say I’m working as a Test Analyst with Assurity Consulting Ltd.

I would then be faced with a blank look.

“So do you write code?”

No, not exactly. But some people in Testing do need that skill. I suppose you could say we want to verify the quality of software before it goes live and plan how to break it.

I’ve had many conversations go along these lines and I’ve come to the conclusion that a lot of people not only don’t know what exactly a Test Analyst does- but the fact that they exist.

Well I suppose that shouldn’t surprise me, given that I, for one, honestly thought that software development went a little like this (before I discovered the world of Software Testing):

Project Managers and Business Analysts tell the developers what they want the system to do

e.g. I want a search website that finds what I want, is not case sensitive and comes up with a maximum of 10 search results per page.

Developers write code for this

It goes live

Oh and I suppose the developers and/or Project Managers & Business Analysts would try out the system to see how it was.

It didn’t occur to me that there are people whose profession is dedicated to ensuring software quality is present.

It didn’t occur to me that this role could branch out to many more roles such as a test engineer, test manager, integration specialist, automation...

It didn’t occur to me that this role is in high demand in NZ

Little did I know.

Now that the world’s reliance on technology is increasing, it makes sense that careers surrounding these changes are plentiful. Don’t get me wrong. I’m not in any way saying that it is easy to get a job as a Test Analyst. But I think I could say that the market is promising.

But you know what really irks me?

The fact that some people think that anyone can be a Test Analyst.

I’m pretty sure there are people out there who think they can just haul someone in front of a computer, tell them to ‘test’ it, and then go-live based on that person’s findings (who, in fact, has another day job).

Now maybe, this is suitable for a really small company where it doesn’t make sense to have someone devoted solely to software testing because everyone at that company has a range of roles in the organisation.

Or maybe it’s a start-up and no financial resources can be allocated to do software testing.

Both of the above scenarios are realistic, and dare I say justifiable.

But if you want to make sure that the system is performing the way it should be- then you know who to call.

Maybe it’s the fact that many people aren’t aware of how IT projects actually operate.

Maybe it’s the fact that people don’t see the point in hiring someone dedicated to ensuring software quality.

But let’s face it- Testing is the Hidden Profession.

So now what are we going to do about it?

My intention in this blog is not to raise awareness among those who already understand the benefits of testing. But I do want people to raise awareness around this profession.

Wednesday, May 22, 2013

What is the
difference between Path Coverage and Branch Coverage? (ISTQB)

To explain this I’m
going to do 2 things.

First I’m going to
use an analogy to try and make this situation more ‘real-world’.

Second I’m going to
draw a diagram and elaborate from there.

So let’s use the example of walking from ‘Hunting and
Fishing Westgate’ (Point A) to the traffic light on the yellow road on the top
of the screen (Point B).

To achieve Path coverage you need to explore every
possible route that you could take to get from ‘Hunting and Fishing Westgate’
to ‘Traffic Light on the Yellow road’.

Here’s what you could do:

From
H&F Westgate you could turn left then left again onto Fernhill Drive
and walk straight until you reach the Traffic light.

You
could turn right then right again onto Pinot Lane then turn onto Cellar Crescent
then turn right onto the yellow road, keep going straight until you reach
the traffic light.

You
could turn right then right again onto Pinot Lane then turn right until
you reach the end of the road (at Fernhill Drive) then turn left and keep
walking until you reach the traffic light.

And so on and so forth.

My point is, for Path coverage your goal is to take as many
different possible routes from Hunting and Fishing Westgate to the Traffic
Light

To achieve Branch Coverage, you want to make sure you
walk along each road at least once when you walk from Hunting and Fishing
Westgate to the traffic light.

There are 4 routes from Points A to B to ensure 100% branch
coverage.

On
Monday you could turn left then left again onto Fernhill Drive and walk straight
until you reach the Traffic light

On
Tuesday you could turn right then right again onto Pinot Lane then turn
right until you reach the end of the road (at Fernhill Drive) then turn
left and keep walking until you reach the traffic light.

On
Wednesday you could turn right then right again onto Pinot Lane then turn onto Cellar Crescent
then turn right onto the yellow road, keep going straight until you reach
the traffic light.

And
on Thursday you could turn right then right again onto Pinot Lane then turn right until you
reach Asti Lane,
turn left onto Asti Lane
then turn right once you reach the yellow road and keep walking til you
reach the traffic light.

Now using 2 pictures
I just drew using Paint, I’m going to attempt to explain the difference between
Branch and Path Coverage.

Here’s my first diagram which shows 100% Branch coverage,
note that each branch has a colourful line drawn over it at least once.

Now here’s my second diagram which shows 100% Path coverage.

Note that in the first Paint picture, my aim was to make sure that each branch (black line) had a colourful line drawn over it at least once. I.e. each branch had to be covered at least once -->achieving 100% Branch Coverage.

In the second Paint picture, my aim was to explore as many different possible routes to get from the green box at the top to a yellow circle at the bottom.

The second picture is the same as the first picture with the addition of 4 orange lines.

So how did you find this post? Let me know if it helps you tell the difference between Branch Coverage and Path Coverage.Do you prefer my analogy explanation or the pictures I created using Paint?

Tuesday, May 21, 2013

How to do well in the ISTQB Foundation Exam

So here you are, about to sit the ISTQB Foundation Exam.

Maybe you want to enter the world of Software Testing and want to get a related qualification on your CV/resume. Maybe you're already working as a Test Analyst and now your company has a new initiative where everyone needs to sit this exam.

Either way, I hope some of the tips below can help.

But first, I'd like to thank ISTQB for this picture. This is a visual summary of what to expect in the ISTQB Foundation Exam.

Time and Format of the Exam

There are 40 multiple choice questions.

You have 1 hour to answer all of the questions.

Bear in mind that a fair number of the questions are tricky so you definitely want to leave time at the end (10-20min) to go over answers and make sure that you didn't accidentally pick the wrong answer because you didn't read it correctly.

Testing Techniques, Tools and Dynamic & Static Testing

With regards to Testing Techniques, as you learn them- think about how you can apply them to the real world.

For Dynamic and Static Testing- not only should you learn the definitions but what it actually involves. i.e.

Static Testing is Testing without execution e.g. going over documentation to make sure there are no defects.

Dynamic Testing is Testing WITH execution e.g. once you have a Test Environment, playing with the system to see how it's going

For tools, learn the different types, how an organisation would go about introducing it into an organisation and potential benefits and risks of testing tools.

The Fundamental Test Process

Learn the order in which the 5 key areas take place and learn the activities performed in each area

Test Planning and Control

Test Analysis and Design

Test Implementation and Execution

Evaluating exit criteria and reporting

Test Closure Activities

Extra tips that don't necessarily apply only to this exam

Read the question carefully

When I was studying for this exam doing mock/past exams, it never ceased to amaze me how many questions I got wrong because I thought I knew the answer before I finished reading the question- and I ended up picking answers prematurely

Don't get stuck on a question

If you get stuck on a question, highlight or circle it then move on. There are 2 reasons for this:

1. You can let your brain 'process' the question so that when you come back to it later you're more likely to know the answer

2. You won't risk not having enough time to answer questions you knew the answer to because you got stuck on one single question

When you first learn something, revise it within 24 hours so that it really sinks in

Someone taught me this tip in first year uni and I've made an effort to do this ever since. It works.

Reword your notes

Don't just straight out copy them from the textbook/internet

That way, you're more likely to understand it

Display your study notes in a visual way

Highlight

Brainstorm

Draw pictures

Study with Friends and Partake in online Discussions

That way, you can bounce ideas off each other and explain concepts that others may struggle/ be taught concepts you're having trouble grasping.

Monday, May 20, 2013

This is Part III of the Journey of a Test Analyst series.

Starting work as a Test Analyst

After 4 weeks of training I was finally...

DUN DUN DUN

Off to my first project as a Test Analyst!

Inside, I felt a mixture of this

And this

I was nervous as this was my first project and part of me was a bit worried that I'd put my foot in my mouth and say something stupid or not ask smart enough questions. But then I was also pretty excited as this is what I've been working towards this whole time.

On my first day, I had two people ask me if this was my first (ever) project. I gotta admit, that didn't sit too well with me as from that point on, on my first day, I was worried that I looked a teeny weeny too fresh-faced. But hey, it is what it is so I smiled back and responded yes it is.

Here are a few things that struck me the most about my first few weeks on the project

I should have kept notes on which Design Specs referred to which part of the functionality.

Since I was working on a pretty big system, there were a decent amount of Design Specs I had to 'study' to understand how the system was expected to operate. I wish I kept better -coughlegiblecough- notes.

There are HEAPS of people that work in IT projects in roles that I never knew existed

Namely, architects and infrastructure. Up until this point, I only associated architects with home design and infrastructure with cities.

Face to face communication is much better than email and/or phone

Even if you're a super-guru with the written word- it can still be difficult to articulate your thoughts in such a way that what you say, and what the other person hears/reads are actually the same thing.

One of the Grads from the previous intake gave me such advice which is to hold face to face conversations then email the other person a summary of the discussion to make sure you're both on the same page.

Only using 1 screen can be rather difficult

This is particularly true as I can look back on only using 1 screen after being exposed to the joys of 2.

Make sure I get straight to the point when I ask other people questions so that:

1. They don't see me as a time-waster

2. They're more likely to be happy to answer questions in the future

You can expect A LOT of reading in the first few weeks

I had to not only read the Design Specs to learn how the system was supposed to operate but also read up on the terminology of the organisation that wanted this system built.

And here's what else I learned from my first project (other than in the first few weeks)

It's great to make friends on the project, who work in separate areas to you

Other than the obvious perks of having friends, I liked hearing about what Developers, Business Analysts and Technical Testers need to focus on in a project.

If you want to upskill- just put your hand up

We used Sterling Business Integrator to check what was happening between a few systems. Since, I wanted to learn how to use this tool- I asked for help and guidance on how to get started. One of my best friends on the project, who has since gone back to Australia, and my mentor were great at showing me how to use this.

How to take a screenshot of just the active screen

It took me about 6 weeks to realise that there was another way to take a screenshot other than Ctrl + PrtScn

Answer: Alt + PrtScn

You need to be very clear in what exactly you are raising a defect against

Since you only have the written word (and screenshots to support what you say) at your disposal, it helps to describe exactly what you did that resulted in you discovering the defect and state clearly if the defect is against code, design etc.

This is Part II of the Journey of a Test Analyst Series

The Application Process
Well to start with, the thing that really caught my attention was the fact that a handwritten cover letter was asked for.

So this caught my attention for a few reasons.

I figured, since we're actually using snail mail to submit part of our application; they're more likely to be read

No backspace was available for my cover letter (Shock! Horror! Old school it is then.)

Will my handwriting be legible? Most people can't read my handwriting when I don't make an effort to be legible. I'd liken to a doctor's.

I also prepared and submitted my CV, placing emphasis on the skills I possess that applied to the role of a Test Analyst.

Quick tip: Make sure to proof-read your application. I've been told time and time again that attention to detail is muy importante to be an effective Test Analyst- so I like to think I possess this trait.
BUT, if you get a haircut and I don't comment on it, please don't be offended and throw this blog post in my face.

Now, onto the next stage: Phone interview.
I had this during exam time on the top floor of the uni library, so thankfully this was short and sweet.
My impression of this was that it was an opportunity for the company to gauge what I'm like and how I communicate.
I do remember thinking: OK Nicola answer the question but don't talk her ear off. (I once had a 6 hour phone conversation- I really can be quite a chatterbox).

Luckily I made it through that stage as well. *fist pump*

So it all came down to the face to face interview.

This was done through video conference. Admittedly, I did find the start a bit distracting as I kept on checking myself out on the corner of the screen to see if I looked OK.

I also appreciated the fact that they made an effort to make me comfortable and used some humour to diffuse the situation.

Looking back, I was quite glad that I did some background reading (study) on Assurity before I came in. You see, you know how you usually get told to do your research on a company before you apply/interview, well in this case- I'm certainly glad I did.

With regards to any specific questions on what I was asked in the interview..... hmm well let's not spoil that part :) some things are best discovering yourselves!

The Graduate Programme
And now we come to the Graduate Programme. Hmmm how do I put this?

Well let's just say that one distinct thing that I remembered from the Grad welcome drinks was the knowing looks that the previous Grads exchanged among themselves when they realised we were just about to start the Grad Programme.

I learned A LOT in the Graduate Programme including:

How to articulate your ideas clearly

Professionalism

ISTQB

Public Speaking

To be honest, I'm not sure I'd say it's what I had learned that stick out to me the most now that I look back on the Grad Programme- but more the people I had met (as cliché as that sounds). Don't get me wrong- the intense four weeks made having an exam period where I was tutoring and working (over 25 hours/ week) and studying for exams seem like a breeze. Completing 2 projects in a relatively short space of time, helped us understand the importance of time pressures and how, at the end of the day, you need to complete things (to a high standard) by the time they are due- even when circumstances may change on you.

Monday, May 6, 2013

This is Part I of The Journey of a Test Analyst Series.

So in this post I'm gonna go over how I got into the IT industry in the first place; i.e. how and why I first started thinking about it.

First off, I saw the job advertisement on Careerhub. For those who do not know, Careerhub is a website for job seekers that are currently in (or just graduated from) a tertiary institution.

A few parts of the job ad stood out to me.

These are:

A career in the IT industry --> given our reliance on technology these days; job prospects would be good.

Assurity are thought leaders and that was something I wanted to be a part of.

Exposure to different projects and industries

Focus on innovation and improvement.

And last, but most certainly not least- training.

I'm now going to proceed to focus on this last point. You see, I didn't study Software Engineering or Computer Science. In fact, I studied German and Economics.

So then you may be thinking "How do you get from a Bachelor of Arts and Commerce degree majoring in German and Economics to a career as a Test Analyst?"

You see, I gained a lot of transferrable skills throughout my time at uni such as written communication skills (from my German translation course and the International Trade essays I had to write for my Econ assignments) as well as analytical skills (from my participation in the Alternative Budget Competition).

I've also been able to use these skills in my time as a test analyst so far. Although one may think that to be a test analyst you need to have a strong technical background, that's not true.
Yes, for some roles you do need a fairly technical skill set, but I'm of the opinion that if you don't already possess the technical skills- then just learn them. You do, however, need to pay attention to detail and have strong communication skills.

So I soon found myself typing out my CV and writing out my handwritten cover letter (meanwhile freaking out that I would make a mistake and have to start the letter again).........