You never heard of me before, as this is my first article that saw the public light. I do not have years and years of experience on my shoulders, but I can give you my thoughts, my personal opinions, and it is totally understandable if you do not agree with something, or even any of this.
I started my journey into software engineering as an Automation in Test Engineer, around 7 years ago. 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? How does one monitor and track the users’ behaviour, to learn from their journeys and add improvements to the product? And where is quality standing in these workflows? When are you confident enough to say: “Yes, we can ship this. Customer can have it!”
I am 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 does not 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 evaluate 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 happen in product development, as well. We make assumptions all the time related to what we think is right for the users. 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 versus 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?”
On Delivering Quality
Ever since the oldie, waterfall methodology, we understood that we did not actually provide quality services. We could work for a year on a new product; doing our research, implementing this awesome new idea. Then testing and validating it for a couple more weeks, and finally delivering 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 us say) 6-week window and reported appropriately that it met the requirements, and we were highly confident in it. We built the system right, but coming back to the previous point, was it actually the right system to build? Even if the idea might have been validated initially, in the year of developing and making the product available to the customer, they might have changed their priorities, realising that they actually needed something else, or that their problem was different. 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 were providing quality services and eliminating waste.
And that is one of the reasons why software development evolved, into all the new different trends currently happening.
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.” Continuous delivery 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. We can give feedback as early as possible to improve the quality of the system. Just by asking questions during requirements analysis, we challenge the group to think about different scenarios, improving collaboration between developers, testers, and operations. And how much does that cost? Nothing! We did not even start implementing it!
On The Testing Manifesto
Quality does not cover only the system anymore. It evolved as a whole new process. We moved away from testing only roles, but to Quality Engineering ones. 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 have 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. When every engineer writes and runs tests with their commits, they show ownership. If the whole team cares about the state of the system or the build, they show ownership. When good monitoring and logging is in place, the team 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!