Crafting Quality Software
Tarcio Saraiva and Adam Crough talked about crafting quality software at the 1st Conference in Melbourne, Australia. InfoQ asked them to share their views on what software quality is, and to explain the business benefits that quality can bring and how it can be managed. InfoQ also asked them about the role for testing when it comes to delivering quality software, how continuous integration supports quality, and asked them for advice for organisations that want to deliver high quality software products.
InfoQ: Can you share your view on what software quality is?
Saraiva: It’s a conceptual goal that will help the team pave a path towards a better product with less bugs, better functionality and easy to understand code. This path can be observed from an internal point of view - e.g. developers - and from an external point of view - e.g. end users - and both groups perceive quality in different ways. The challenge is to ensure that they don’t compromise one another.
Crough: In its simplest form, quality could even be defined as how good or bad something is. The subjective nature of its definition suggests that individual perception plays a part in identifying what quality is.
It is important to acknowledge individual goals when trying to find consensus on what constitutes quality software. A developer might look at the code base and admired its maintainability or an end user may be satisfied because they can store all their favourite music on one portable device.
InfoQ: In your experience why do organisations choose for quality, what are the business benefits that quality brings to them?
Saraiva: Quality brings a controlled ability for the organisation to plan ahead and implement enhancements that will provide value to the business. With a proper process in place to build quality software it’s easier to enable the business to evolve and change, as well as enable the team to adopt emerging strategies and technologies.
As a developer I see new tech and methodologies coming in very often. At DiUS we are constantly talking about what’s new and ways we could bring them to a project. That’s why quality is important for us: bringing those values to our clients will also help educate them when it comes to being pragmatic and moving quickly to evolve organisations.
Crough: Return on investment, robustness, reliability, reduced time to market, increased customer satisfaction are all by-products of investing in and managing quality. They are all important attributes for organisations to pursue when developing software. On a more personal level I think the pursuit of quality and providing satisfaction to others are innate attributes we all individually possess at varying levels. In this sense the benefit to organisations is two-fold.
Firstly, to work in an environment/culture where members of software teams can aspire towards a standard that can not only be met but encouraged to be exceeded is empowering. Secondly, the knowledge that individuals and teams are developing products that provide fitness for use and satisfaction to customers is an enviable position.
InfoQ: Sometimes organisations use terms like "quality assurance" or "quality control". Do you think that quality can be managed?
Saraiva: I believe quality can be measured and that will lead to actions that could be called management. Visibility from Continuous Integration will tell the team if something is wrong - e.g. number of test cases dropping. This visibility will prompt an action by the team to talk about the problem, understand the cause and apply a fix.
In my experience, self-managed teams provide the business excellent input on how quality can be managed by adopting tools and techniques that will empower the team to achieve excellence. In turn, businesses get the opportunity to explore new avenues on how to manage their own quality from techniques implemented internally.
Crough: As I mentioned earlier, quality can be considered somewhat subjective, but this doesn’t imply it can’t be managed or that consensus can’t be reached.
In software development, quality assurance and quality control are often used interchangeably. In an overall sense they form part of quality management but play a distinct role. In short, quality assurance could be considered as a strategy of prevention and quality control a strategy of detection. Self-managed teams, iterative development cycles and a drive for continuous improvement are all techniques and/or processes available to manage quality in an agile project.
InfoQ: Can you elaborate about the role that you see for testing when it comes to delivering quality software?
Saraiva: Testing has shifted from a "handover to testing" approach to a "let’s test this" approach over the last couple of years. This change consequently lead to a "how can I do this better" mindset.
Test-driven development as a software practice is great for that because it makes you challenge your design decisions leading to better written software. Combine it with pairing and things get more interesting because you are sharing ideas and expanding on the understanding of the problem to achieve the best possible solution.
Exploratory testing is another practice I’ve seen taking shape recently: it provides the team the ability to exercise unusual paths in a feature or user flow that would not be typically captured by the automated testing suite.
Simply put, testing provides confidence. It’s a set of practices that will enable the organisation to move forward.
Crough: From the moment that an idea or concept is identified, testing should be part of the dialogue. The testing of an idea helps to gain insight into determining whether it will be desired by people, feasible to produce and viable for the business to do so. Lightweight forms of testing can be done by talking to new or existing customers, sketching ideas on paper can be a mean of validating concepts and driving innovation.
Whilst testing responsibility plays a critical part of the development team’s day to day activity, allowing for and encouraging end user testing is also important in determining whether the software’s quality is fit for use. An end user will do things with your software that your and your team may not have considered. Getting software into the hands of your end users as early as possible is a great way to test what has been built.
InfoQ: Do you have examples showing how continuous integration support quality?
Saraiva: On my current project we are applying Continuous Deployment with zero downtime. This is only possible because of Continuous Integration.
The "development cycle" - push, build, report - is important because it gives us the confidence that our structural and functional quality is correct but the real benefit behind Continuous Integration is that it helps expand the team’s practices and evolve the organisation by being a "robot" that opens doors to modern practices.
Crough: As a part of the development process, Continuous Integration provides confidence in ensuring that each check-in done by a developer is verified by an automated build, allowing teams to detect problems early.
This gives confidence to not only the development team, but also to business/product owners that the software being developed is adhering to a standard that is continuously being examined. It also provides scope to continuously improve the process through constant examination.
InfoQ: If an organisation wants to deliver high quality software products, which advice do you want to give to them?
Saraiva: There is no silver bullet for quality. What has worked for us in the past is working with organisations to build quality from inside out but look for feedback from the outside in. Embrace change, constantly challenge the way things get done and bring the team along for the ride.
Crough: Externally, understand who your customer is, listen to them and appreciate what value your product will or currently provides them.
Internally, allow your organisation to value the shared vision with your customers. Be willing to experiment and build a culture where a fear of failure isn’t detrimental to individuals or teams but is viewed as an opportunity to learn. Listen to and collaborate with your development teams.