The world is going mad for digital transformation. Organisations that historically have little experience in software development are now building self-service apps and digitised services — ranging from banking and financial services, to apps for digital TV, ordering dinner, providing metrics on your golf swing, storing your drivers licence and even allowing you to use the lift at work.
It is clear that Marc Andressen’s “software is eating the world” quote from 2011 has come to pass. The big problem however, is the quality of much of that software.
Poor quality software = brand and reputation damage
High-quality software is sadly now the exception rather than the rule, as anyone who interacts with just about any Government, utility or telco-built web portal or mobile app can tell you.
The ability to build high-quality applications represents a major competitive advantage and could well be the difference between winning or losing in your market.
There are countless examples of customer focussed startups whose high-quality, beautifully designed software with frictionless user experiences are seriously threatening — or even overtaking — the once unassailable incumbents.
In the digital economy, your software is your competitive advantage
What is the secret to building high-quality software at high-velocity?
Enter Quality Engineering (QE), a relatively new and evolving discipline that encompasses a multitude of technical and soft skills. QEs are key in the improvement of quality, speeding up development time, and shipping better products, more consistently.
Some of the most technically progressive companies in the world are now embracing Quality Engineering. In Australia, the market is frothy with organisations such as Canva, Atlassian, SafetyCulture, Qantas, Xero, Vodafone TPG, ING, CBA, WooliesX (and many more) all competing for very limited available talent.
At the most basic level, increasing the quality of software means reducing the number of defects in both the software itself and in the processes that are used to develop, release and maintain it. In practice, a whole host of disciplines must be brought together to solve what can be complex technological, process and people problems.
Quality Engineering further entrenches the “Shift-Left” mantra of teams practicing DevOps the world over. Attention to quality should be paid not towards the end of the software development lifecycle (SDLC) as it is with the traditional Quality Assurance approach; rather, quality should be built into the entire process starting with the project’s earliest stages of conceptualisation and development.
The trade-off used to be Quality vs Speed. Now you can have Quality at Speed.
Traditionally, it was true that increasing the quality of your software came at the cost of slowing down velocity. The Quality Assurance (QA) function was considered a separate team, bolted onto the end of the development process and perceived by many to be standing in the way of the software’s release and slowing everything down.
However, thanks to new approaches, and perhaps counter-intuitively, the reverse is now true for the Quality function. Adopting Quality Engineering and embedding quality into a software project right from its inception actually helps to increase your velocity. It brings about about shorter development cycles, increased automation, faster releases and the earlier detection of bugs. How is this so? Let me introduce the Quality Engineer.
The Software Quality Engineer
The Quality Engineer (SQE or QE) is a very different beast to the Quality Assurance Analyst/Engineer.
Quality Engineers provide software teams with quality assistance, define and improve processes, identify and mitigate risks & implement tooling and automation solutions. Instead of performing manual tests and writing automated tests, QEs look at the bigger picture and find the best solutions to improve the quality of products while helping improve development speed.
Typically possessing a strong background in software engineering and test automation, QEs are native Agilists. Born in the cloud, they can provide insight into the testing of distributed systems and microservices. They are highly experienced in the application of both functional and non-functional (e.g. performance) testing and possess a deep understanding of quality attributes throughout the SDLC.
QEs promote CI/CD best practices. They’re able to contribute to the design of monitoring and observability systems for apps in production and are students of Lean engineering — looking to reduce waste wherever they can (such as engineering processes or tooling) to improve efficiency and quality.
Most importantly, QE’s foster a culture of quality within an organisation.
What kind of things do QEs do day-to-day? Here’s an example:
- Creating services that monitor for risky coding patterns, and providing insights to the developer before merging their work to master
- Convincing a team to architect their code in a different way to make it more testable
- Pairing with developers to train them on efficient testing techniques (including exploratory testing)
- Augmenting a team’s build pipeline with the right environment to test platform changes
- Analysing incidents to identify the optimal point to prevent reoccurrences in the future
- Building a heat map of the complete picture of performance testing results against certain product offerings
- Analysing automation coverage to find the most valuable area to focus on
As you can see, the Software Quality Engineer’s responsibilities are very different to that of your typical software engineer.
What is the CSQE?
At the time of writing, the ASQ’s rigorous professional industry certification, the “Certified Software Quality Engineer” or “CSQE” is the only widely-accepted accreditation on offer. The CSQE posits that software quality improvements for a business are driven through the application of knowledge across the following six domains:
Obtaining your CSQE is no easy feat. Aspiring engineers must have a minimum of eight years experience in at least one of the fields listed above, and at least three years of this must be in a leadership position. The CSQE exam itself runs for nearly five(!?) hours with a passing score of 75%.
And given the industry’s mantra for continuous improvement, things are moving so quickly that its necessary to re-certify every three years.
The six core disciplines that must be mastered to become a CSQE are as follows:
1. Software Quality Management
This relates to quality management leadership skills, extending to strategy, planning, oversight and the fostering of a quality culture within an organisation.
2. Software Quality Engineering
This covers the activities required to define, plan and implement a software quality management system, including the continuous improvement of systems, policies, processes and work instructions.
3. Software Quality Assurance
This relates to the activities performed to ensure that the software is being built to quality standards and that the organisation’s Quality Management System is sufficient to meet quality goals and objectives.
4. Software Quality Control
This is the set of activities needed to monitor and measure software projects and processes to ensure that unwanted variations aren’t introducing problems into the system.
5. Software Verification and Validation
This is to ensure that the software being built meets the specified requirements and intended use. To quote Wikipedia — “In simple terms, software verification is: “Assuming we should build X, does our software achieve its goals without any bugs or gaps?” On the other hand, software validation is: “Was X what we should have built? Does X meet the high level requirements?”
6. Soft Skills
Soft skills help a SQE to be more effective at influencing others in the team towards quality. Leadership, team building, facilitation, communication, conflict resolution and negotiation skills all form part of a Software Quality Engineer’s toolkit and are critical to effect the necessary organisational change.
Do you agree? What does a Software Quality Engineer look like to you? Please let me know in the comments.