Change control and testing. Can we really control the changes?

In this article we will delve into the diverse range of  changes that could affect our projects, sources, motivations, how they impact our testing and some tips to cope with them.

In general, we are always afraid of changes. Most of the time we would like our environment to continue the same: not having to touch that code that was so painful to program, that test that finally worked as expected after struggling with, etc.

The key point here is that a change does not have to be negative. In fact, it brings us some valuable skills because:

• it guides us to adapt to a very competitive market
• it helps us to grow and acquire some seniority
• it allows us to incorporate lessons learned and be able to foresee next time.

What we need to accomplish then, is to be able to manage those changes, adapting our processes and ways of work, assuring that we can deliver our product while maintaining its value. I’m going to focus my speech here, identifying changes and being prepared to face them.

Sources of changes

It’s important to realize that there are many sources of change, some are generated from outside of the project (external) and some of them emerge internally within the project itself.

External Changes refer to those originating from stakeholders and other entities beyond the core project team. For example:

• New government regulations that should meet a certain date or face severe penalties. 
• A change in the strategy of  the organization we work for.
• New corporate leadership that has a different vision/strategy that affects our budget or scopes.
• Redundancy, sad but true…
• A competitor beating us with a new product with more features at a lower cost.

In those cases, the control that we have over the changes will be very little and we will need to manage it and learn how to adapt to them quickly.

Internal changes emerge from core project team members. We can think on the following examples:

• Suggested changes by team members or the company to improve functionality. A recent experience about this, when a client I worked with changed from 2-weekly releases to Kanban releases per demand as an approach to improve our times in delivering features, forced us to adapt our entire workflow across various squads with different microservices and it took a lot of effort before being ready to accomplish it.
• Detecting bugs in production (yes, we should see that come before production but you and I know that sometimes happens…). On one Thursday night, with the  team I lead as a QA, we had to deal with a bug in production because an unexpected change from a third party broke our workflow, so our whole Friday consisted on finding the exact fail, contacting with the other company and trying to fix it together while managing other production issues unrelated to us. Design defects or forgotten requirements force you to go back, redesign part of the solution and test again the whole  product.
• Team members leaving the company or 
• having an unexpected medical leave. 

These situations may involve the reorganization of the tasks for the next sprint because we are not going to be able to deliver all we planned or maybe we just lost the person that had more experience in some of our services.

Sometimes we have a little control over these changes, but others , we do not and they could generate significant chaos on a project if they occur without previous warning. 

And of course, all these changes will impact our testing in one way or another because testing is a process that runs through the entire Software Development Life Cycle.

As we can see in this picture the Agile life cycle can be implemented faster and easier than in the waterfall one. But why? In Agile, teams break down deliverables into smaller pieces. As a release is where the users or client will see the changes that are being made, and they can take only 2 weeks;  the priorities can be reordered during the refinement/planning and the change would be introduced faster in the next sprint (if necessary, and if the time to develop it and test it makes it possible).

As one of the values of the Agile Manifesto [1] says: “Responding to changeover following a plan.” Therefore, Agile in itself is the knowledge to formulate and respond to changes, and a process of dealing with an unpredictable and uncontrolled environment.

Years ago, I worked with classic methodologies and I can assure you that a change can significantly change a project’s scope. During my time as a project manager I have seen how even a minor change could generate a considerable amount of documentation, not to mention the meetings and meetings with different areas to convince the team that no matter how much they didn’t like the change, it had to be done. 

When I moved to the quality side , a change in the middle of the project was something to go crazy about  and ironically, I was on the other side complaining to the project manager about the challenges presented by these changes without success, of course.

Changes and testing

Talking about quality assurance, let’s see how the process of testing is affected by the changes that you find. They depend on multiple factors:

• The development model of your organization no matter if there  is a  small company or a big one where the different areas are not in direct contact with each other
• The type of product that you are developing or the final client that will use it, in case of a mainstream software. *Anecdote alert!* In my early days working as a contractor for a government agency I spotted some typo errors in the texts or messages.  I complained about the UX (user experience) because I came from working on applications that the general public had access to and they could add a very bad review for something like that, but as the software that we were deploying was for internal use (although it reached a whole country) those things weren’t really important (comparing with the tight deadlines, security concerns and complexity of the workflows that we needed to accomplish). The user experience wasn’t ever important because they will receive a course to learn how to use such applications. So the testing should be focused on the safety of access to data or the workflow itself, no time for “little” things. What I want to stand out with this idea  is that there is a big difference in testing according to the product we have in hand.
• Test levels: component testing, integration testing, system testing, acceptance testing could all be affected by changes, but we have to be sure and repeat our testing for all levels.
• Project Methodologies: old-school approaches are not the  same as agile methodologies. Having worked with both of them, I can highlight and understand the differences which makes me personally choose the agile methodology. I’m always picking up a lot of lessons learned from it. 
• Operational constraints:
  • Resources: We can find different scenarios. In my experience I have encountered two. On the one hand, I have been the only tester within a company, collaborating closely with each phase of the lifecycle. On the other hand, I have been part of a QA group composed of 30 testers, operating independently from a different company than the developers. Both experiences have taught me to adapt to different situations when dealing with changes.
  • Project budget: I had the opportunity to work as a QA manager for a mobile application company almost 15 years ago where the tests were manual testing. I remember having almost a model of every  mobile device that existed at that time and a card for each company. Nowadays,  the market has changed a lot, and if you want to test the different operating systems and the mobile devices , you need licenses. Back then there were also licenses, but they were expensive and not so good in some aspects.  Today  it would be almost impossible to test manually in every mobile devices
  • Complexity: The tests required, for example, for a fintech company are not like those for a simple  game  you download for free from the market store.Contractual and regulatory requirements: for example if your products have to meet   specific requirements, it is very important that you keep them updated.

The professionalism  of a team member could also be another interesting factor that could have an  impact on our process to test changes . For example, I had to deal with a situation where the quality engineer disabled all the assertions in soapUI that were red after a change in the web service… no comments.

In conclusion, what really helps us to cope with these changes effectively will be our close collaboration with   the project team during each iteration or sprint. We should raise all our concerns in the form of risks and not be shy to inquire and try to understand a bit more. No question is a silly question and we, as testers, are the ones that have to be sure that the changes are implemented  with the least possible impact on our product.

Have we finished? Mmmm….. Wait! The title of this article said:  can we really control our changes?’ And it seems that we have not delved into that topic yet? Have we?

We suffer changes everyday in all our aspects and it is something that could affect our balance. Ok, it might sound like I’m about to perform a TED Talk about something very philosophical but, for that topic, I’m not the best person, because a long time ago, back in my thirty’s, I started dealing with my stress issues enrolling on an American football male team. But that’s another story, I just wanted to brag a bit about it.

Why Change Control?

Whenever changes are requested to the system especially by stakeholders, they are not something we can choose to ignore. It has to be implemented without affecting other system components. As a Quality Engineer, it’s our responsibility to ensure  that our product works  as expected by testing carefully the change itself, to be sure that nothing else has been affected by this change. This is where the change control process comes in handy. It helps project teams modify project scope using specific controls and policies ensuring a balance between our quality, budget, user expectative, security, etc. Equally important, we need to cope with it. If we don’t, our team members might experience burnout which can lead to unexpected exit, which means again a change to manage, and so on.

One of the things that I learned throughout all courses I took is that we often experience changes in our projects or companies that align with the 7 stages of grief, as seen  in the Kubler-Ross curve. Which stages are these?

The grief of the changes

• Shock: Even if we are aware that change may come, we are not really prepared for its arrival. We don’t know when or how a change in our code will be needed. I remember having a kanban release in production scheduled for the first hour on a Friday(yes, on Friday, we are so reckless! yeah!), and the day before, our client changed some validations on their code without any previous warning so instead of a kanban release we had an incident to solve! We didn’t expect that, we know it can happen, you don’t know when. → What does a person need to mitigate this shock? A warning, if possible.
• Denial: Many people experience denial after a change. They know something has happened but it doesn’t feel real. In addition to experiences of shock and denial, people often describe having a ‘mental fog’, and this can include lack of concentration or lack of motivation, which doesn’t really  help to deal with our change request in our product. “No, no, no, this is not happening, do we need to change our feature after all the work we did? I don’t think they are requesting that! It can’t be! It’s nonsense!”. → In this case we must be consistent because people carry on as usual and may deny having received communication about the changes, and may well make excuses for not participating in future planning.
• Anger: It’s perfectly normal to feel anger after a change. As I finished my previous sentence: “This change is nonsense!! The client/product manager or whoever asked for it, doesn’t know what they are asking for! They don’t know anything, we are the ones that developed!” → During this phase, people often need to be listened to A good example could be  a   small talk with a manager who can listen and understand their concerns 
• Bargaining & self-blame: The bargaining stage is about making promises to yourself or to a higher being, asking the universe for a chance to fix things. Ok, maybe this is a little bit excessive for a change in our code… ask the universe to change it?? But this stage is when you can think about: “if I knew about this possible change I would program a different method, I  would include another step on my test…” → That worker will need support from the team/company/manager.
• Depression & Confusion: Again, maybe excessive, but yes, anxiety can be a signal, and it can happen in our work especially if deadlines are unexpectedly moved up a few weeks. . Someone may question the meaning of life, or at least of their job. “Do I really want to work like this? Is this the job that I wanted? (This happened to me several times throughout  my career). Here is where it’s so important to ask for help. Depending on the change that we are being requested to make on our job, maybe we need to ask for more information about the requirements, or ask for more resources, and report about the risks to a higher command… It depends on the type of change that we have to deal with. → The person will need to have a vision, someone leading her/him so it’s not going to be lost.
• Acceptance: Acceptance is about realizing that you can’t change the circumstances, but that you can gain some control over how you respond. This is the most important phase. If we know that we are going to pass through all of the previous stages, we can get to this phase sooner and wiser.  . → We need to have options to be able to accept this change. The options can come from ourselves, our company, our manager and/or another team member.
• Processing grief/problem-solving: The process is not the same for all the people involved in that change and the seniority of some members of the team can help them to address the change. → Here, we will need to bring our motivation.

I have gathered some tips on how to cope with a loss and really, we can use most of them in our day to day work (and if you want to reuse it for your personal life, at least something you obtain with this article):

• Connect with others
• Ask for help
• Practice deep breathing regularly.
• Set small, realistic goals.
• Ensure you’re getting enough sleep and aim for some form of movement each day.
• Eat a healthy, balanced diet and keep hydrated.
• Rehearse how you respond to questions and new situations.

So, after going through all of this, What’s your perspective? ? Do we really have control of the changes? With my vast experience and as a mother of two toddlers, my answer will be: NO. I don’t have control of my life anymore… And a client or a regulation or a new update on the browser can be as picky as a 3 year old sometimes… or unexpected things will happen. The other day, one of my teams had another kanban release and when trying to deploy to a QA environment,  the whole environment suddenly went down. So again, you can have all ready for your deployment and the testing and then, something unexpected that puts your work at risk, comes up, great! How fortunate we are! In this case, the seniority of the developers and QA team involved  in the release helped a lot to have it fixed.

So, realizing that we cannot “control” most of these types of changes, we need to find a way to make sure that unrestricted change does not completely derail any chance of our project meeting its business case. If we cannot control, we should at least strive to manage . How?

RISKS, RISKS, RISKS!! We have to think about all the risks as much as  we can. (How can we explain this in a different way to make it clearer?)  and how to mitigate them or in case that’s not possible, raise them in the proper forum. It’s not just to tell it to our closest mate, or at home to our partner (if the confidentiality allows you to do that) or thinking aloud and then when something fails you say: “I KNEW IT!! I SAID IT!!” Ok, great, you are a good forecaster, but did you really tell that to the people who could help you or your team? 

Resources

References

[1] Agile Manifesto for Agile Software agilemanifesto.org