How I see the QA mindset part 1— The Business Value
This scene from the movie has made an impression on how I understand my job. Please watch it since I’ll be talking about it.
And don’t forget to come back here
The first time I applied Steve’s priorities when testing an app I got it wrong - I thought that the key to success is prioritizing fancy stuff over functionality. Believe me, it doesn’t work on a 10yr old monolithic project.
It failed miserably.
That is not the way.
I had to dig deeper if I wanted to understand his genius.
What I learned after my failed live experiment was a concept I was not consciously considering up until then:
The business value.
It was a layer of complexity I did not account for when testing up until that point.
Each task, issue, bug or implementation has various layers and multiple values assigned to it: Priority, severity, story points, story, epic … the list goes on and on. There is one that is invisible and impacts all the others from the shadows, you could say - it is the business value.
A team that works on a medical project will have different priorities when compared to a team working on a gaming application.
This is nothing new, I assume, to anyone.
But why is the business value concept especially important for a QA?
QA’s purpose and role is to elevate the end result. I imagine the QA’s position like the “man in the middle”. The decision making might not rest upon his shoulders, but he can definitely have great influence on how things are done.
I’m not saying that the other roles don’t have influence over the project. Everyone does, but each role has it’s own nuance.
Returning back to the scene from the movie.
The entire team was present when the decision to implement a functional story instead of a non-functional one was taken. Writing it like this, it makes perfect sense, doesn’t it? Most of the time the functional story will have priority.
But, the team was not completely in sync with the business value of the tasks. The QA should have advocated for the non-functional task in this case. The QA needs to follow the golden rule — he who hath the gold maketh the rules. In this case, the gold owner was mister Jobs.
Steve Jobs argues that he wanted that particular implementation for a long time already. Even if he seems a demanding boss and would most probably avoid having such a boss, I emphasize with him here — I would also get angry at this point in time.
QA should act like a diplomat, who tries balancing opposing interests.
I believe that the QA is the one that double checks not only the developer, but each member of the team, in one way or another and with various depth.
I will try writing an article on this ridiculous statement in the future, explaining my arguments for it, but for now I’ll leave it as it is.
The outcome of not being in sync with the business value?
Loss.
Profits dwindle.
The business loses.
The team misses their purpose.
And it is to be expected, because they are not doing what they should do — work towards prosperity and success of the idea and it’s implementation. The end user, whoever it may be, is not satisfied with the product. If possible, he will chose an alternative. If not, the end user will get to hate the product and it’s manufacturer.
Any person will chose tools with which he can work better, easier and more intuitively at any moment in time. And if you get to be recognized as a great tool builder, as Apple’s mission was, you achieve success.
But, just as Jobs says, sometimes you have to take risks.
Risks mean getting out of your comfort zone. You need to try something new. Your idea / suggestion might fail. Miserably. But if you don’t try you will never know.
Should a QA just accept the Acceptance Criteria or specifications as they come?
No, obviously not. As a QA you need to doubt everything
Like a real scientist, one that has no personal interest or gain in the matter.
It is an interesting delicate balance it needs to be attained: one should care about the idea, yet one should not “contaminate” the outcome with his opinions or feelings on the matter. Just let the facts speak. Just let the truth manifest itself.
Your arguments need to have their foundations dug in into facts. Think of them as your “wing-man”. A trustworthy, loyal and dependable friend.
Take risks, ask stupid questions, try changing the perspective as much as possible, try viewing the issue at hand through as many layers as possible, get into the details, go macro level. Get creative.
Be a little bit like the Joker.
But, always consider the degree of this risk taking and creativity — set clear boundaries: in time, money, effort… something that is easy to quantify. With the boundaries clear, one can easily know when to stop and when the effort is getting irrelevant.
Sometimes, as a QA you might even need to play the fool, in order to come up with genius ideas… If the job was straight forward and no nuance was needed, it would get automated. (and since this is currently the case with the manual QA’s, it is critical to stay ahead of the machines and sharpen our human perception and skills).
I’ve talked quite a bit about the end user.
He is just one element of the mindset.
But strangely enough, he is not the top priority.
Priority #1 depends on the business: what it does, how it does it, when, where etc
Business value is the thing that brings the most money in.
Follow the “yellow road” (a reference to the road in Alice in Wonderland, which means the gold or the money). That is how a QA prioritizes correctly according to the business.
As a QA you need to adapt your tests and priorities according to the business needs. Some teams never change their business, some may do it often. QA needs to always apply the correct priorities to each test suite.
No 2 implementations are the same. You need to take into account all of the variables. The output could be the same — the same test suites were run, but the “backend logic” that you went through, should not be the same.
Each sprint, each single task has it’s own DNA. This makes this job really fun and interesting. And challenging.
Account for the particularities of each individual situation.
Be adaptable, expect changes, prepare or at least take into consideration alternatives for the things that might not go according to plan.
Prepare / expect the worst, hope for the best (outcome).
I am aware my take is a little bit on the opportunistic side and has some darker shades (maybe even some Game of Thrones vibes here and there).
I am planning on writing at least one more article on this subject but until then I’ll try to read all the comments and consider them when I’ll write again.
