Needs, feelings, emotions and software testing

A couple of weeks ago I attended a short workshop on nonviolent communication, and for me the root of it wall was the link between needs and feelings (see basic cycle below)

Image credit:

My mind started wondering around how can this be useful and interesting in the context of software testing.

First thing that came to mind for detecting dark patterns (more here). This is an obvious usage since dark patterns usually cause negative emotions while we as testers need to be observers.

Second approach to using this was testing something like emotion user journeys. This is a little bit on the opposite of the dark patterns facet., since when designing a user journey in a product or service, the UX designer can target some user emotional states, and as testers these intended emotional states should also be targeted as things to test. So, the questions can be “What feeling would I associate with the user journey so far? Is this in sync with the intended one?”

Third usage scenarios I see is around writing testing findings in a more empathetic way or even for defects that have not visible and obvious technical ground, but they just “feel wrong”. When I say this I have in mind those defects that seem obvious on a human and emotional level, but have no technical ground, things like “i just feel this is wrong, but why?”. In this scenario, I believe the nonviolent communication model can help, as it puts a flashlight on the feeling-needs pair.

Of course, I might be wrong, and things could be added, but this is what I see and believe now ūüôā


Framing – Why should one do it when testing?

Early 2018 I started to learn in a more structured way about coaching. During the first hour of an almost one month long training engagement the trainer mentioned framing, the coaching frame of reference, introduced as the context where coaching can exist and makes sense.

Later on, I read Daniel Khaneman’s “Thinking Fast and Slow” and was again put face to face with the topic of framing, with the author highlighting how framing can affect decision making when presenting a problem.

Today, I started fresh on testing a new application targeted towards a quite narrow audience, with high demand levels, expecting nothing less than the best (based on how much money they pay for this service). As I identified the first inconsistencies (this is how I like to call defects or bugs, but more on that in a future post) I realized that unless I  present it well, people will not understand its impact and might decide to not fix it.

So I started to build a frame, a frame of reference for the identified inconsistency and these are the questions I considered:

What are the working assumptions?

What is the context inside those assumptions?

What is the impact? (for the user)

This is vital to be formulated from the point of view of the persona for whom the deliverable is intended, with a clear understanding on what need the product fails to  satisfy. The impact can then be translated on the company side, in terms of lost opportunities or lost revenue.

A thing to consider is also avoiding to phrase the impact always as a negative thing. Ask yourself, what is a possible positive impact of this? Is there a context where this is an opportunity, a blessing? This is important, as it moves your mind to a different perspective point, allowing not to be a prisoner of just one option, point of view or context.

Are there workarounds?

Nobody wants to be with the back to the wall, and if the problem is really well understood and not one of the few life & death ones, there almost for sure are one or more workarounds. People need to know that the context has been explored and a solution was looked for, preparing for the next question. At this point leaders can gather confidence that team members are willing to take the steps towards finding the way to fix the inconsistency.

Is there one or more recommendations and what are some of the foreseen consequences for each? 

Quite likely the most important aspect! Decision makers sometimes need a leading line, but there is also the trap of having just one option. Here, the rule of three, as stated by Jerry Weinberg comes to mind. As one option is a trap, two options are a dilemma, three are the starting point towards really understanding the context. So try to find at least three recommendations, and you will find that from this point forward even more are visible. From this point on, leaders can really empower the team by saying ¬†‚ÄúYes, go do that‚ÄĚ or, ‚Äúyou have my permission,‚ÄĚ, and they will learn that the team is capable of building decisions that don‚Äôt need constant approval.


Today has been a intense day, and maybe this is why I’m starting again to write down on this blog.

This time I’m venting some negative energy, as I am quite dissapointed. Why? Because I learned a lesson on the hard way, a lesson on coaching and possibly human interaction.

Before jumping to reasoing, I’d like to bring back from the memory alley a short quote that stuck to my mind and that I have been trying to use, “always assume positive intent”. Even if I had it stuck to my mind for a long time I did not know where I got it from and did a quick search.

It’s from an old interview¬†with one seeminigly succesful person (since it was the CEO of Pepsi at that time), beingone of the taglines of the interview. It was mentioned as a life lesson, and since we live far too short to make all the mistakes, it’s advisable to learn from others.

Today’s low moment comes from encountering a person who even if acting in an agile coach position, failed to assume positive intent when reading a quick and harmless e-mail.

This is where the sadness comes, because I see dogfooding¬†as a good practice for every situation where delivery is involved. At the same time, when dealing with people, it’s hard to justify change in ones behaviour while not living the change you ask for.

Is it only me or it’s normal expectation to live by this rule as a agile coach, and not only ? Shouldn’t coaches manifest and live the values they preach and ask others to embrace?

Now that the rant is over, I need to figure out a way to turn this event in a positive learning!

Image credit:

1-st #30daysoftesting mobile challenge

For the first day, the easiest task was chosen, that of picking up some of the tools to be used for testing on mobiles.

For reference, the complete list of challenges is available in the previous post.

The first challenge asks for a photo of the mobile testing lab and this is my contribution.


Even if I have many devices in the office, laying around, including devices like Nokia S40, Windows Phone or even Blackberries, those two are the prime representatives of the current day mobile landscape, dominated by Android and iOS.

By looking at the picture, there is little to be said, but I believe it says a lot about today’s mobile landscape, with two dominating ¬†but if it was for me, the black notebook could be more important than any of the devices to have a successful test session, as it’s the “device”¬†where the tester’s notes are ūüôā




Testing challenges

It seems that testing challenges are a thing these days, and #30daysoftesting makes a comeback with a mobile-first version if I may call it so.

The mobile oriented #30daysoftesting challenge is somewhat easier to achieve, as there is no time due date, and this makes it more suitable for some persons with a busy schedule.

Here is the breakdown:


I hope to make it through and also to have the determination to write about as many of them as I can.

In the end, equally important, I need to thank @pot_licious for inspiration and setting a good example with her blog


#rtc2016 reading list

Conferences are great places to meet new people, learn and load yourself with lots ideas and things to think about until the next edition.

Since most sessions are high level, they are just offer seeds for you to grow on later, and what is a better way to grow your knowledge than a book.

This year, while attending the Romanian Testing Conference  I tried gathering the books mentioned in the talks.

Some sessions were quite rich in mentions, with @karennjohnson and  @steveo1967 worth highlighting. Thank you!

<<Errare humanum est>> said the old Latins, so If I have missed books mentioned in other sessions, please leave a comment with the reference.

Image credit: Romanian Testing Conference 2016.

Agile Coach Camp Romania 2016 (#accro16) reading list

Around two weeks ago the first edition for Agile Coach Camp Romania (#accro16) took place, and it was a wonderful event. Since it was a informal gathering of people open to learning, books were an important part, even if not mentioned explicitly.

There was a pretty cool collection of books brought by attendees , open for lending during the event (and why not after ..)


Beside the lending table that was formed during the event, attendees wrote down a list of influential books for all present to have and share, and this is one of my retribution gifts for the gathering. I tried to put together in an electronic format the list, so that other can use it.

At the end all agreed that such events need to happen again, and hopefully around this time next year this list can act as a reference point of the changes and shifts happening in the local community.

The reading list from Agile Coach Camp Romania 2016 (#accro16):

To those who were in the #accro16 gathering, let me know if I missed any ūüôā and if not, let’s read ūüôā

Is agile short-term oriented?

This past weekend I attended one agile related event. It was wonderful in many ways, and one such a way is that it triggered me to think about starting to write down my thoughts (as it seems all to often Twitter is not long enough).

There was one influential session where culture was the main topic, and one discussed aspect was that long-term vs short-term orientation of various cultures. A side talk got my attention, as someone mentioned “Agile is short-term oriented! Just look at how short sprints are”. A first, impulse was to react on the spot, but a blog post is more appropriate.

I strongly disagree with this view, and if there are bad things to say about agile, this is not one of them. Let me detail a little bit below.

Agile is based on the now famous¬†manifesto, and the seemingly lesser known list of principles. One of them says “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”. Writing principles lists is a¬†serious endeavour, and these have been under scrutiny both before and after their release. Sustainability makes sense only in long term oriented approaches, and including it in the principle list is definitely a sign that the approach based on the those principles is not a short term oriented one.

What’s more short term oriented? Chasing a moving target with a train or using something more nimble and easier to steer? ¬†This is a good analogy on long terms ¬†approaches and their associated plans. At that meeting some approved and supported the need for a plan to be followed, thus helping me build the rails for the train to chase the target that is the product or project vision. Agile seems to be a better approach, because in the end the purpose of a project is to deliver value, not following a plan. Just think of the last time a customer was happy with a followed-up plan, but receiving a not so compelling set of deliverables.¬†Change is embraced and welcomes in the agile way of working.¬†Change support offer the chance to adapt to the context and change direction if needed.

Getting back to the initial statement, it’s worth noting that iterations are one of the most visible and talked about aspects when people think of agile development. This is happening, even if many times it is mentioned that “Agile is not only scrum”.¬†Having shorter iterations helps agile implementations in at least two ways. One is for enabling flexibility in when change occurs, and the second one is a risk management aiding tool, with shorter sprints containing smaller numbers of risk-bearing-items (a.k.a. work items) that can provide “surprises” when opened. Maybe this is why shorter iterations are praised for their effects, while at the same time influencing people to say agile is short term oriented.

This is my view on this, and please let me know view in comments

Image credit: