Backward Compatibility - What and who drives the compatibility?

A tweet of Ministry of Testing read as this -- How do you decide how backwards compatible your product should be?

I learn, there is no general rule and as well no specific rule that applies when it comes to backwards compatibility, forward compatibility and the compatibility.  It is highly specific to what product we are dealing with and how the system around it are developed, or being developed or will be developed.  Also how it is deployed.

While compatibility is one of the main feature of product feature, it also signifies -- the design, the deployment style & patterns, communication and the exchange of data.

Further to be precise, compatibility is context specific task.  I have not come across where it is generic task where it is applied and applicable to any where.

If asked what software can come into compatibility spectrum, then:

>> Database System

>> Server

>> Client libraries like SDKs

>> Server Configurations

>> Operating System

>> Hardware Configurations

>> Client application versions being used by user and number of users

>> Server configuration versions being used in different client applications

>> Browser versions, it was a major compatibility concern a decade back

>> Application system version and its dependencies compatibility version

Few analytics that influences the decision on compatibility

>> Analytics showing the user on specific versions of libraries

>> Analytics showing the user on specific versions of OS

>> Analytics showing the user on specific version of hardware configurations

>> Analytics showing the user using specific feature which involves server configurations

>> Analytics showing the conversion funnel on specific setup of system

Few emotion that influences the decision on compatibility

>> Experience of user using a product on specific setup and configuration

>> Customer Support analytics on problems, queries and user satisfaction on specific setup and configuration

>> History of previous compatibility and migration

>> Competitor's presence

>> Team's opinion

Business aspects

>> Negotiation extent

>> Bearable Cost and Non-bearable cost

>> Business Value

>> Social Value

>> Strategic Value

>> All above converting to business profits

>> Survey carried out

>> Timeline

>> Budget and Resources

>> Talents -- people

Environment

>> That simulates the backward version of the system

>> That simulates the provisioned version of the system

>> Outcome of the assessment in such environments

If seen, where do tester fit here to decide the backward compatibility of the product?  In my experience, the decision of backward compatibility is most times strategic from aspect of the technicality.  In the enterprise ecosystem, the same strategic will weigh more on the business decisions and then the technical decisions.

The executing tester most time will not be involved here in such decisions.  Could be a person leading the testing team or the engineering efforts can be involved in such meetings.  In start-up environment I have worked so far, the decision meeting most times did not have the testers involved.  However, on getting the heads up for backward compatibility need, I use to assess the risks in system and its sub-systems.  Then, I shared and had a meeting scheduled if there was a need of different stakeholders and teams to clarify and resolve any risks mentioned.

In simple, the business don't want the service to be broken for a user.  The user should get the service that business provides on using the software application.  Further, the conversion what the business expects has to be what the business expects.  If not, then there is a problem to user and as well to business.

Communication, has explicit and implicit messages! Have you got them?

Besides all the technical work the testing team and a tester do, there are times the tester and her/his testing will take a hit.  Here is one such hit and how I solved it.  When working in an organization which is building a product, usually there will be multiple teams involved.  Likewise, multiple people on influencing and making the decision about the product, development and shipment.  Any one miscommunication here and the slipping of time, the testing team gets its time squeezed and cut, most times isn't it?  I have experienced it.

When I looked into what was the problem here and to solve it, I learnt these:

1. When decision makers communicate, they can have two types of communication being conveyed for teams. 
2. One is explicit communication - which is verbal and written.
3. The other is implicit communication - which is neither verbal nor written; but it is expected that it has to be understood by teams.

If the testing team don't catch the implicit communication, what could be the impact in the time given to testing?  It depends on magnitude of the problem!  Most times, the explicit communication made in a context as well goes misinterpreted by the teams.  If you are not part of that teams which misinterpreted and did it right each time, probably you had a better and standing leader in your team who solved the communication problem.

A simple heuristic here for the testing team and others who involved in this context -- How one can misinterpret what I said? Did I misinterpret in what is said?  One can be not that sharp in communication and interpretation, say.  But that number of team members with varied experiences level, are same in that skill?  Could be yes, then we have to help team; if not, then where is the problem?  Here the question is about solving and proceeding further so team can be of help to each others.

I lead the projects and testing delivery while I was working in Moolya Software Testing Pvt. Ltd. Having lead 55+ projects for different customers and its deliveries, in this role, I had to communicate with external teams (programmers and testers), internal teams (i.e. team within Moolya), sales team, recruit team, human resource for skill development programmes and management team (at customer place and in Moolya).  Especially working in the Startup projects will give the lessons very well, at least I have seen it for me.  Note here, if I had one misinterpretation with customer's communication and passing it to my teams in Moolya and to management, how impact that would be? Is it a big cost?  I did misinterpret in initial stages; but then when I observed it, I made sure, I will have to minimize it and keep it to zero if possible.  I worked on it and assisted the teams I was leading to practice it.  For example, say a feature and release date said by customer explicitly and I misinterpreted it. Further customer too assumed I got the message.  Were there any implicit messages here, which customer assumed that I have got it?  So do I assumed that I got it?  Once I found that I was struck with problem here in a project, I fixed it in me for first.  Note, my Moolya is always close to the tester in me!

Here is how I worked on it and continue to work on it. Despite this practice, at times I do still fail and I know I'm human and so are others.  All I check is what is the cost and value of what I did here!

Whenever I'm certain that I fully and completely understand the other person and teams without the benefit of clarifying questions, I ask myself this question -- If I weren’t absolutely, positively certain that I fully and completely understand, what would I ask?  This question helps as a trigger heuristic to know more about my understanding.  But will I do this each time?  No, I pick it in contexts which hints me something is missing. For example, when there is confusion arising in me or in teams; in the time of where major decision leads are being considered in decision being made.  If none of the team have confusion or questions, I still revisit on this and ask teams for saying what is been understood.  How I ask team members is another way of doing it. I will not get into that details, you see that's another challenge and problem to solve. Let me keep one problem here and focus on its solving.  If you said, who will do this when there is no time to do task which I have been assigned, fair enough.  In my role, I will have to do that until I get confidence -- this team or these team members can handle themselves in the situation by questioning and asking for clarification.  My role is not just to lead and deliver the projects.  I'm responsible and accountable for my team members skill development too - which is implicit expectation of an organization though it is not communicated in offer letter or in promotion letter or in promoted role.  If you don't agree or you say I should not be doing this, fine!  One day, when it comes and hits to you or to your team and organization, probably that is the whiteboard day.

I keep in mind that it’s in situations of absolute certainty in which I'm sure I understand and I say it to myself -- I'm most likely to misinterpret. I make it my responsibility to clarify my own terminology to ensure that the other person or team members understands me. As I provide clarification, I ask these questions to myself:

1. What assumptions might I be making about their meaning?
2. What assumptions might they be making about my meaning?
3. How confident am I that I’ve exposed the most damaging misinterpretations?

I see sometimes, people getting annoyed!  But my testing career experience have shown me, the decisions most times goes not conveyed well enough explicitly.  Later it is said, isn't that mean same or no change or there is a change, i.e. it is implicit.  Later, when taken implicitly and proceeded, I was asked why did I do that.  Now should I say -- that isn't implicit as last time?  Then answer is NO.  I decided that I should be avoiding this mistakes and I started to practice -- interpreting and getting clarified it, though few feels annoyed.  I see value here and cost of being catastrophic happening is high if went on assumptions for the implicit meanings that is not literally communicated.

The best solution for me is simply to try to heighten my awareness of the potential for misinterpretation.  I probably can’t catch all communication problems.  But if I do the best I can, and don’t allow myself to feel too rushed or too intimidated to ask for clarification, I should find that I'm in sync with the other person(s) or team(s). If I'm not, it’s better to find out early on, rather later when the consequences could be catastrophic.

I make sure, I ask questions and get it clarified.  I do insist on communicating verbally and in written about the explicit and implicit part of communication and clarification.  I hope this will be helpful to testers and others who work in a team and with teams to deliver the shipment on time.

To end this post, see this is not part of any technology stack, automation, testing, and roles.  It is about how we solve the problem that blocks the core problems which we are solving.  If you happened to see a value in it, do talk a word about it with your team member.  A change in team member or in you, can help your organization, your team, your product, your customer, your promotion and your salary.