Why Negative Testing is so important ?
Testing is not all about code coverage!.
Testing is not all about How strong is our code !
Testing is not all about How many test cases we have covTesting is not all about code coverage!.
Testing is not all about How strong is our code !
Testing is not all about How many test cases we have covered !
Testing is not all about what Technology you have used in testing!
Testing is not all about what Technology you have used in testing!
Then What really Testing is ? The above starting picture simply reveals it.
It says very simple concept .
How much near are your in your test cases to actual and real time conditions which the end user goes thru ?
If we miss even one real time scenario like failing to test a negative test case where your sensor is bad and How your software which is controlling the plane operations especially the Autopilot to which the sensor is integrated , see what is the amount of damage it creates not only to the product, life of people and but also your brand for which you spent so much time and effort to create it .
So this is what it happens as shown above!.=>https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings
Hold on ! We did not understand anything you said so far . Okay
Why do we need the MCAS ?
How do we detect and correct the stalling using MCAS ? The main source to sense the stalling is the angle of attack sensor
What was the issue in this MCAS System ?
So now you know but the important part is that MCAS system had a single point of Failure and was the system vulnerable to such a situation , yes it was but was not tested . We missed this negative test
For People who want to know How a angle of Attack sensor works shown below is the Video https://youtu.be/znRi-N1q4UU?si=1fl7QGyx5HEJUt_t
and why do we need a signal from an angle of attack sensor to fly a plane the video is given below . We have to monitor that the plane should not have a climb angle beyond critical angle of attack and it happens and if its happens, Its called as a stalled condition where in the plane looses control and does not work in a normal way ,then we reduce the climb of angle by bringing the nose down . That is what the MCAS System was doing that is bringing the nose down of the plane by overriding the Manual controls .(Please note that Iam not an SME in this subject so please careful on conclusions you make after reading about angle of attack here or the MCAS System) And How does the MCAS System work Refer https://www.cnn.com/2019/04/30/politics/boeing-sensor-737-max-faa/index.html#:
The intent of this Topic is to bring the essence of testing your code and not to point anything else .
When we talk of content Management we talk of relevance of contents to the Topic depending on the Type of Audience but during Testing stage do we do not talk about relevance of test cases and test design to real time and actual conditions of the Product ? Where is the terminology for this do we even have it ? (Something like this as shown below ) We need to realize the more relevance we have the more smarter we are in building a stable and Stronger product which can survive in any conditions and we should enjoy achieving the relevance which is there in non software related product like Car , Planes engines and so on but we don't have it here since our entire focus is completing the Jira Story .
Agreed 100 percent ! But Then
So, if you want to drive DevOps adoption across your entire company, you need to dig into testing and change the way it works.
Thats the only way to maximize the efficiencies of your team. So you are driven to do testing also In recent years people have removed QA departments and bought up the Dev Ops culture where we do not expect to have a QA personnel and Developer does all the testing until it goes to UAT Cycle .
What would be the Quality of such Code when people who are in regular QA can miss near real time cases as shown above ?
The Quality could be deceptive to the end user sometimes like this .
It worked on all cases but except one negative test but the failure was of such a high cost Have you ever wondered wondered about this?
Do not show sympathy on the Young the developers now who have to follow the Dev Ops Culture , Lets think about Empathy Aspect .
Sprints and Stand up meetings Where we do Kanban or Have agile Methodology do we even discuss about relevance even for 5 minutes?
On Top of that Lets except Ground reality the that the Developers are viewed as the Valuable piece in SDLC Life cycle by the Higher Management and rest everything can be replaced.
So do not be surprised if we have another catastrophe happens like this.
But let’s not wait and watch to happen it again. We all are engineers and lets take accountability for what is going on and lets come up with a solution for these kinds of issues. After all the engineer or tester there is one of us!
We do not know when one of us could be passenger of such planes. Its we who should start the revolution to make the earth a better place to live and not leave.
Developers you are measured by how fast can you develop code and appreciated by Release Managers and Directors for that.
If no then now is the time to rise and awake and do a deep dive in testing .
Lets take a one step deeper drive into this now .Another source familiar with the 737 MAX testing said the failure of an AOA sensor was not flight tested, but rather analyzed in the design and certification of the aircraft, and it was determined trained pilots would have been able to handle the failure.
A second former Boeing test pilot was surprised to learn that the company had relied on a single sensor, as opposed to a redundant system, to perform such a vital function in the first place. A former Boeing pilot who tested the 737 Max, who requested anonymity due to fears of negative repercussions, told CNN I don't think we appreciated the ramifications of a... failure of an AOA probe.
Here we go that we have to understand the more Broader picture of Products as well as platforms and width and breadth to which can expand otherwise word Quality can be deceptive .
You will be surprised to know that for some of the products its 80 percent testing and only 20 percent development .....
So testing methodology itself gets a revolution as the product evolves and if we do not have evolution of Testing methodology , that will reflect that we are not in Tandem with product evolution or may be application evolution .
领英推荐
Latest Trends in Technology results in overhaul of existing application in software and the new application is available for example as we progress in asynchronous technology for APIs we overhauled monolithic application and bought up microservices .
Note that this also can be viewed was an interruption in the evolution of existing application.
Where am I going ? Yes look below they did not drop the old car they developed on that .
Look there the Jump from steam engine to Internal Combustion engine .
When and how ?
Steam car manufacturers tried to shift tactics and market their cars as luxury products, but the fact that by 1918 the Ford Model was six times less expensive than the most popular steam car of the time, the Stanley Steamer, said it all. Once the electric starter motor debuted in 1912, steam-powered cars all but vanished. This is from https://www.extremetech.com/cars/148416-are-steam-cars-poised-for-an-epic-comeback
Do you want to vanish classifying defects as corner case or evolve the product ?
Its up to you ...................................lets not forget that Testing is Not just a Methodology , It's a big field in engineering.
Refer https://www.bosch-engineering.com/services/testing-and-prototyping/ and see How serious is the business of testing of Vehicles .
Car Manufacturers are serious about testing and yes they will outsource that as shown above. Our software culture thinks more about Job security rather than about serious testing or emphasizing on it since some people are already darlings of the Higher Management and the whole budget control is given to them and they are backed up by several people to strengthen there opinion who do not want to emphasizing on testing . If they cannot get enough budget and time for you do develop quality products and if you still like them that good Luck to you since you will also a part of the drowing Titanic ship .
On top of that QA resources are not considered as critical resources since the higher management thinks that all the intellectual power is needed only in coding and design and that is where most of the thin budget should go for which they put up so much fight to acquire it.
The QA resources are only testing what has been developed so they are just mere inspectors . That is the kind of flow which is getting built up slowly. When a QA person becomes a developer its like a promotion to that person ....!
This is the harsh truth of Software Industry.
Yes this is not just a clutter in the code but clutter in Work culture slowly seeping into Software Industry and since software is used in other industries its also going there . Are you not alarmed ?
Toyota Manages 350 Suppliers at Kentucky for the parts of the Car , Imagine How many number of tests they may be conducting before they release the Car to the Market .Interested more on this watch the Video below . We have Quality Assurance engineers in Manufacturing not Quality Testing engineers like in the Software Industry and that is called as passion for putting quality into products . We software engineers celebrate our winning events very early and most of the times do not show any passion to put quality into products due to pressure of releases
A Feature we developed on webapp does not work on particular version of Apple Phone .
What is our immediate reaction ? Ahhh ! It is corner case Scenario.
Should we adopt This way of thinking about the software we use to build products ?,
Should we not give a reaction that its time to measure degree of closeness of our test cases to actual condition ?
code is not everything neither is technology so what is everything ?
Its your attitude towards product or Application which you express thru your code or Technology and this is everything which should not be compromised due to peer pressure or pressure of the release .
You should not signoff or end after implementing a new technology into a Legacy application.
you should continue from that point then until you can make your end customer happy and then only is your passion is expressed and reaches there .
Do you remember the Happiness you had when you drove your first Favorite car ?
Yes you are capable of giving the same happiness if you see implementing a new technology into a Legacy application as a starting point .
Guys Lets accept this , the very cursor you type now jumps somewhere else when you are typing and this issue has become more serious now a days and we almost accept it now or may be compromise for that because we have already established that attitude in our mind and this kind of incidents are merely a reflection of our Attitude and compromise of standards in our Software releases.
Back in those days a defect when corrected in a product , that contributed to evolution of the product and it was not seen as corner case scenario . Its this type of culture we need to adopt and the change to see better products and applications which I feel in my opinion and wanted to share .How often this happens in Software development that your Testing methodology evolves ?
How many times you have seriously visited a car Manufacturing plant and looked at what kind of testing is done there ?
How many times your car has broken , does it break on a daily basis ?
No . If so why you don't have that curiosity to find out at least on internet ?
Computer Science is about Speed Guys , its not everything, Lot of Science is still unexplored .People still don't have clear answer on How life came to earth !. Other wise real estate would have grown very Quickly on Mars Planet .Coming back to our original Discussions...
Where do we include this in our Analysis report of testing about ramification of a failure in SDLC ?What is around us when we start thinking of Testing ?
Lets think of the Big picture when we are testing , It take years and years to earn brand image on products or applications and it should not be lost for our ignorance on testing Just because we need velocity and people cannot find issues in our application upfront during releases
Stay Tuned on for more on Testing methodologies in our SDLC Process . Note that iterative Testing is the most preferred way but it is Trial and error .Say you are a Quality Inspector and you go at Vendor Place and you have to decide in 5 Minutes if a lot of X product is good or Bad , so you will have a random technique to test that in the Automotive world and you can use similar techniques on deciding if you can take up a module for testing or reject for testing . That is acceptance criteria for Testing . Lets discuss more on that .
For now https://qualityinspection.org/random-quality-inspection/ this should tell you something and how we can apply this in SDLC.
Revisiting my article where I had talked about Boeing and Now Iam talking about Tesla , Yes Tesla has a digital Twin but that is also incomplete, since we fail to see all type of negative scenarios which occur in the actual field . shown below is the video of Tesla car burning in Garage.
Do we have a solution for that Yes?
May be IOT has answer but the focus is not on the solution its on the ability to design edge cases of Testing in Automotive world . We need to simply understand Limitations of AI when testing . Keep watching we will have many such incidents .
Does the ownership of quality is Totally dependent on QA or Developers ? absolutely not , It also could be related to a Failed leasership and a flaw in culture , In case of Boeing please go thru https://www.library.hbs.edu/working-knowledge/why-boeings-problems-with-737-max-began-more-than-25-years-ago for a brief analysis .
Note : This is my personal thought and personal article and it does not reflect opinion of any organisation or institution.