Ok, I hereby confess that the last talk was a hard one to wrap my head around so I'm looking forward to getting my head back on straight. Here's hoping this talk helps to do that (btw, just kidding about the last talk but I confess I've never considered floating point in depth in such a manner ever).
Our closing keynote tonight is the evolution of modern Quality Engineering. To understand where software quality is heading in the future, it helps to understand what we thought of Quality Engineering in the past.
It certainly seems that the conversation of Quality is circular. Many of the ideas of people like Deming and his points through to Margaret Hamilton and Glenford Myers. Somehow, the idea of testing being removed from development as a standalone discipline, and now we seem to be working to merge testing back into more traditional quality standards. the problem with having a dedicated tester (and so many of them for specific issues) that we created and refined the role of the tester to be at the tail end of the quality process. This reminds me of the space of testers in the early 1990s and how many there were vs the latter part of the 1990s and how many software testers there were and that specific separate group.
Granted, I can only talk about the Cisco Systems approach in the 1990s as it was the only tech company I worked for at that point in time. Early in the days of Cisco, the software testers were not a dedicated group. Everyone who was a tester did something else in addition (my early testing years also included me being a Lab Administrator). I didn't get designated a Test Engineer proper until 1994 and that was when many others became branded as testers in a software sense and that being the core purpose for our work.
I've also seen that there does seem to be a divorce between the idea of building in quality upfront, and that there seemed to be a reliance on testers being the main line of defense for bugs. I remember that attitude and approach well, and in many ways, it is still that way. Ideally, we need to create Quality as a process at all levels. we need quality all the way at the very beginning of the story workshop that proposes a new feature. It needs to carry over through development, through having everyone at every level associated with quality and making it a core part of what they do.
To be clear, I'm not saying people go out of their way to not deliver a quality product, just that our practices tend to make that approach harder than it really needs to be. It's interesting how shifting the word Test to Quality changes the whole conversation.
Cool, so what is a Quality Engineer, how do we become one? we would need a range of skills that are functional, technical, and consulting related, to be able to work effectively with a number of groups, not just our own and not just related to testing. they need to be effective in methods, techniques, tools, and approaches that allow them to be effective in a variety of areas. A Quality Engineer also needs to beef up skills in technical areas, specifically coding.
The fact is a large percentage of projects fail, badly enough to threaten a company's existence. A poor scope on requirements and quality overall ranks high in the reasons for this. There are a lot of techniques that can be used to help mitigate these failures. To reduce the overall cost of quality, it would be much more helpful to focus our energies early in the process, and let's stop the idea of testing at the late stage of development. Move the testing further back in the process and make quality the most important discipline in all groups as far back as possible.
No comments:
Post a Comment