Quality, Value, and how all of this might help

Over the past week I was surprised to receive a pingback from Eusebiu Blindu on Quality is value to some person at some time. He raises some very conscious thoughts about the term quality, value, and the Relative Rule from Michael Bolton, so make sure to read it, as I will explain some nuances from the Quality Software Management Series from Jerry Weinberg that should explain the pieces I left out so far.

Continue reading Quality, Value, and how all of this might help

Answers to an interview questionnaire

Parimala Shankaraiah, the curious tester, wrote a blog entry on hiring testers. In it, she references a questionnaire for interviewing new testers. Taking a closer look into it, I felt the urge to answer the questionnaire. Follow me along while I visit the 25 questions there, though I’m sure it’ll take me more than the 1.5 hours indicated there, so I’m sure to get some penalty points deducted.

Continue reading Answers to an interview questionnaire

ParkCalc automation – Keyword-driven tests in FitNesse

To conclude the ParkCalc mini-series, I choose to work through test automation using keywords with FitNesse. As I was using Selenium mostly with RobotFramework, I decided to use Selenesse for the integration into the FitNesse environment. Here is the write-up as I implement the tests.

Continue reading ParkCalc automation – Keyword-driven tests in FitNesse

Interview in Software Test & Quality Assurance

Matt Heusser is setting up an interview with me in the Software Test & Quality Assurance magazine. The name of the series is Ask The Tester, and until now there he interviewed Jon Bach for the most recent magazine issue and Michael Bolton for the next to come. That said, I feel honored to be the third in this series next to these great testers.

As the name of the series is “Ask The Tester” the community is called for submissions of questions. So, if you have any particular question for me regarding testing, the Miagi-Do school of testing, Agile testing, Weekend Testing, writing about testing, etc. please leave a comment on this blog entry with your name, city, province, and country, and you may end up with your name in a print magazine.

Quality is ambiguous

Challenged by Michael Bolton, Brian Marick wrote a blog entry about a famous quotation from Jerry Weinberg:

Quality is value to some person.

Marick called his entry “Quality is value to some person” restated. In his entry he describes quality without even using the name quality.

After having read Marick’s piece, the only thing I see is that this whole discussion is pointless. How does the discussion about what quality is lead to better software? How does the discussion lead to better testing? How does it lead to better management of the projects around us?

There is one precise point underlying the discussion, that Jerry also mentions in his Quality Software Management series, and that – to me – Brian seems also to agree to. Quality means different things to different persons, and that means that quality as a term is ambiguous.

It didn’t take me four years of working as a tester to realize this. Recalling the past few years, whenever I was asked what the quality of the software is, I was puzzled about what to answer. Maybe “42” is the right answer there. And of course, every problem in the software is a quality problem. For infinite times I ran into troubles, because the quality I thought was relevant did not match the quality for the next person to complain.

That said, since quality may mean different things, we have to find out what quality to care about. But how do we do this? The first person to approach with this question is the stakeholder, the one who asked us to do quality related work for him. He may say something like “Quality to me means that the customer will be happy with the software.” or “Quality to me means that I can get money with the product for the next decade.” Helping ourselves understand what quality we ultimately should care about is part of what Cem Kaner calls finding out the mission of our testing. For this we need to work closely together with our stakeholders and try to find out what our mission for the current project or task at hand is, and how we can help assist in quality related aspects of the software.

Such a mission may be to test the product for risky bugs. Another mission may be to evaluate a product, and help to decide whether we may ship it. This may mean that we evaluate a tool for future use. Just like a dressmaker works together with you to get the dress you would like to wear, we need to work together with our stakeholders to help us understand how we can add value to the product in our unique manner.

That’s what a professional tester does. And it’s still a thing I’m working on to excel at.

ParkCalc automation – Templates for data-driven tests

As pointed out earlier, I wanted to work through a test for ParkCalc using templates. As this did not seem to work, and I got no clue why, I gave up and postponed it. Today I was able to take a step back with a fresh mind and approach the problem with a different focus. So, here is the template solution for ParkCalc automation.

Continue reading ParkCalc automation – Templates for data-driven tests

ParkCalc automation – A short reflection

Over the course of the past week or so, I wrote some blog entries on ParkCalc automation. Today I decided it’s time for a brief wrap-up on what I learned over the course. You can find the four parts written up so far here:
Getting started, Refactoring a data-driven test, Refactoring a keyword-driven test, BDD style tests

Continue reading ParkCalc automation – A short reflection

ParkCalc automation – BDD style tests

In the comments on one of the previous blog entries in this series, Pekka Klärck pointed out that another great way to refactor a keyword-driven test to a data-driven is the usage of templates within Robot Framework. Before doing this, we will take a look at BDD style tests using given, when, and then. Following an ATDD approach does not make sense for the problem statement given, but I will at least scratch that topic during the reflection.

Continue reading ParkCalc automation – BDD style tests