Blog Image

Testsson

A blog with a holistic view on software quality

Highs and lows, ideas, rambling and fire starters.

Never go back for your phone and be ready to adjust your plans…

Common Posted on 2018-06-07 11:10

As a fan of the Hitchhiker’s Guide
to the Galaxy “trilogy” I’m well acquainted with this section:

As she was getting into the elevator Tricia, slightly preoccupied,
realised she had left her bag in her room and wondered whether to duck back out
and get it. No. It was probably safer where it was and there wasn’t anything
she particularly needed it for. She let the door close behind her.

Besides, she told herself, taking a deep breath, if life had taught her
anything it was this:

Never go back for your bag.

I’m currently attending the Nordic
Testing Days in Tallinn and as usual I have scouted the schedule for the
sessions I’m interested in. This morning there was to be a workshop called (Re)invent
your test strategy with exercises using the TestSphere cards. The workshop was
starting at 10:30, after the half-hour coffee break so there was plenty of time
getting to the room. As my phone was really low on battery I therefore took
this opportunity to go up to my hotel room to charge that phone and get my other
one in case I wanted to document anything from the workshop. Said and done I
then went to the conference room where the workshop was held and got there 15
minutes early. Judge of my surprise when I found out that the workshop was full
and there was no way of getting a seat. Looking stupidly at the track chair this
one sentence kept repeating in my head “Never go back for your…”.

I’m aware that in Tricia McMillans
case she missed a space ship when going back for her bag the first time and she
missed the gig of a lifetime when she didn’t go back for her bag the second
time and in comparison missing out on a workshop might seem as a minor issue
but here and now it’s really frustrating. I guess that the lesson learned is to
stop and consider what you might be missing when you do or don’t go back to get
something you forgot but at the same time there are quite too many unknowns for
doing a proper risk assessment…

Change of plans

As one of the speakers on the conference didn’t
make it here today I have agreed to do my talk today instead of tomorrow.
Suddenly I got really nervous and think I need to do some dry runs on my talk. Since
I shortened my talk I’m not 100% in control of my slide deck so this might get
interesting…



HUSTEF and back again

Common Posted on 2017-11-27 09:52

The
journey to deliver my first conference talk and making it out alive.

How it started…

In April I visited our office in Budapest and
was asked to give a presentation of an ongoing project I was conducting. After
the presentation I was approached by one of the attendees who thought it was a
good presentation and suggested that I should apply for the HUSTEF conference. Since
I had done presentations at various meetups and answered to the call for paper
for other conferences in the past I was quite intrigued by the idea. I had not
heard of this specific conference earlier but after checking their web site and
looking through some of the previous talks held there I was convinced that it
would be a good place to do a talk.


Preparations

I prepared and sorted information around the topic, wrote a biography, sketched an initial version of the presentation and submitted my paper just in time for the deadline in mid-May. A month later I received a mail that started with: “Congratulations. Your proposal #60 with the title A quality nerd in a DevOps world has been accepted for HUSTEF 2017 Conference.”

At this point I was struck by Speaker’s Remorse but at the same time I felt that this was something I really wanted to do, so I shuck it off and turned my attention to what needed to be done in order to get ready.

Knowing I’m a master of procrastination I laid out a time plan for completing the slides well in advance of the deadline. One challenge was the time constraint for the actual talk, 25 minutes including Q&A. My plan was to address testing in the DevOps tool chain, how we applied our version of Googles Test Certified model and ideas on building cross functional teams which meant that I had to boil down three ~30 minutes presentation into one 20+ minutes talk. Cutting out samples, quotes, funny references, slides covering buzz words et.c. I had a set that ought to work. I did quite a few dry runs with that slide set and I felt it was working fine. Average time for the dry runs was a few seconds shy of 20 minutes.

While I’m at it…

Since we have an office in Budapest I planned to arrange a Meetup there while I was in town and deliver a more in-depth version of my talk. I contacted two of the largest local testing Meetup groups but in the end they had planned for other sessions during that same week and we couldn’t quite synchronize our schedules. The door is still open for any future visits though.

The conference

The first conference day was a half day with tutorials and in the evening there was a speaker’s dinner where I had the luck to get a seat next to Dawn Hayes who was one of the tutorial and keynote speakers for the conference. Had a nice dinner with good discussions before taking a scenic evening stroll over the bridge across the Danube back to the hotel.

Second and third conference days consisted of keynotes, sponsor presentations and track talks. There were two parallel tracks so one could select the ones that corresponded most with your area of interest.

My slot was the last track talk on the last day, just before coffee and to top it off the conference party was planned for the evening before. This all catered for the likelihood of having a slightly tired and not to focused audience.

The talk

After lunch it was time to get prepared and enter the “presenter zone”. I watched the two preceding talks, deep down hoping for them to be kind of rubbish so mine would be conceived better, turned out they were both excellent (in fact the guy before me won the speaker award).

I thought that I would be a nervous wreck by the time it was my turn but I felt nothing but a small adrenaline rush as I entered the stage. The spotlights made it hard to really see the crowd of some 250-ish people but I did a quick intro and started my presentation.

Trying to keep my mind on the audience and the message I delivered my talk and finished within the allotted time. Got some questions that showed that people had listened and heard what I had to say. Talking to a couple of people from the audience afterwards and checking the postings gave an indication that the talk was well received.

Aftermath…

During the conference the audience could vote on the different talks via the conference app. As it turned out my presentation was voted third best track talk (of 24) which felt extremely nice and I would like to thank the audience and hope you enjoyed it.

All talks were recorded and have been posted in the HUSTEF YouTube playlist. With my usual luck there were some technical issues with the recording of my presentation so the stills from the presentation was added over the recorded sound afterwards. Unfortunately this affected the flow of the presentation and the intra-page transitions were lost. Recording of my presentation on YouTube

Why do a conference talk?

Getting up in front of an audience doing a talk is for many of us far outside our comforts zones, so why would you even do that? In my case I feel that I have something to share with my community. After attending all sorts of venues where people from the test sphere meet I have both learned a lot and realized that some of the things we are doing and working on are totally new or otherwise interesting for others. Challenging myself and applying for this conference I felt it would be a good opportunity to grow as a person as well as tell our story hoping it might inspire others. I found this so rewarding that I applied for a couple of more venues and it’s definitely clear that I’l do a track talk at another conference in June 2018. I’m really grateful that my company support me to take the time needed for preparations and going to these conferences.

If you want more good reasons, and tips, for
talking at a conference then you should read this blog post by Rob Lambert.



Knowledge for nothing and training for free…

Common Posted on 2017-05-16 11:38

Do
you feel like you are stuck in knee deep wheel tracks doing the same thing day
out and day in while the rest of the world seem to move out of sight into a
hazy distance of cool techniques and mysterious processes?

You do need to invest time and energy but defining
training for free as something that come without a monetary cost there are some
simple things you could do in order to evolve even if your organization don’t
see the need/don’t have the budget for courses or conferences. There are things
like test bashes, meetups, un-conferences, web casts et.c. that are either
free of charge or low cost. If you are serious in your quest for deeper/wider
knowledge I would most definitely suggest that you attend a real life event as
a meetup. The chance to talk to your peers and ventilate any ideas, impediments,
worries is invaluable.

Start
by checking out what’s available in your area on sites like Eventbrite or
Meetup. There are usually a number of groups and events available. Either be
selective or just attend any gathering you find interesting (if nothing else
there’s usually free food and drinks). You’ll soon find out what is right for
you but a good idea is to check what other groups the people in your group are
signed up to.

If
there are no groups in your area you could consider staring one yourself. If
you don’t have any cool presentation to share you could always get people
together and start discussions.

Conferences

If
you get an opportunity to attend a conference it’s wise to consider your
options. For a long time there were basically only three major test
conferences, STAREAST, STARWEST and EuroSTAR. I attended EuroSTAR between 2003
and 2007 but felt that there was just minor news year to year (besides
exploratory testing that kind of shook the community at the time).

Since
then the number of test related conferences have increased dramatically and
there are both generic ones as well as the ones with a special focus. There is
also a great fluctuation in costs, mostly depending on where the conference is
located. As an example two days at HUSTEF in Hungary or Nordic Testing Days in
Estonia are around €300 while Agile Testing Days in Germany and EuroSTAR are
well over the €1000 mark for two days of conference. The price difference normally
doesn’t reflect the quality of the venue.

Share!

Do you have something you feel the community
could benefit from? It doesn’t matter if it is a new revolutionary idea,
improved processes, applied tools or just lessons learned, there are always
someone who want to hear what you have to say. Share your thoughts by discussing
them with your peers, do a lightning talk at a venue, present at a meetup or
send in a paper for a conference. The best way to learn is to teach.

Practice makes perfect

Attending conferences, meetups and so on is of course very good but anything you learn have to be interpreted and come to use. It’s said that things like courses, books, conferences only constitute some 10% of developing new knowledge. Networking, mentoring, and feedback is around 20%. In the end it’s working on real tasks, challenging current ways of working that ads those final 70% that is needed to master something.

Go out there and exploit new things but make sure to add anything valuable you learn to your personal toolbox and let it come to good use.



An uncommon understanding

Common Posted on 2016-09-23 15:50

About a year ago I attended a meetup at King in Stockholm featuring James Bach. During his talk James drew a number of well-known geometrical shapes like triangles, squares and circles on the white-board. Some were filled with lines and some were empty. He then asked the audience a question in line with:
-“Raise a hand if you see a filled triangle on the board.
We could clearly see that there was a filled triangle on the board and eager to please the great Mr. Bach we all happily raised our hands. He then looked at us in the audience for a while before turning to the board saying:
-“What do you mean? The triangle is empty!
While pointing at the empty circle on the board…

We all made the assumption that we had a common definition of a triangle and focusing on the task at hand we all missed out on the opportunity to ask just one simple question whereby we could have reached an common understanding on what he meant when saying “triangle“.

I sometimes think about the above and the fact that we all often miss out on the opportunity to ask questions and clarify things.

It get extremely apparent among our applicants when faced with a technical assignment we use in our hiring process.

The assignment consist of some high level instructions and access to a WSDL for a simple calculator. The short instructions contain the following information:

  • Set a scope and define requirements based on what you can find out through the supplied WSDL
  • Provide a set of automated tests that you think are necessary to verify the requirements using .Net / C#
  • Tests should cover functional and non-functional requirements for the given service
  • Make a simple report of your findings
  • If you have any questions about the assignment or the process, just get back to us.

So the applicants can basically set a scope and come up with their own requirements, cover it with the needed tests and produce a simple status report. Simple enough one would think?

So far all applicants have provided some sort of automated test suite. Some have created good test cases, showing that they at least know the basic in regards to input validation, equivalence classes, boundary values, exception handling et.c.

Some have provided some sort of status report, others have actually covered the seeded defects with tests but haven’t reported that they found anything out of the ordinary.

No one have provided any information in regards to scope or requirements…

When we ask why they haven’t listed even the simplest requirement some say that it’s obvious what a calculator does(1) but more often we hear that they did not know what the requirements were(2).

  1. We are back to the “assumption is the mother of all f_up’s” scenario again. If I don’t know what their understanding of the application is it’s hard for me to say that the supplied test cases are in any way conclusive.
  2. If they don’t know what the requirements are then why not just come back to us with some questions in regards to that? The fact is that we have a ready set of requirements to supply them with if they ask for it.

We end up with many applicants that flunk this fairly simple assignment just because they make incorrect assumption or do not bother to ask for more information.

If you are not asking questions or use some tool/model like specification by example, BDD or other in order to reach a common understanding of the task at hand it’s about time you start doing it!

The only true wisdom is in knowing you know nothing
Socrates

Image by @kirsty_joan

#BDD #JamesBach



30 Day Testing Challenge

Common Posted on 2016-07-09 17:35

Don’t know why but I have totally missed this thing going on in the testing community. Suddenly the hashtag #30daysoftesting started to pop-up in my flows.
A short investigation showed that this was a challenge started by Ministry of Testing.
Looking into the details it looks quite simple and fun. My problem now is that I’ll be on vacation during most of July and will have a hard time to complete some of the challenges.

As a tester or holding a role within software quality you might want to check it out? I’m going to take a stab at it and see what I can complete out of office…

There’s a PDF with all the challenges here.



Wanted: New colleagues

Common Posted on 2016-07-04 09:38


We’re looking for an experienced QA Developer who appreciate quality and who constantly strives to learn something new!

The Platform team consists of 60 dedicated developers, QAs and product owners in 3 locations and 8 scrum teams.

You’ll be focusing on ensuring that our backend team delivers the cleanest possible product and preventing bugs from ever making it to production. The aim is to go beyond simple quality control and adopting a real quality assurance mindset instead, ensuring that the team is building the right things, in the right way, with unit test and test automation as a natural part of development.

Betsson Group | Jobs



Automated testing is dead, long live fact checking

Common Posted on 2016-07-04 09:07

I want to challenge a term that is widely (mis)used and that is the term automated testing. Whenever you hear talk about automated tests I want you to replace the word “test” with “check”.
It is true that a lot of the activities that tend to fall under testing can be replaced with automated fact checking, and then it should, but checking and testing are two activities with different mechanics.

Testing is a human activity and not a machine activity and can never, or at least extremely seldom, be omitted from any delivery process that claim to have good quality as an objective.