Blog Image

Testsson

A blog with a holistic view on software quality

Highs and lows, ideas, rambling and fire starters.

Förklara agil testning med hjälp av den agila testkvadranten

Agile Posted on 2020-09-17 14:01

En av grundpelarna i den agila testningen är att hela teamet ansvarar för kvalitén och utvecklare skall vara med och testa.

I ett team där bilden av test är att slumpvis knappa på ett tangentbord kan det vara svårt att förklara för de som inte jobbar med test att det innebär så mycket mer. Det går att sätta testningen eller snarare de olika aktiviteterna inom kvalitetsarbetet i ett perspektiv som de flesta förstår genom att använda den agila testkvadranten.

Denna introducerades av Brian Marick 2003 genom en tämligen enkel modell av en kvadrat uppdelad i fyra kvadrater där de två undre speglar tekniksidan och de två övre affärssidan. De två vänstra stödjer utveckling medan de två högra ifrågasätter produkten. Med tiden har modellen utvecklats för att bli ett ännu större stöd när man vill förklara och modellera agil testning. I sina böcker Agile Testing och More Agile Testing har Lisa Crispin och Janet Gregory lagt till element och exempel som gör det lättare att förstå och fördela aktiviteter i modellen.

  • Q1 beskriver aktiviter som verifierar det tekniska systemet
  • Q2 beskriver aktiviteter som verifierar hela systemet och affärsprocesser
  • Q3 beskriver aktiviteter som verifierar kvaliten. Här hittar vi många av de aktiviteter som de flesta förknippar med test.
  • Q4 beskriver aktiviteter som verifierar tekniska aspekter som oftast kräver att systemet är komplett

Genom att använda den här modellen kan man ofta skapa en större förståelse för var och varför man gör olika kvalitetsaktiviteter. Genom att lägga till en definition som Kristian Karl som är Test & Development Manager på Spotify presenterat kan man göra det ännu lite tydligare:

  • Den vänstra sidan har ett preventivt syfte i.e. kontrollera det förväntade.
  • Den högra sidan fokuserar på att hitta fel och defekter i.e. leta efter det oväntade.

Jag har använt de agila testkvadranterna på olika uppdrag där jag behövt få hela teamet att förstå hur man kan påbörja arbetet med kvalitet tidigare i processen, inte minst i team där det inte funnits någon testare. Bilden ovan är från ett sådant uppdrag där vi gemensamt i teamet mappade ut de olika aktiviterna innan vi började jobba fram detaljerna med hjälp av andra modeller.



Building diverse teams based on primary behavioral traits

Cross Functional Teams Posted on 2018-06-27 13:48

When dividing into teams for competition, like sports, we often select members based on their skills and personal traits fitting their position and to build a dynamic team. When having the opportunity to select team members for work we tend to choose people that are similar to ourselves, maybe because we understand how they function or we don’t have any clear plan. If the person is someone we’d like to go out and have a beer with we’d probably choose them as team mates. Trying to build a cross functional team with members who all have the same behavior impedes dynamism and the first thing to go overboard is often quality. Many companies focused solely on technical competence and perfunctory base the fit in the team on the beer test when hiring new people. When doing this over a period of time both throughput and quality will probably deteriorate in the teams. When having a team consisting of only one type of people you might end up with situations like conflicts between the dominant or no guidance for the passive.

A plan is needed to build more dynamic teams not only based on skills but also on personality. Implement the use of a behavior assessment tool to cater for a better mix of people in the teams. There are several assessment tools but Myers-Briggs and DISC are two of the ones I have been in contact with. Use the tools to assess the team and see what behavior you should be looking for in the next team member to get a good mix.

It’s also good if everyone in the organization understand how the selection process work with the best fit for a team as sometimes certain diversity is forced. This is of course done with good intent but might backfire and undermine its original purpose.

Building teams based on behavior might give you some teams that are obviously diverse when looking at origin, gender and age while others are seemingly homogeneous groups of people however still diverse when it comes to primary behavioral traits.

A well working team is not based on how the members look but how they behave in the group.

Image: Sample of primary behavioral traits as defined in DISC



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



The Agile QA Manager – working towards your own extinction?

Agile Posted on 2016-07-18 21:07

I was recently appointed QA Manager in an agile(ish) organization where the aim is to have truly cross-functional teams. I know it sounds like an oxymoron and the phrase rebel without a cause came to mind at first.

In an agile environment the QA roles, if existing, belongs to an agile team and the teams are responsible for any test specification and the quality of the product. Meaning that the traditional responsibility of test management belongs to the team. The QA Manager role needs to be redefined to find a purpose in this type of organization. This is not a new problem, there are postings and threads 10 years or older that handles the altered traditional QA roles and in my quest I have dug through some really good and some really bad articles.

So what is the verdict, is there a place for a QA Manager in an agile organization?

If you have a really mature agile organization with teams containing the right mix of T-shaped people (Subject for a separate post on a later stage) the need for a QA Manager might not be there. Seeing that very few organizations are actually agile and true cross functional teams are scarce there is a place for the QA Manager that is willing to adapt to organizational and process changes.

In short: If a QA Manager does the job right the role may become obsolete.

As a part of my new assignment I was asked to come up with a role description. Based on the current maturity of our organization this is the short list I presented.

The role of a QA manager in an agile organization is mainly about supporting, training, facilitating and coaching QAs and other team members and to ensure best practices are established and that quality is built into every step of the process.

What it is not
There are some things that traditionally used to be included in the job as QA manager that are not valid for an agile organization. This includes but is not restricted to:

* Writing heavy documentation such as detailed test plans
* Being individually accountable for the quality of the product

What it is

The role includes but is not restricted to:

* Personal support, mentoring, and professional development for QAs
* Participate in the recruitment process for QAs and Automation Engineers (roles TBD)
* Taking an active part in evaluating and implementing tools and processes focusing on the quality of the products
* Drive the evolvement of true cross-functional teams
* Ensuring the teams implement and follow best practices to prevent defects finding their way into the product
* Drive the quality aspect of CI/CD in close cooperation with the infra team and the Development Manager
* Set the quality vision for the department
* Ensure that any work/process changes has a clear purpose and is moving towards the agreed vision
* Coordinate any cross-teams test/verification effort
* Help out with hands on testing when needed

Inspiration
These are some of the articles on the subject I have found interesting that I have used for inspiration for this post.

Gojko Adzic – Changing the role of test managers
Katrina Clokie – Test Manager in Agile
Amir Ghahrai – Role of QA Manager in Agile Project
Stephen Janaway – The end of the road for Test Managers?



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.



Next »