DEV Community: Areti Panou

Does Quality fit in CALMS?

Areti Panou — Thu, 08 Jul 2021 20:41:22 +0000

This was originally published on my blog, https://unremarkabletester.com/.

Recently, I was asked to give a 15 minute introduction on Quality Strategy in DevOps for our upcoming "Efficient DevOps with SAP" course and I happily accepted. And then, to my horror of horrors, I realised that I needed to figure out what a Quality Strategy is and what makes it unique in a DevOps world.

Instead of trying to come up with a definition, I started considering what are some quality specific aspects within the CALMS framework that would help a DevOps transformation.

So, here are a few ideas on the Culture, Automation, Lean, Measurement and Sharing aspects to consider that might improve the overall quality of a system, from idea to end user.

Culture

When it comes to the online narrative of Quality in DevOps environments I see two major changes in mindset. The first one is that when we talk about quality we shouldn't narrow the discussion to functional testing activities. There are more things that affect the quality of our product, such as for example a well-thought-out user experience. Once we get beyond the Quality = Testing mentality, it is easy to see the second required change. And that is that quality is everyone's responsibility. Releasing a quality product is not a final check but a continuous state of mind for every task we work on. More often than not, this is easier said than done of course.

Automation

Automation is the part that gets the most attention in any DevOps transformation. When it comes to quality, automating various functional checks increases confidence in the system’s expected behaviour. The time that automation saves us can be used to explore unexpected behaviours within it and look into ways to anticipate them better in the future. But the automation we build also needs to be of good quality. Having flaky tests that nobody trusts is something that anyone who has been bitten by it painfully knows.

Lean

Including Lean aspects to improve the quality of our product might appear obvious. For example, a reliable, time efficient, compliant Deployment Pipeline where everyone is responsible for having it in a good state to reduce handovers and "red tape" seems like a pretty good idea. But even if your team has mastered DevOps maestro levels, if your neighbouring teams still struggle with releasing their changes in good quality then the quality of the whole product suffers. The discussions need to focus on continuously improving the quality of the entire system and not just that of the individual parts if we want to remove bottlenecks and constraints.

Measurements

A common quality metric is the number of issues opened by the customers. But what about users that can't find the proper way to report a bug? What about those that instead of complaining just stop using a product? What if instead, we measured our users' satisfaction and the net promoter score they give to better understand the quality of our product? We can make a hypothesis of how we can improve, implement it and try asking again. And implementation doesn't necessarily mean building new features. Sometimes it is removing unnecessary functionality, sometimes it is renaming the buttons to something more meaningful. A small bug might be forgiven and not be considered a threat to the quality of a product but the inability to do the work you want on a constant basis might be a bigger problem.

Sharing knowledge seems to be an intuitively good practice, but implementing is not as straightforward as one might think. And that is because it implies investing time both for the side providing information as well as the one consuming it. For example, we can say that we share testing tasks. For that to become a factor of improving quality, testers need to take the time to show their team how to do it efficiently and the team needs to take the time to learn how to do it properly. Sharing is good to spark the flame for something new but to keep it burning the oxygen of time investment is needed.

So what is a Quality Strategy and how does it fit in DevOps environments? For me, in the end, CALMS is a Quality Strategy. It is a framework for improving the value for the end users of a product while optimising the process of creating it. This might not be a perfect definition or by any means a definitive one. But it is one that I can work with in the future.

Are there any programming languages that the commands are not in English?

Areti Panou — Sun, 19 Apr 2020 21:04:15 +0000

I am trying to put together a small presentation on how language affects software development. So I was wondering if there are any programming languages out there that have commands in any other language but English. Any input is more than welcome!

Some Ideas for Reducing "Release Decision" Time

Areti Panou — Sun, 02 Feb 2020 13:28:59 +0000

This was originally published on my blog, https://unremarkabletester.com/.

"Can we release this feature?" is usually a question answered by humans, not machines. From what I have seen around, even teams that practice continuous deployment seem to take a step back to consider whether they are ready to expose new functionality to their users. My impression is that "release decision" time might vary from a couple of hours to days or longer. Surely, a stable, meaningful deployment pipeline and a team's certain autonomy level are prerequisites to take a decision. But I was wondering, what other activities might influence such a decision and how we could reduce their time span?

Here is a list of the things I came up with.

Acceptance testing

Usually done by the product owner, it's a review whether the software produced meets the business expectations. Behaviour Driven Development (BDD) can reduce the time acceptance testing takes as it puts in place automated checks to cover that task. But even if you don't automate your specifications, just having a conversation as a team to get a clear understanding of the business' needs, produces software that requires less time to be verified before release.

Compliance validation

If you are working in a regulated industry, proof of compliance might be something that takes up a big chunk of your time before releasing. For checks that can be automated, a good idea is to include them in your deployment pipeline and automatically collect the produced artefacts, like reports of issues found. For things that cannot be fully automated, such as Accessibility aspects, raising awareness on the topic and educating the development team on good practices can improve the software quality without extended checks at the end.

Go-to-market activities

A new, prominent feature might affect marketing and user assistance aspects of your product. Pricing might change, new sales pitches might need to be created and some new documentation should help users in case they need it. To avoid surprises that cost time before release, it is a good idea to include technical writers and people from marketing or sales in the development process. They don't need to be in every meeting, but having an idea of how a feature is shaping up during development and working in parallel on their end to bring it to the customers, could reduce release decision time.

Exploratory testing

I have noticed many teams performing exploratory testing sessions, as a final check-point before releasing to their customers. Having a last look for risks that might threaten the quality of our work is a very human thing to do. On the other hand, waiting until the last moment to do such an evaluation might be too time consuming. By applying exploratory testing mindset throughout your development process, from specification of requirements, to API design and external services dependencies, you address potential risks earlier. So, when the release decision time comes, you already feel a certain level of confidence about the quality of your product.

I am sure that there are more "manual" activities we perform before we release our product and even more ways to reduce their duration. So the question that remains is, can we come up with an automated process to trim the release decision time to zero? And most importantly, do we really want to remove the decision from humans altogether?

Cover photo by Noah Silliman on Unsplash

Cheat-sheet for Laws, Principles & the such

Areti Panou — Thu, 14 Nov 2019 11:15:10 +0000

This was originally published on my blog, https://unremarkabletester.com/.

Have you ever been in a conversation where somebody ends an argument with something like "But as we all know this will never work because of Conway's Law"? And even worse, have you found yourself thoughtfully nodding even though you are not 100% sure what Conway's Law exactly says?

I for one admit to have been in such a situation so I thought of noting down some of the laws, principles, theories or what have you, I often hear referenced in software development discussions. I included only the definitions and leave it up to the readers to look deeper into each one of them.

Conway's Law

Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.

Occam's Razor Principle

Entities should not be multiplied without necessity.

Often paraphrased as:

The simplest solution is most likely the right one.

Halting Problem

The problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever.

Brook's Law

Adding human resources to a late software project makes it later.

Theory of Constraints

A methodology for identifying the most important limiting factor (i.e. constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor. In manufacturing, the constraint is often referred to as a bottleneck.

Pareto Principle

For many events, roughly 80% of the effects come from 20% of the causes.

Conjunction Fallacy aka Linda Problem

Assuming that specific conditions are more probable than a single general one.

This list is far from being complete, so any suggestions to enrich it are more than welcome.

Just quoting some of this wisdom won't get us very far. But maybe by taking another look to the truths we use, we can apply them better in the future.

Cover photo by Negative Space

A Collection of Suggestions I Strenuously Resisted

Areti Panou — Mon, 16 Sep 2019 11:06:05 +0000

This was originally published on my blog, https://unremarkabletester.com/.

As soon as I started working as a tester, I knew that this was what I wanted to do for the rest of my professional life. Being completely inexperienced in software development, my idea of testing was that its purpose was to find bugs. Oh and I loved finding bugs. Starting from gaps in the requirements, to functional bugs, to inaccuracies in the documentation, to missing identifiers of texts that needed to be translated, I was there, creating my bug tickets. Life was good.

But alas, my manager and senior developers thought that I could contribute more to the quality of the product by doing additional activities, beyond just finding my beloved bugs. Here is a collection of suggestions that I received, which I initially, emphatically, denied.

Provide test ideas to developers before they start coding

The architect of the project noticed that I could spot gaps in the user stories as soon as they came in the backlog. He suggested that I add my testing ideas in the story, so the developers could take care of the pitfalls before they even started coding. I was outraged! If I laid out all of my ideas, how would I find bugs? If they wrote good software, how would I ever be happy with no bug to be found? I even had the audacity of contradicting him. He smiled politely and let me sleep on it, until I came to my senses.

Share my knowledge with the rest of the team

Not only were the developers interested in having my test ideas beforehand, even worse, they wanted to know how I came to think about them. They wanted to learn how to do exploratory testing efficiently and I was supposed to be the one telling them all of the testing craft's secrets. I was not thrilled with the idea, nevertheless I paired with them for a couple of timed sessions and we found many issues together. We also discussed how a bug ticket should look like, so that it is easy for everyone to understand its importance and resolve it in a timely fashion. Eventually they became quite good at it, leaving me with even less bugs to find. At least, I had a hidden sense of pride for my "students".

Merge bugs and enhancements into a single list

Another outrage. My well thought of corner-case bugs in the same bucket as things like "change colour of button from #4286f4 to #2977f4". I half-heartedly accepted and agreed to have a look at these enhancements, reported by all sorts of people, from developers to sales colleagues. What I found out was that most of them were valid points that would significantly increase the good adoption of our product, sometimes with minimum effort. That gave me another perspective of how to approach testing, going beyond finding problems and looking into ways to actually improve our service.

Talk to people from sales

Another waste of my precious time. I knew what they would tell me. More features released faster, even if they were functionally incomplete, because this was what the customers wanted. In a nutshell, I thought that my job was to ensure that the customers got software that worked and not if what they got had any value to them (I wish I had come across Alberto Savoia's "Test is dead" presentation much earlier than I did). After the first discussions, I reluctantly started seeing the error of my ways. Even if I couldn't make any decisions on how features were prioritized, it sure made a difference to my testing approach, understanding what things the customers found important. What their resilience to failure was and how long they allowed for a fix. What their business was like and how our product could serve it. I swallowed my pride and admitted defeat yet again.

In all of the above cases, I embarrassed myself by either loudly refusing or grumpily accepting to even consider anything that was out of my testing comfort zone. Luckily, with approaches for creating quality software like Modern Testing becoming popular, most of the ideas I resisted are becoming mainstream. Will there be more things in the future that I will resist? Sure! Have I learned anything from my mistakes? I did. Developing software, and testing as part of it, is a creative process fulfilling the people that practice it. But if you don't share your craft with the rest of your team and don't listen to the people that consume your work, you will inevitably be left behind by both.

Cover image photo by Jon Tyson.

Learning a new programming language

Areti Panou — Mon, 16 Sep 2019 10:43:03 +0000

Code newbie question: How do you choose the language you want to learn to program in? Is there a course or resource that tells you what sort of problems are solved by each language?