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

2010 - a full year in, "if testers are not involved early, we do not want to be involved later"

After being employed full-time for a year or so, we finally completed a full circle of releases, both the major releases involving a full scaled up beta/pilot program, and some minor releases, as this was taking place on a yearly basis. After each ended project, a small group of people from different teams formed a retrospective team, to go over what was done good and what could be done better next time, for all projects individually but also as a whole. This was before any agile methodologies were introduced. During the retrospective, or post-mortem analysis I think it was called at the time, we from the test team argued that we were not involved early enough and that we ended testing specifications that were well out of date due to our late involvement. This was taken into consideration and that from next phase we were to be included in all start up meetings, and walkthroughs of specification. It was an unwritten rule for a while, and when new projects started some of these meetings and discussions, they forgot about this agreement so it took some rounds before it was well established.

One of the drivers was that we took a stand and stated that "if testers are not involved early, we do not want to be involved later", meaning that the projects that did not include us from start did not get prioritized. We were not many testers, and could not cover all projects anyway, which meant the teams them selves needed to put in extra effort in some of the test phases. Even though the test role was new in the teams, my impression was that the effort done by the testers was very well appreciated and welcomed in the teams, as we brought in new ways of looking at the product we made. Forgetting the testers, were not an option after a few slip ups.

In late 2010, I was offered to take over as the manager for the test team, which I gladly accepted. At this time we were involved in the final walkthroughs of the specifications, and could give our input to what was missing or not making sense from a test perspective, improving the testability of the features and fixes to be implemented. Seldom, some of us were also invited to take part in technical specification reviews, which also proved to be quite useful as we could give our input to edge cases, which the developers took into consideration. The test team took over the overall internal beta, gathering what needed to be regression tested, as well as verify newly implemented features, coordinating and following this up with all the teams. In internal beta all teams, all roles, and even our support department were now involved in testing, so we unknowingly practiced the whole team approach in a way, before it was a thing.

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

2011 - moving into the teams, and going Agile
 
We were now closer to the development teams than ever, even though we were a separate team on the organization chart, we always split up when projects were to start, and took part as members of the teams, until the project ended after a release at the end of the development life cycle. This meant that we always were invited to everything that the rest of the team were invited to, and participated in all team activities.

At this time we also started to try out Agile development, Scrum, on some projects, and even though it was not a very smooth transition, reluctantly falling back to some sort of water-scrum-fall, we became better at it. Scrum suited us testers quite well in many ways, as we could focus on specific items that were to be implemented in matter of days/weeks, and then test them along the way, and also having 1-2 "test days" before end of bi-weekly sprints. However we struggled a bit to keep up with development in the beginning, sometimes hanging a sprint behind, and testing/verifying what was already done. We also struggled with agreeing on what needed to be done, for example someone wrote a user story assuming that "abc" should be implemented, the developer assumed only "ab" needed to be implemented, and the tester checked for "acd", so we were always returning to fix the misunderstood parts. This lead us to start using definition of done, trying to discuss and agree upon each case before we committed to it, but in the beginning not all significant roles were involved in this discussion, leading to additional rounds before we were satisfied with the level of revealing the hidden assumptions and adapting the "3 amigos approach" - even though we did not have a name for it at that time.

At this point we also got our selves involved in the business case / mandate specifications, and were discussing these before they were approved on a regular basis, before they were taken into consideration to become a project.

The test team were always very open minded, and eager to learn more about how we could improve our software development and testing cycles. After each major/minor release we broke out from the development teams, and back to the test team, where we discussed what went well and not so well in the different projects, learning from each other, and tried, in the next rounds, to implement the improvements that we learned from each other into the different projects.

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

2012/2013 - shifting right to complete the cycle

At this time we were involved as early in the process as possible, but still did not have insights in what was happening in production environments, so we focused to shift right, to monitoring in production.

When not working together with the development teams, we were seated by the team responsible for the entire platform, which meant that when something were down we were the first to know, and could help out in critical situations in analyzing and finding the root causes as quickly as possible. Gaining insights into the production environment gave us even more knowledge on how our application behaved in real life scenarios, what our customers struggled with or used most. Learning this helped us to improve our test scenarios, and prioritization of our testing effort.

We continuously tried to improve our processes, and pushed testing as much as possible in different arenas, whether it was through presentations to the entire department, or only in the teams through pairing up with developers, testing together with managers or other roles. We matured in our practical use of agile methodology, took on more responsibility and tried to utilize more tools in order to speed up our processes. One particular improvement that we did together with the development teams were to establish common quality checkpoints for all projects,  which needed to be fulfilled before the projects were "allowed" to be part of the internal beta, which meant that if the project failed to fulfill these they were not part of the next major release.

Our release cycle went from releasing 1-2 times a year, to at least 4 times a year, which meant 2 major releases and 2 minor releases. Our patch releases went also down to almost zero, and with much bias I'd like to think that is due to our quality improved. This can, of course, not be verified objectively.

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

In our context on how we developed software from 2007 - 2013, we managed to push the testers from just working on checking bug fixes, and testing according to old specifications, to being a fully pledged member and an important role in the development cycle, getting involved from when the business cases were written to the changes were in production, monitoring the changes and verifying how they impact our customers. It was a great experience, and very much fun to be part of this transformation.

2014 - 2017 - shifting personally, leaving the team and focusing on other projects and products

In 2014 I was reallocated to another product, and took on other responsibilities (still related to testing). The project continued to develop, and the team is now for example able to deploy the on-demand parts of the application when needed decoupled from other parts of the application, and on-premise part at the same pace.

I continued to work on improving the test processes and taking part in testing other products, working with automation and new technologies. In these years, and today, we moved towards Continuous Delivery, Deployment and DevOps, having a number of teams that are able to deploy changes when needed. Testing done in these teams vary depending on their application being made, architecture, technology used, and development methodology, but the main principles are the same when it comes to involvement of testers. We are involved in the business cases, defining and grooming the users stories/tasks, team agreeing on items to be worked on, testing as early as possible, and pushing the changes through the delivery pipeline towards production. Testers are today part of autonomous teams who have full responsibility for their applications, meaning that they all are involved from the defining the tasks to monitoring behavior in production. Checking and testing is done from the first line is changed in the code, through series of automated analysis, unit, integration, UI, e2e tests, with exploratory testing as well, and alerts from monitoring on miscellaneous aspects.

20xx - Where to shift next?
So where to shift next after this? I will share my thoughts on this matter in the next and last part of this series.

If  you missed the first part, you can find it here - "Shifting left, shifting right - where to shift next? - part 1".