On Some Things Quality Related
Through the eyes of the writer
You never heard of me before, as this is my first article that “saw the public light”. I don’t have years and years of experience on my shoulders, but I can give you my thoughts, my personal opinions, and it’s totally understandable if you don’t agree with something, or even anything.
I started my journey into software engineering as an Automation in Test Engineer, around 7 years ago, and at that stage I had no idea what a complex concept quality was. During Computer Science university courses, we kept learning basics of programming languages, OOP, logic, maths, but barely close to nothing about what it involved into a product lifecycle. How do you get from one idea into an entire product available to customers, with a whole system on its back to monitor and track the users behaviour, to learn from their journeys and add improvements to it? And where is quality standing in these workflows? When are you confident enough in its capabilities to say: “Yes, we can ship this. Customer can have it!”?
I’m writing this article and keep re-reading, re-editing and re-doing it. Every time, I keep adding something, a small improvement hopefully, but no one else had read it except myself. All I do is updating it all over again, but with no external feedback. So how can I know that my “product” meets its minimum level of quality? How can I know it meets your needs and expectations?
So, what is quality?
The most basic definition of quality can be identified as grading how good or bad something is. But that doesn’t necessarily mean that “your bad” is also “my bad” , or the other way around! Quality is a subjective attribute, with different meaning to different people.
Quality, in essence, is embedded in our everyday routine: we are looking to buy a new gadget, so we search reviews for different products to asses their quality before actually purchasing one. We read positives and improvement points for different brands until we have the confidence that one of them can actually meet our needs, our expectations. We are researching for our next holiday, so we browse countless websites and brochures until we find the one that fulfils our requirements. So our entire live is actually rolling around this concept of quality.
And this can be seen in product development as well. We make assumptions all the time related to what we think is right for the customers. But quality should mostly be seen through the eyes of the customer.
Software quality is defined as the level to which a system meets specified requirements or user needs and expectations. Testing has become an important segment in the software development process to ensure its quality.
One of the basic testing principle is related to verification vs validation. Verification is testing that your product meets the requirements written for the product: “Did we build what we said we would? Did we build the system right?”. Validation, on the other hand, tests how well you addressed the business needs that caused you to write those specifications: “Did we build what the customer actually needs? Did we build the right system?”.
Ever since the oldie, waterfall methodology, we understood that we didn’t actually provide quality services. We could work for a year on a new product; research done, implemented this awesome new idea; tested and validated it for a couple more weeks, and finally delivered it to our customers in a shiny new box with a red bow at the top; if the product is not fit for purpose for the customer needs, what can we do next? Can we say anything about the quality of that product? On one side, we verified it extensively during our (let’s say) 6-week window and reported appropriately, it met the requirements and we were highly confident in it! We build the system right, but coming back to the previous point, was it actually the right system? Even if the idea might’ve been validated initially, in the year of developing and making the product available to the customer, he might’ve changed their priorities, he realised that actually another thing is needed, another problem needs solving . So, providing quality enforces this idea of building the right system for the user. Feeding back to the customer more often was essential to understand if we’re providing quality services and eliminate waste.
And that’s one of the reasons why software development evolved into all the new different trends happening currently.
One definition proposed by Jez Humble is that DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.”. Continouous delivery concept is also seen as “the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.” The entire community understood that we can use different techniques, we can collaborate more and we can help each other to mitigate risks and get the confidence that we are delivering value to our customers, and all this through small incremental changes.
We are more focused now in working in cross-functional teams that broke down the silos and the fences, and we can give feedback as early as possible to improve the quality of the system. Just by asking questions when analysing a set of requirements challenges the group of thinking at different scenarios, improving collaboration between developers, testers, and operations. And how much does that cost? Nothing! We didn’t even start implementing it!
And quality doesn’t cover only the system anymore. It evolved as a whole new process, and we moved away from testing only roles, but to Quality Engineering ones. And as the Testing manifesto is stating, we are not focusing only in proving a level of confidence for the product anymore, but we actively collaborate towards:
- Testing throughout OVER testing at the end – As we’ve seen in so many examples and memories, the amount of waste increases exponentially if we leave the testing at the end of the product lifecycle. Instead, we should focus our efforts in testing early and testing often. And with the massive help of automated checks, it all comes back to fast feedback loop!
- Testing understanding OVER checking functionality – Similar as above, why waiting to get a new build to test and confirm behaviours, when some of the possible issues could be found in earlier stages? Shifting left the testing is a massive improvement to the overall quality of the system as it might raise questions in team’s understandings or even customer expectations. Building a common understating will automatically lead to improved quality.
- Preventing bugs OVER finding bugs – This is essential if we want to respond fast to our customer needs. We need to think more about the “life” after releasing to the customer. How can we prove it is actually working as expected and if anything happens, we can act fast?
- Building the system OVER breaking the system – We need to be proactive and work closely with the engineers, POs to identify what the customer actually wants. We need to steps into theirs shoes and help understanding the problems we are trying to solve for them and find the best solutions.
- Team responsibility for quality OVER tester responsibility – Every single team member is responsible for quality of the product we are building.
Testers do not provide assurance anymore; they help with analysis and feedback. With every engineer writing and running tests with their commits, they show ownership. With the whole team caring about the state of the system or of the build, they show ownership. With good monitoring and logging in place, the team then owns quality. Through a continuous-improvement mindset applied throughout the lifecycle of a system, we demonstrate that ownership of quality. And the truth is that shared ownership results in higher quality!
—
Photo by Brian Goff on Unsplash.