It's been a long time since companies have been developing products & services frequently consumed by a wide gamut of population.
Some of these firms are leaders in their field of innovation, they set the pace for others to follow by breaking technological myths and setting up new dimensions & perspectives for the general consumer to use the product.
It becomes crucial for these firms to make sure that the critical or core function of the product still works without any issues and it needs to be completely fail safe.
However, it has been seen in past few days - that the critical core feature hasn't lived up to its expectations. There can be various reasons for this - some of them might be as follows -
1. core feature identification was flawed or skewed.
2. the fail scenarios were not properly evaluated.
3. third party issues which lead to the critical feature stop responding or responded erratically(although this is a virtual scenario & I will explain why in the next paragraph).
What am I talking about here?
Let's take an example to understand - let's say a popular mobile phone manufacturer makes an awesome mobile phone, it's tech trendy, quality proof, secure - now the manufacturer replaces a function which was originally mechanically controlled via a digital substitute - let's say - touch or haptic feedback.
Sometimes firms go forward with taking bigger risks like eliminating the mechanically controlled control point completely. This is a perfect scenario for innovation but the major question here is -
a) is that mechanically controlled feature - a core functionality? how do we answer this? - best way is to invert the question and answer what if that feature is removed completely - can the device function without it? if no, then the answer is yes - if answer is 'yes', then without question it 'has to work always'.
- in the above example - this might be the 'home' button on the mobile device.
So we answered the first question(although I am sure, there will be well educated minds challenging the basic response to this common man question and more hillariously, justifying it too) - let's move on.
So what happens next - this core feature should work always - in both cases of upgrade - 1) changing the technology from mechanical to digital 2) removing the button completely - there should be enough scenarios to evaluate both the possibilities scenario set for failure. Also there should be third party integration evaluation so it is confirmed that the button does work all the time.
So here testing plays a major role, and the firms focus should shift to active testing not just by using automated methods but engaging vast number of scenarios. Question is how do we do that?
This brings up an interesting concept into focus - experience feeds in a lot of test cases - as long as both 1) & 2) have had sufficient time periods of being in existence and have had usage patterns which have been unique.
Then there is testing for future products in development but being launched in the 1 year timespan of the feature switch. The concept which helps here is let the humans and computers work together to perform this part of the product cycle validation. The possibilities here can be new found like using an AI engine to evaluate scenarios and mix & match them and test them throughly or have a third party dumb component created via an AI software to simulate a test which would allow the feature to be switched to a fallback mode and would test it's fallback coherence in that scenario.
Third party issues are ones wherein nobody takes the blame unfortunately there is nothing like third party issues, if the product is owned by a firm - it's not owned partially and every third party issue which is core to functionality should have a fallback built in so the third scenario is basically a virtual one.
Well, why so much of a hustle - because it seems one fine day when unfortunate customer 1 who was using the mobile device(via car play) with so much trust on the company making it - that he/she spent their savings to get it, couldn't activate the home button during driving to help with navigation even with voice failing to capture any command and had no option but to stop and restart the device, which might have costed them an accident or it might have gone worse.
Still many would disagree this is a core feature but the essence of the story here is when it comes to core feature identification more thought needs to be given to given current product standards.
In case if anyone is interested and might not have guessed - the product in above example was iPhone with latest software version installed(but that's not important as the above detail is..).
Some of these firms are leaders in their field of innovation, they set the pace for others to follow by breaking technological myths and setting up new dimensions & perspectives for the general consumer to use the product.
It becomes crucial for these firms to make sure that the critical or core function of the product still works without any issues and it needs to be completely fail safe.
However, it has been seen in past few days - that the critical core feature hasn't lived up to its expectations. There can be various reasons for this - some of them might be as follows -
1. core feature identification was flawed or skewed.
2. the fail scenarios were not properly evaluated.
3. third party issues which lead to the critical feature stop responding or responded erratically(although this is a virtual scenario & I will explain why in the next paragraph).
What am I talking about here?
Let's take an example to understand - let's say a popular mobile phone manufacturer makes an awesome mobile phone, it's tech trendy, quality proof, secure - now the manufacturer replaces a function which was originally mechanically controlled via a digital substitute - let's say - touch or haptic feedback.
Sometimes firms go forward with taking bigger risks like eliminating the mechanically controlled control point completely. This is a perfect scenario for innovation but the major question here is -
a) is that mechanically controlled feature - a core functionality? how do we answer this? - best way is to invert the question and answer what if that feature is removed completely - can the device function without it? if no, then the answer is yes - if answer is 'yes', then without question it 'has to work always'.
- in the above example - this might be the 'home' button on the mobile device.
So we answered the first question(although I am sure, there will be well educated minds challenging the basic response to this common man question and more hillariously, justifying it too) - let's move on.
So what happens next - this core feature should work always - in both cases of upgrade - 1) changing the technology from mechanical to digital 2) removing the button completely - there should be enough scenarios to evaluate both the possibilities scenario set for failure. Also there should be third party integration evaluation so it is confirmed that the button does work all the time.
So here testing plays a major role, and the firms focus should shift to active testing not just by using automated methods but engaging vast number of scenarios. Question is how do we do that?
This brings up an interesting concept into focus - experience feeds in a lot of test cases - as long as both 1) & 2) have had sufficient time periods of being in existence and have had usage patterns which have been unique.
Then there is testing for future products in development but being launched in the 1 year timespan of the feature switch. The concept which helps here is let the humans and computers work together to perform this part of the product cycle validation. The possibilities here can be new found like using an AI engine to evaluate scenarios and mix & match them and test them throughly or have a third party dumb component created via an AI software to simulate a test which would allow the feature to be switched to a fallback mode and would test it's fallback coherence in that scenario.
Third party issues are ones wherein nobody takes the blame unfortunately there is nothing like third party issues, if the product is owned by a firm - it's not owned partially and every third party issue which is core to functionality should have a fallback built in so the third scenario is basically a virtual one.
Well, why so much of a hustle - because it seems one fine day when unfortunate customer 1 who was using the mobile device(via car play) with so much trust on the company making it - that he/she spent their savings to get it, couldn't activate the home button during driving to help with navigation even with voice failing to capture any command and had no option but to stop and restart the device, which might have costed them an accident or it might have gone worse.
Still many would disagree this is a core feature but the essence of the story here is when it comes to core feature identification more thought needs to be given to given current product standards.
In case if anyone is interested and might not have guessed - the product in above example was iPhone with latest software version installed(but that's not important as the above detail is..).
No comments:
Post a Comment