Category Archives: Software testing

Posts about software testing in general

Standard

Posted by

Posted on

October 24, 2011

Posted under

Software testing

Comments

Leave a comment

Educational reflections of a fairly successful tester

Experience in any field comes through learning and perfecting the skills and knowledge you apply in many different areas. Working in the software testing industry has taught me a lot, over the years I have gained quite some programming skills, analytic skills, people management skills, learned a lot about all the different testing theories, read a boat load of books about testing, programming, test automation and quality assurance, heard a lot of people speak about it and gained quite a broad general knowledge of testing, or so I hope. All of this knowledge I apply, fairly successfully, on a daily basis in my job.
So what would it take for me to go from fairly successful to very successful? Do I need to gain some more specific knowledge? If so what exactly?

I love learning new things overall and related to my job in particular, i enjoy studying to get new ideas and get my mind challenged making space for the most unexpected and fresh approaches, perceptions and solutions.

Working for Polteq gives me an advantage of my employer providing quite a lot of trainings I can sign up for. Unfortunately when going over that list there is not all that much I would want to study at this point. I have studied books on TMap and ISTQB, ITIL, Prince, TQM and many other subjects, why would I now all of a sudden need to do courses in it?
Agreed, it might give me some new ideas, but it will not really challenge my mind I believe, especially since the courses are mainly oriented towards gaining certification in these subjects.

A while ago I needed to hand in an overview of my “educational needs” to my manager in order for the company to see how many people have desires in a similar direction and thus which courses they can arrange with a fair sized group. My answer to this request went something like this:

I feel a need in further education, however, at the moment I have no clear ideas in which direction I would want / need this education to be.

I am inclined however to say that my education should be oriented more towards gaining skills, both testing skills and softskills, given the frame of work I am being inspired by at the moment. This will help ensure moving test automation within Polteq and the testing community to the next level, the thing that i am aiming to in my professional life at the moment.

Standard

Posted by

Posted on

October 21, 2011

Posted under

Software testing

Comments

Leave a comment

Is it more difficult to learn something new as an adult than when we were kids

Over the last 3 years I have continually been amazed when watching our son learn new skills. It seems to come so natural to kids, learning. They go about it with extreme ease and are absolutely not dissuaded by initial failure, or even by repeated failure, in stead, they change their approach and try again, but now from a different angle or point of view (usually literally a different angle or point of view).

This has kept me thinking,  why is it so difficult for adults to learn something new?

Experiential learning

Experiential Learning Model

Kids have a big advantage when trying to learn things, they (often) look at them for the very first time. This helps them to not worry about what it is supposed to do, but to instead figure out what it does do. Whether it is the intended function or not, the child learns what the object can and cannot do in a rapid and fun way.

Whenever us adults encounter something new we always will try to draw from the past, look for something that may have been similar and go forward based on assumptions rather than intuition. In quite a few things it helps, but in as many things I also believes it hampers us. Most adults have a form of built-in “best practices” which they will use when they encounter something new (as described in the concept of experiential learning).

So how can we, as software testers try to not use our default boxed-in thinking? Is there a way to break through the barriers experience builds and look at something as if you see this truly for the first time?

One way I try to ensure I do not get blocked by my knowledge when starting on a new piece of software is by exploring it as I believe my child would do it. Rather than guess what it is supposed to do I try to figure out what I can do with it.

Fairly soon however, I tend to run into the feeling I have seen something like it before, or the feeling of recognizing a pattern which then triggers all kinds of things I have learned in the past. So, how do you get past this? Or should you want to get past it?

The fact that our mind works based on boxes seems a limiting factor, but apparently these boxes do come fairly natural for the human mind. One way I try to use for the so called “thinking outside of the box” is to expand the boxes in my head to contain several different boxes.

In the example above, where I start recognizing a pattern or have the feeling I know what I am looking at, I try to combine the two feelings, or hunches, and through that push my mind into a whole new trail of thought, thus breaking out of the original boxes, and shoving all of that into a bigger one. On top of that I try to change the context in which I know these patterns, transplant the feeling to my current situation and see how this could apply here, since I have to deal with a different situation, with different circumstances; different data, different programming language, different developers and designers, quite likely a totally different objective of the software I am looking at etc.

There have been all kinds of studies and theories that should help one think outside of the box, but what seems to work for me is a combination of things:

  • try to apply knowledge I gain from reading books (and I read a fair amount) into a practical situation
  • try to combine the new experience and the “learned” responses into its own, separate context of the here and now (e.g. the context in which I am currently working)
  • try to find several points of recognition or deja-vu if you will, and mash these ideas together into a whole new thing, within the current context
  • and to top this all of: I try to think of what my son would do to figure out what this object (or software) can do for him.
This approach may not always be the most efficient or for that matter the most effective, but it does ensure that whenever I try to learn something new, new software when testing it for example, that I expand my horizons yet a bit more beyond just this object under investigation. I quite often even get new insights into how I could have tackled a previous problem more effectively as well. Which then gets stored in memory and at some point gets reused yet again.
The vicious circle of learning is great, and finding new ways to expand your knowledge and the ways of learning new things is even greater!
Standard

Posted by

Posted on

October 6, 2011

Posted under

Software testing

Comments

Leave a comment

Systems Thinking

While reading Weinbergs “Introduction to General System Thinking” I started doing a bit of research on the web on it and stumbled onto a few entertaining videos giving a (very) basic introduction to what you can consider system thinking.

Since I quite liked this short series I thought I might as well share it with the world here. These are not my video’s I just ran across them on Youtube.

As the uploader of the videos states “Systems thinking is a way of appreciating complex social problems also known as wicked or messy problems”. I hope this collection of videos will help more people get interested in Systems Thinking.

Introduction:

Stakeholder analysis:

T, O and P syntesis:

Problem Picturing:

Standard

Posted by

Posted on

August 25, 2011

Posted under

Software testing

Comments

Leave a comment

How I, unintentionally, social engineered information out of a bank employee

I had a wonderful banking experience this week.
I was trying to move some money from a savings account to a current account, the savings account having plenty of money on it and the current account being on zero.

On my first attempt, in the weekend, there was no direct feedback from the system, so I guessed it would take till Monday for the transaction to be processed cause banks are closed over the weekend (yes that is how things work in Holland more often than you’d expect).
Monday I checked the account and no money there, on checking the transaction I found out the transaction was refused by the system without any indication why.
So I decided to try it again, without waiting for the feedback from the system cause it was now after office hours (yes I make really odd assumptions when banking, unfortunately experience has taught me that more often than not these assumptions are correct).

Next morning I check the account, no money in it. I think, that’s odd… So I check the transaction and yet again it is refused without a reason, just some inexplicable error code, which meant nothing to the helpdesk either as it turned out later on.

Being a persistent person I decided to try it once more, this time during office hours so that I could see the immediate feedback from the bank and of course could call them.

No surprise the transaction was once again refused.

On this I called the bank’s helpdesk.

I explained what was going on, e.g. that i tried transferring money from a savings account to my current account, both within this bank. To my big surprise the only identification I needed to give to the helpdesk person was the bankaccount I was transferring from, no extra verification who I am and whether I can proof that I indeed should have access to these details. Instead she asked me which of the current accounts I was trying to transfer to, naming the account numbers for me and telling me on what name they are, so that she could lookup the transaction and see what was going on.

Ever since reading Kevin Mitnick’s first book, “The art of deception” I have thought that social engineering could not be as easy as he makes it seem. Turns out it truly is. I social engineered, unintentionally, the account numbers and attached names out of a helpdesk employee of a bank. With this I could quite easily start playing around on the internet and clean out the accounts with purchases based on direct debit transactions.

The other odd thing came to me when I was told what was going on, why were the transactions being refused: we apparently never returned the original, signed contract for this savings account. I of course requested a new version of the contract to be sent to me.

On receiving it I decided to read the contract and the small print on it for a change. The smallprint contains a short section about possible wrong information on the contract, such as counter-account numbers or names and how you can adjust these. All you have to do is write the correct details on the contract, sign it and send it back.

So it turns out you can open a savings account, attach it to an account, put money on the savings account from one of the attached accounts all without ever signing the contract. On signing the contract you can change the details about the attached accounts to something else just by writing the new information on the contract and send the contract back to the bank. All by snail-mail.

On receiving the new details the bank will make the appropriate adjustments and send a confirmation (snail)mail about this to the account holder.

This sounds like a very slipperly slope for a bank to me. I was first of all shocked to notice that my details were given away so easily without verification and secondly that if someone wants, they can hijack an account relatively easily…

I did tell the bank that their verification of the caller should be changed, curious to see if they actually do…

Standard

Posted by

Posted on

August 4, 2011

Posted under

Software testing

Comments

Leave a comment

What did I get out of today’s testingdojo

It’s funny to see how difficult it is to get a group of people, who work with one another daily, to talk freely and share their ideas, even when their manager is not present and they are amongst their peers.

During today’s testingdojo, which again was supposed to last an entire day focussing fully on working with FitNesse, we started off with a talk about what we aim to achieve at our customer’s with test automation. I tried to enthuse the group by pushing them to think about the possible difference between “test automation” and “computer aided testing” and if there are differences, what does one mean and what does the other mean. From there I hoped to get to insight into what they think we should aim to achieve and of course whether or not their ideas make sense to us, as the leads on implementing test automation.

A real discussion on this never took flight unfortunately, moreover, the two people we have been working with closely on the implementation remained most silent of all. I am still not sure what the cause of this silence from their side was, natural shyness, cultural pressure, or something else. Instead I ended up pulling some keywords out of the group and discussing my thoughts on them. Not too bad either, but I do not believe I should have been the one talking this much about the subject.

The second part where I hoped to create a bit of discussion was on what the group believes to be good practices in testautomation. This also took some pains from my side, along with some poking, probing and planting the occasional seed, but some discussion arose on this. After a while one of them remarked that in the end it seemed that all things that can be considered good or best practices in testautomation also fly for manual functional testing.

This insight led me nicely back to clarifying the first point, what are we aiming to do: trying to remove manual testing all together or trying to create more free-space and time to enable them to do more and different manual testing? I do believe I got the picture across that we are not trying to take away manual testing, but rather trying to help them remove repetitive work. Since repetitive testing of the same items and same or similar functionality is quite likely to create a form of feature-blindness.

The term feature-blindness seemed to be a new concept for a big part of the group; however I managed to get this concept explained fairly easy by example.

In the end the morning session was not exactly what I hoped it would be, but it clearly did get the points I wanted to make across. Which were: think of what you want to test, try to describe for yourself why you want to automate something and then read it back in order to figure out whether it indeed still makes sense to automate this. Try to keep your tests small, self contained and reusable. Refactor your FitNesse tests into reusable scenarios, but also keep an eye out on over-complicating things by making everything a scenario, e.g. do not make a scenario for the sake of making it, only create it if you indeed have several identical tests which need different input data. And the most important of all as far as I am concerned in functional testautomation: Keep It Simple and Stupid. Even fancy stuff you should be able to keep simple, readable and brief. If at a first attempt you fail at doing it, don’t worry, move on and come back at a later stage to refactor your test.

One not so nice thing about today’s dojo was that for the second time in a row the second part of the day was rudely disturbed by some very unexpected downtime of our test-environments. We were told in advance that one of the environments would be taken down for urgent maintenance and patching, unfortunately both environments went down during this change which resulted in us sending the group off earlier than anticipated.

Main takeaway for me: I really enjoy doing these knowledge sharing and coaching sessions, I like it a lot and see it as a great bonus to my work as a consultant, especially since it makes me (and hopefully my colleagues) think about why I am doing things they way I am doing them.