Shifting left, shifting right - where to shift next? - part 1

Today it is almost unthinkable, with the teams that I work with every day (read - in my context), that some team members inside a software delivery team are not involved in almost every phase of the software development life cycle. Looking back some years ago it was certainly not like that, specially for testers. In this, and the coming posts I will share some of my experiences and thoughts on this subject as well as what I believe where we should shift in the future;  left, right, or even more left, and right...

2007 - The first experiences, part-time tester, waterfall

I started to work with software testing in 2007, as many of us in the field, by chance as a part time tester. At this point the company that I worked for did not have any full time dedicated testers, only a team of part time testers who rotated, and worked at least 2 days a week. The team consisted of students studying economics or computer science at master level, who could work at any time of the day/night, as long as we overlapped at least 2 hours each day with rest of the teams. We were located on a separate floor, than the rest of the development teams, with a full time employed test manager who made sure that we were busy. Needless to mention, the development was in waterfall style, and if I remember correctly we delivered new versions of the software 2 times a year, with additional 1-4 patches that needed to be rolled out at various points due to bugs found after release.

We who were employed in the part time test team, tested according to written specification, explored the software for any obvious issues, received builds and verified reported bugs when fixed by developers, so at this stage we were involved at the very last stage of the development cycle. We did not have that much contact with the development team, so testing or checking according to specs was tedious, not to mention almost half of the specifications were wrong, or so we thought. When we reported those issues, they were closed immediately since the specification actually changed in the mean time, and implemented in another way, so it was actually the specification that were wrong, but just not up to date. Imagine the time wasted on this, both by the testers and the development team who needed to read those.

The development life cycle for a major version looked like this, very quickly explained and we were only involved in the very last part:

• Business case or a mandate - 1-2 pages description of the project, goals and priorities
• Functional specification - long documents describing in detail the functionality to implement
• Technical specification - describing how it was to be implemented on a technical level
• Implementation - the actual coding and configuration
• Testing - checking and verification of the implementation
• Internal Beta - gathering all the sub-projects into a final build, merging and testing product as one
• External Beta - first release to a small number of volunteer customers
• Release Candidate - a build of the product that needed to survive a week before final release
  
• Release to all customers - final release

2009 - Full time employment, waterfall

In 2009, as we were finishing our master degrees, some of us were employed as full time testers, we also got other colleagues that were employed as full time testers from other companies, and moved to the same floor as the development teams. We were organized as an individual team, test team, but took part in other teams depending on the need, and importance of the project. Still some projects did not have dedicated testers. Now we at least could interact with the developers, managers and other roles on a daily basis, also when testing according to the specifications, it was easier to get hold of those who wrote and approved them so the feedback loop was shorter.

In the beginning, we were still only involved in the same parts as before, but gradually moved to be involved in Internal beta testing, where we merged all the projects from the teams, and started to sew these projects to form a common product, that could be tested as a whole. We also began to get in touch with beta customers, through the external beta program, and helped these throughout the beta period, which lasted for 4-6 weeks. When the versions that external customers proved to be stable enough, we marked these as release candidate and these versions were rolled out to the final external beta group and needed to survive for at least a week, meaning no high or critical issues reported by the beta customers, or anyone internally, before it was released. So in this case we shifted a bit left, and got our selves involved a bit earlier in the process, as well shifted right, to get involved in the external beta program.

• Business case
• Mandate
• Functional specification
• Technical specification
• Implementation
• Testing
• Internal Beta
• External Beta
• Release Candidate
• Release to all customers

The issues that we still struggled with was that we were served with a finalized and approved functional specification, which was difficult to change, since the technical specification built upon it, and parts were already implemented as specified. We who had our "tester goggles" on found issues, or asked questions that were not specified in the specifications, which meant these were implemented by developers according their own assumptions, since they were not specified and agreed upon. A good example of this were edge or absolute values, how young or old a person could be when registered in the system, start and end dates or other edge or absolute values like minimum or maximum numbers of characters. These were things that naturally I as a tester needed to know in order to check and verify these, but something that the ones who wrote the mandate, functional and technical specifications, at that time, did not had in mind. Many bugs that we found at this point, were due to assumptions made in several stages of the development process, as well as that we spent a long time in each stage of the process (meaning weeks and months), which meant going back and making changes was expensive.

In this part, part 1, I've briefly touched upon how and where we were involved in the software development life cycle at the start of my career, when waterfall methods still were mainstream, 

In the coming part/parts, I will continue to share my experiences on how we got our selves involved earlier in the development process, all the way to the approval of the business case document, and also my thoughts on where we should shift to next.