Gone are the days when a software developer could toss features “over the wall” to let them tester savages have at it. This often led to an adversarial relationship and a great deal of highly unproductive ping pong back and forth about the validity of these allegations. Things are moving far too fast these days, and in most cases the concept of a separate test team has gone the way of the dodo.
A specialized test team was a bad idea then and a really bad idea now that things are moving so much faster than ever before. The more modern mindset is that of a flow-based system where a beautiful piece of code did its magic and was flawlessly deployed to production with no delay or deleterious side effects.
Early on during the initial “shift-left” movement developers were resistant to being more responsible for the quality associated with the code they delivered. Their art was hidden in the details buried in the code. No matter how elegant the code may have been there was always a “safety net” team that was devoted to validating the interpretation and implementation was correctly in line with reasonable customer expectations.
As a recovering tester I despised the sloppy devs that could not be bothered to pay attention to the intent. They often delivered garbage that I could find countless problems with. In turn the devs despised me for being gifted in representing the will of the customer and in many ways making them look bad while saving their bacon. It was not a healthy existence.
These days and more often than not devs get it that if they are involved with a competitive company that needs to release features frequently and with high quality that they need to own. Not some part of it but all of it soup to nuts as they say. Design it, build it, review it, document it and yes test it ensure that it not only does what it should but does not break something else in some unforeseeable way.
Enter agile, Test-driven development (TDD), unit testing and pair-programming or mob programming. None of this is new but more and more teams are reaping the benefits that this all has regarding the flow of features to customers. We will explain these in more detail later – for now know that if you are not doing these things to build in quality at the source then you will someday be crippled with technical debt to make it right.
In the agile universe you need a closer connection with the customers that you are working for. It is critical that you have the means to hear their feedback which can shape the direction of what you are doing next and thus deprioritize the things that may not matter to them.
Devops concepts made it possible to move even faster through streamlined releases and automated processes reducing time and risk.
Beyond that value stream management came along and pushed us even faster with a data driven perception that reflected the flow of value. With this new vision business leaders were equipped to make real time data driven decisions without complex reporting or disruption to the people that needed to focus on doing what they do best.