Where are the testers on the spectrum?

There is a term that is being bandied about called ‘Shift Left’ in software testing. The waterfall method of software development had a “waterfall” of product development activities, where, if you start from the left of a drawing board, you go from gathering requirements up to operations and production support, from left to right. This created a step ladder of activities where testing was placed/done towards the far right of the waterfall or ladder.

Apparently, this was actually not the norm when software development as a field started out , and people (programmers) in fact tested from the onset. Creation of independent test teams led to the time lag between programming and testing, and I have been on projects where each activity was a separate event done by teams that rarely communicated informally. But I have also been on independent test projects where we were given information about the development sooner (sometimes starting with requirements gathering documents) and hence were able to “test” earlier. This was sometimes the case if the testing team had a free schedule, and did not have any other projects on hand that needed their immediate attention. But being an independent tester still created barriers and hierarchies of when and whom we can interact with, to get a glimpse of the product development process and thus be able to provide testing feedback on it.

It was much easier to have that fluid interaction when working on actual product teams composed of all sorts of roles, programmers, product owners, build engineers, etc. In fact I had instances where I gained a lot of insight into a product just by talking to the technical writers on my teams.

So Shift Left is an idea where we start testing in the earlier stages of product development . Agile teams do this. Being a purely independent tester does help with subjectivity and in providing the much needed impartial eye on the product. But it creates lag at specific points in time at which testing is actually done. And this also situates testers in some imaginary far away space where they have to be handed over an almost finished product.

As a tester on traditional teams, I have spent a lot of time waiting for things to be handed over. In agile or the shift left situation, or even just in teams that bring together all sorts of roles in all stages of the product development, this waiting to be rescued (I mean, the waiting to be handed over a piece of the application) time period can be avoided. Instead, as a tester, I get to go to sessions where everyone is talking about how the end product will look like, and I can then give inputs into that particular stage of the software development life cycle.

There is an increasing trend of eliminating most roles in software engineering and hoping that developers (or rather programmers) will pick up the slack and be able to become the jack of all trades. There is a reason why all these trades exist. The focus on composing a team with only coders assumes that programming is the only activity needed for software engineering. Instead, to build a product that people will actually use, we need many different people with varied skill sets; those who can visualize what it should look like, those who like to talk to end users, those who can imagine the larger systems that the proposed solution needs to integrate with, those who can identify problems and risks, and of course those who can translate these human ideas into virtual code. I am not harping on the outdated notion that different sets of roles can only do specific activities in a software project. (Of course, people in software engineering should try to move across skill areas if possible.) I am saying that we still need diverse knowledge to successfully build a usable and liked product. Otherwise imagine building a home by only hiring drilling machine operators to do all the work from start to finish.

I started writing this when I came across an article on shifting left in testing. But the writing is now morphed into a tirade about elimination of multiple roles in software engineering. The fact is that we mostly work with virtual systems that usually do not have a physical aspect to them. So it is hard to sometimes visualize an end product, like we could visualize a physical product in a civil engineering project. Every role in software engineering finally comes back to the computer code, and all of us should have an insight into how code works. But what we are doing today is building automated processes to wrap the knowledge that is contained in requirements analysis, systems operations, testing, and even programming, and moving them into automated systems. Surely this creates economies of time and effort, yet is limited to what knowledge has been encoded in that automation. A human on the other hand, who might be involved in requirements analysis for example, can expand so much more and come up with many more scenarios and risks that an automated process cannot really come up with. So to eliminate all these roles with the assumption that a process (encoded in an automation tool) can replace human thinking is simplistic.

To get back to the original thought, shifting left is an idea, where people in all sorts of roles start talking about and gain insight into and provide feedback into the software engineering process all throughout the process, not just at designated stages. Here the analogy of civil engineering may not work, as I doubt that the drilling machine operators are called upon to provide feedback on the building blueprint. In software engineering, we should perhaps celebrate the democracy that code offers us, and let in all sorts of knowledge into the process of how we set about creating a virtual product.