Intelligent testing is a brilliant set of opposites. Is it finding more bugs or enabling brilliant code from start? Is it about frequent and continuous evaluation or being sensitive and pre-empting issues? Is it an act of doing or a state of mind? In this article I relate intelligent testing to Yin & Yang, where the tension of opposites keeps one in the perfect state of balance enabling one to deliver the very best.
As we mature we see more opposites. Find more bugs or prevent by being sensitive? Automate more or use human smartness to do less? Continuous frequent checks or smart minimal tests? Things that seem contrary, creating tension of choice. It is really not a tussle, it is a perfect state of balance.
What is Yin & Yang? Well it is the really opposites that exist.
The FOUR main aspects of Yin & Yang are :
Let us switch to software testing now. What is Yin & Yang in the context of UNDERSTANDING a SUT?
What is Yin & Yang in the context of DESIGNING test cases?
What is Yin & Yang in the context of EVALUATING the SUT?
What is Yin & Yang in the PROCESS of evaluation ?
What is Yin & Yang in the context of the OBJECTIVE of testing?
Philosophically Zero = Infinity Nothing is everything.
The ability to be empty, to be unattached, to be in the moment, no past or future, mindful and observant enables one to deliver great outcomes.
Yin and Yang are not opposing forces, it is the tension to keep you in a perfectly relaxed state.
Summary High Performance QA is about enabling the path to brilliant code, of doing lessand accomplishing more. High performance occurs when you articulate crisply, think clearly, organise well & execute nimbly. It requires a high performance mindset that is strong, clear, agile and value oriented.
TWELVE interesting and counter intuitive perspectives to High Performance QA , beyond the typical beaten track of process, technology and skills. The perspectives are organised into FOUR themes of LANGUAGE, THINKING, STRUCTURE & DOING.
CLICK HERE to go to the special page on High Performance QA. A summary of each of these articles is listed below under these FOUR themes.
Theme #1: LANGUAGE – “the EXPRESSION of problem/solution” High performance communication to exploit power of expression in ’what-we-do’, ‘how-we-do’, ‘how-well-we-have-done’.
(1)High performance thinking using the power of language Here I outline how various styles of writing, various sentence constructs & sentence types play a key role in the activities we do, as a producer of brilliant code from the QA angle. CLICK HERE to read the full article.
(2)Three communication approaches to brilliant clarity Here I outline three communication approaches of storytelling(descriptive), rules/criteria(prescriptive) and visual that play a key role in activities we do as a producer of brilliant code, from QA angle. CLICK HERE to read the full article.
(3) To express well, choose the right medium Here I explore the role of medium to expressing a thought/idea. A frictionless paper medium is very suited for early stage ideas whilst a strict template/tool is more suited for capturing ideas fully and clearly. CLICK HERE to read the full article.
Theme #2: THINKING – “the THINKING to solution” High performance thinking is goal focussed, user centric, spatial, approximate, immersive and contextual
(4) Left brain thinking to building great code In this article I examine how a logical ‘left brained’ thinking plays a key role in the activities we do, as a producer of brilliant code from the QA angle. CLICK HERE to read the full article.
(5) It takes right brain thinking to go beyond the left Here I examine how a creative ‘right brained’ thinking enables us to go beyond what we do with logical thinking to discover new paths or discard potential ineffective paths of application to improve outcomes to deliver brilliant code.CLICK HERE to read the full article.
(6) Ultimate power is in the “empty” middle In this article I examine the infinite power that we have, which is neither in the left or right brained thinking but in the space of middle, the silence when one is absolutely mindful. CLICK HERE to read the full article.
Theme #3: STRUCTURE- “the STRUCTURE of elements” High performance structure is about great arrangement, to connect better
(7) The Power of Geometry In this article I outline how structure(or organisation) of elements plays a key to doing more with less. CLICK HERE to read the full article.
(8) The 4W to structuring a problem well Here I examine how a great arrangement of various elements of system-under-test enables one to see the problem clearly in terms of facts and questions and set the stage for efficient evaluation.CLICK HERE to read the full article.
(9) 10 ways to smartly organise test assets In this article I examine how organisation of test assets (test scenarios and cases) plays a significant role in the effectiveness and efficiency of testing. CLICK HERE to read the full article.
Theme #4 DOING – “the act of DOING” High performance execution is about doing less, doing early , staying engaged
(10) Doing less and accomplishing more Here I analyse as to what it takes to do less and accomplish more by not doing at all, by doing early, by doing what is only necessary and finally delegating the act of doing to tools. CLICK HERE to read the full article.
(11) Move rapidly by doing less In thisarticle I outline how the act of execution can also be speeded up by use of a smart checklist, which provides a significant intellectual leverage to how we do. CLICK HERE to read the full article.
(12) Stay engaged and do brilliantly In this article I outline how staying engaged by being mindful can significantly enhance session based testing in an ‘immersive’ manner, and introducing “Immersive Session Testing”. CLICK HERE to read the full article.
All these are laid out beautifully in an exclusive page on High Performance QA. CLICK HERE to see go there.
Want to be a successful leader? Let animals be your guide. Assemble varied skills to build a great team. Let good techniques and methodical action unleash the power. Watch progress and steer continuously. Be confident. Make decisions. Enable each individual to unleash their full potential. Finally enjoy the journey.
Many years ago, we went on a holiday to Masai Mara, a lovely 1510 square km game reserve in Kenya. Here the animals are free in their natural habitat whilst humans are inside open top jeeps. Seeing the Big-5 (Lion, Leopard, Rhino, Elephant and Wildebeest) and others in close quarters was just wonderful. Observing their behaviour, mannerisms at close quarters was not only enjoyable, but educational. Here is what I learnt about leadership from these wonderful creatures.
Lions after a kill
The Lions
A lion is busy eating a fresh kill of wildebeest whilst a cackle of hyenas sit a little distance away patiently waiting for the lion to finish. Once the lion is satiated and moves away to rest, the hungry Hyenas will finish the rest. Their teeth are so powerful that they can crush the bones. At another place a wake of vultures are fighting fiercely to eat the remains of a carcass killed by a lioness. In nature, nothing is left to waste , for each animal is specialised in its contribution to the nature’s eco-system cycle. A wildebeest is a big animal and it is a shame to waste anything at all. The Hyenas don’t mess with the lion nor do the vultures with lioness or with any other animals.
Leadership lesson: It takes multiple skills to get a job done well. Each facet of work requires varied intelligence and power; understanding this and abiding your time patiently is key to being successful. So in your team, who is the Lion(ess), Hyena, Vulture…? Each one of them is important, there is nothing superior or inferior.
Leopard eating his meal
The Leopard
A Leopard had dragged up a young waterbuck up the tree, suspended it precisely on a branch with body resting on branch and legs hanging down. It then went about methodically tearing up the rear with its canines. Though gruesome and sad, it was interesting to see the leopard periodically adjusting the dead animal on the branch as it progressed methodically with its job of eating.
Leadership lesson: The Leopard is a very powerful animal, with its sheer speed and power it can snare any animal. To ultimately accomplish its goal of satisfying its hunger, it must secure the dead animal, which it does by dragging the animal up the tree and then eating it by doing it methodically, tearing from the rear. What do we learn this? In addition to having a powerful team, it is necessary to employ powerful techniques and great processes to ensure that the job is well done. Power is best extracted by using great techniques and then going about it systematically.
The majestic Giraffes
The Giraffe
A herd of giraffes are moving majestically, absolutely elegant movements as they peacefully chomp on leaves off a tree top. Giraffe by virtue of its height and its distinctive coat is indeed a majestic animal. They are not shy at all. One of them walked to our vehicle confidently, stopped, looked at us without any hint of fear and then strutted away. The movements were peaceful and seemingly unhurried. On a different note, it is interesting how a giraffe walks- Both the legs on one side go forward and then the next side go forward, very unlike the other animals where front and rear are in sync.
Leadership lesson: The majestic appearance oozing confidence, fearless attitude, grace and elegance are traits that make a leader successful. And the team will do anything to ensure that the leader stands tall always.
The nimble Zebras
The Zebras
The vast African Savannah is filled with Zebras, beautiful they are with a shiny coat and beautiful stripes of black and white. They are an easy prey for the lions. Their excellent sense of sight and hearing coupled with their acute sense of smell enables them to detect danger which they nimbly respond to, by quickly running away. Their legs are so strong that a just a kick can kill the animal.
Leadership lesson : To survive/course-correct, it requires one to continuously measure (aka smell/watch) and respond nimbly to steer to safe places. Not only is sufficient to know the danger, but it is imperative to have enough power to move away quickly.
Hippopotamus powerful and relaxed
The Hippos
Hippopotamus relaxing in the water seem to be the most lethargic animals. They seem to spend the entire day relaxing in the pool when not eating grass. But do you know that Hippos are the second largest killers of humans? They are not carnivores, they attack only to protect. Their strong bite can kill humans.
Leadership lesson : Each one of us possess enormous power.It is dormant most of the time, the key is unleashing it. A great leader should be able to spot this in others and enable them to unleash it.
The happy Warthogs
The Warthog
These animals were the most interesting. Belonging to the same family of pigs, these herbivores were constantly running, seemingly for the sheer joy of it. Enjoying themselves just running across the vast expanse. They stop suddenly only to recommence in a short while. It was sheer joy to see these “pigs with tusks” run despite no threats from other animals.
Leadership lesson: Explore. Be curious. Enjoy. To unleash your full potential, you need to be unbounded and enjoy the flow.
The Wildebeest
Masai Mara is famous for the crossing where over a million wildebeest cross over from Tanzania to Kenya and vice versa. Our trip was close to the end of ‘crossing season’. Keen to see the action up close, we went to the river Mara where the crossing occurs. And there it was, a group of wildebeests on the other side of river deciding on what to do – ‘cross or not to cross’. Upstream, nearly a kilometre ahead, a crocodile was basking on the rock while a couple of them were gently floating on water, just their tops visible on the surface, a nemesis for these crossing animals.
The wildebeests are still trying to decide, one of them pushes the other into the river, but that guy does not go any further. In fact he turns back. Then they stand still for a few minutes, one of them goes into the water and then turns back. Suddenly some of them run into the water with some running on the banks, coming to a dead stop after some time. They do nothing, each of them just stand still, waiting for the other to decide. None of them take the next step. One of them on bank is fed up and decides that he has had enough of this indecision and heads back to land. He climbs the mud embankment into the high land as he climbs, a few follow suit. One by one, others follow suit. The decision has been made, they are not going to cross now. The animals that were standstill a moment ago due to indecision are rapidly moving away following the first one to the high land.
Leadership lesson: We all suffer from indecision and do possess herd mentality. A good leader takes decision and confidently goes ahead and the team follows. Not all decisions may indeed be right, but taking a decision is indeed superior to not doing anything.
I hope you enjoyed the educational tour of the Savannah! Want to be a successful leader? Let animals be your guide.
Assemble varied skills to build a great team. Let good techniques and methodical action unleash the power. Watch progress and steer continuously. Be confident. Make decisions. Enable each individual to unleash their full potential. And enjoy the journey.
Inspired by how the world is handling Covid19, this article as a SlideShare lists actions taken and criteria met to contain the pandemic and correlate this to how we can deliver clean code for large scale software systems. This article focuses on the process flow and criteria for delivering clean code.
Corona virus aka COVID19 is a global talking point now. What is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now. In this article we take a look at the actions being taken to contain the pandemic and relate to what to do deliver clean code.
Corona virus aka COVID19 is a global talking point now. A pandemic now, it has shaken the entire population of the world, busted the business and the world economy. The major stock markets are taking a massive beating driven by the sentiment that there is no medicine for this as of now.
Interestingly the suggestions posed by experts are pretty basic stuff related to good hygiene and this seems to be the only way to go given that there is no medicine as of now. What can we learn from COVID19 to deliver clean code?
So what is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now.
What is being done in terms of PREVENTION that we can relate to code?
Cover when you sneeze/cough => USE ASSERTS, HANDLE EXCEPTIONS
Wash hands frequently => SIMPLIFY, REFACTOR
Don’t touch surfaces => STRIVE FOR LOW COUPLING
What is being done in terms of DETECTION that we can relate
to code?
Check
for fever => DO BASIC TESTS
Check
for other symptoms => USE SMART
CHECKLISTS, DO DETAILED TESTS
Check
if contact with affected => DO STATIC CODE ANALYSIS
Check
origin on arrival (for travellers) => WRITE DEFENSIVE CODE
Check
travel history => ANALYSE CODE COVERAGE
What is being done in terms of CONTAINMENT that we can relate
to code?
This article is a short primer on Blockchain outlining ‘What is blockchain technology’, ‘How does it work’ and ‘Where is it useful’. Curated from four articles which are nice and easy reads.
Blockchain 101
The interesting article “Blockchain explained” is about “What”, and outlines What is Blockchain?, How Blockchain Works, Is Blockchain Private?, Is Blockchain Secure?, Blockchain vs. Bitcoin, Basics of Public and Private Key, Practical Applications, Pros and Cons of Blockchain, Disadvantages of Blockchain and What’s Next for Blockchain? A quick and easy read it is, check it out!
There are different Blockchain networks – Public, Private, Permissioned and Consortium. In a public blockchain networkis one that anyone can join and participate in, such as Bitcoin. In a private blockchainnetwork, one organization governs the network. It controls who is allowed to participate in the network, execute a consensus protocol and maintain the shared ledger. A private blockchain can be run behind a corporate firewall and even be hosted on-premises. In a permissioned blockchainnetwork, there are restrictions on who is allowed to participate in the network, and only in certain transactions. Participants need to obtain an invitation or permission to join. In consortium blockchain network multiple organizations share the responsibilities of maintaining a blockchain, predetermining who may submit transactions or access the data.
What are areas where Blockchain can be very useful? Well these are: 1. Payment processing and money transfers 2. Monitor supply chains 3. Retail loyalty rewards programs 4. Digital IDs 5. Data sharing 6. Copyright and royalty protection 7. Digital voting 8. Real estate, land, and auto title transfers 9. Food safety 10. Immutable data backup 11. Tax regulation and compliance 12. Workers’ rights 13. Medical record-keeping 14. Weapons tracking 15. Wills or inheritances 16. Equity trading 17. Managing Internet of Things networks 18. Expediting energy futures trading and compliance 19. Securing access to belongings 20. Tracking prescription drugs
The article “20 Real-World Uses for Blockchain Technology” outlines the “where”, that is areas Blockchain can be used in, and how these applications could benefit from this technology.
A mashup of three articles published as part of SmartQA digest over the last few months that outlines mindsets needed to brilliant code, tips to produce clean code and habits to speed up evaluation
Here is a mashup of three articles published as part of SmartQA digest over the last few months that outlines mindsets needed to brilliant code, tips to produce clean code and habits to speed up evaluation.
10 Simple Tips to Clean Code has in detail, simple practices that can ensure that code developed is constantly cleansed. In current times where code is churned out at a rapid pace, it makes great business sense to contain the entropy continually.
Automation is a key enabler for rapid QA, the limiting function to speed is one’s skills. And this is where good habits come in. 10 Habits to Help You Speed Up Testing outlines these in detail.
What does it take to do SmartQA? Thoughtful pause, multidimensional thinking, sensitivity and awareness and designing for robustness & testability. A short crisp article continuing from the previous article outlining FIVE MORE thoughts, on what it takes to do SmartQA.
It is about pausing to speed up, it is about thinking multidimensionally, it is about being sensitive and aware, it is about designing for robustness and testability to doing SmartQA.
Doing SmartQA is about visualising the act in one’s mind and taking steps to being robust and enabling rapid and easy validation.
1. Pause to speed up
Before you test, pause; ask what are you testing, for-what and for-where(environment). If you are not very clear, explore rapidly to dig in and understand from users’ POV and architecture/construction. Pause to collect your thoughts as to what issues to go after and how, then uncover exploiting using tools as needed.
After all, doing SmartQA is about enabling clarity to visualise potential issues before evaluating rapidly. Pause to speed up.
2. Multidimensional thinking
Yesterday a good friend of mine told me about his recent conversation with a senior engineering manager in a product dev org. The Sr Engr Manager, a great believer in code coverage told him that he just focuses on covering close to 100% code as the only measure to ensure quality, and as a means to implement shift-left. Absolutely right, isn’t it? After all, ensuring all code written is at least executed once & validated is logical and necessary.
What is/are the fallacy in this? (1) Well you have assumed that all code needed has been written (2) Well, non-functional aspects of code cannot be completely validated (3)Well, it assuming that this is what users really wanted, even if code is working flawlessly (4) Well, the number of paths to cover at the highest level of user oriented validation is just to many to cover, next to impossible! Code coverage is a necessary condition but simply not sufficient.
Doing SmartQA requires multidimensional thinking, of looking of the system from various angles both internal in terms of code, architecture and technology and external in terms of behaviour, end users, environment & usage and then making appropriate choices of what to validate later or earlier and what to prevent or detect statically.
3. Sensitivity and awareness
Being sensitive and aware to the causes of errors is useful in doing SmartQA and delivering clean code.
At large, errors creep in due to these :
Untold expectation – Did not know they wanted these, as they did not communicate it to me.
Accidental omission – They missed stating it clearly to me.
Quiet assumptions -Filling in the gaps quietly, without confirming.
Incorrect implementation – Mistakes made during transformation to code.
Inappropriate modifications – Making fixes without fully appreciating the larger context.
Interesting side effects – Innocuously affecting others, without appreciating that they are coupled.
Deliberate abuse – Wantonly use it incorrectly to push it beyond and break it.
Innovative usage – Used in a very different context that I never thought about.
Appreciate that these may occur anytime, a heightened sensitivity enables us to question, analyse, clarify and validate.
Doing SmartQA is not just finding issues, but sharpening one’s senses to be able to smell these and spot them from afar or near before they hit us. It is about elevating QA to be far more valuable to business success.
4. Designing for robustness
Doing SmartQA is not just evaluation. It is about enabling code that is being built to be robust. To resist errors creeping in, to code-in firewalls. To ensure that I have all I need in good condition before I consume it. This implies that data (inputs) process are clean, the environment I operate in is clean and the resources I need are indeed available, and the dependencies that I have on others are indeed working well.
All I do is to protect myself. How can I handle when irritants are hurled at me? Well I have three choices :
(a) reject them and not do what I am supposed to do (b) flag them (log) and not do what I am supposed to do (c) intelligently scale down and do lesser.
The key focus is be robust, to be disaffected by inputs, configuration/settings, resources or dependent code. The act of designing for robustness makes one sensitive to potential issues that may arise and ensuring we are edged into a corner.
5. Design for testability
Not only is it necessary to design the ‘how-to-do’, enabling ‘how-to-examine-the-doing’ is doing SmartQA. Enabling the ability to test the code easily and ascertain what went wrong to speed up debugging.
Hooking in code to enable the ability to inject inputs to stimulate and the ability to ascertain the correctness of outcomes is doing SmartQA. Putting in traces that can be logged and turned on doing test/debug and off doing production is indeed SmartQA. Embedding ‘self-test code’ is possibly the highest forms of testability.
Ding SmartQA is about enabling the ability to validate too!
What does it take to do SmartQA? How can I do less and accomplish more? What parts of this are human-powered & machine-assisted? A short crisp article outlining some thoughts, five for now on what it takes to do SmartQA.
It takes a brilliant mindset, intelligent exploration, diligent evaluation, keen observational skills, tech savviness and continual adjustment. It is about being logical yet be creative, it is about being disciplined yet be random, it is about exploring the breadth and depth, it is about understanding deeply and also finding blind spots about being bundled by time but be unlimited/unbounded with the possibilities. Doing SmartQA is about doing mindfully, in a state of brilliant balance.
#1 What does it take to do SmartQA?
A deductive ability of a mathematician, creativity of an artist, mind of an engineer, value perception of a businessman, technical savviness, empathy, doggedness and nimbleness, all finely honed to do less and accomplish more.
#2 Humans & Machines : Doctors & diagnosis
In today’s medicine, we know that machines play a huge part in diagnostics and treatment. They help us see internals more clearly, enable us to get to the hard-reach parts, perform rapid tests to analyse problems , monitor tirelessly to help us correct our actions. So is the doctor’s role redundant? Ouch no! The skill of the doctor in diagnosis and treatment be it via medicine or surgery is far more required now in the complex world of disease, business and law. To assist in this ever increasing complexity, machines are becoming integral for the job.
Much like this is software testing, the act of diagnosing of software for issues. Tools/automation are integral to testing that a skilled test/QA/SW engineer uses. It is about “doing SmartQA” which is a brilliant combination of “human powered and machine assisted” . The WHAT to-do is human while HOW-to-do is when’re machine helps.
Doing SmartQA is about intelligent/smart WHAT-to-test/WHAT-to-test-for/WHERE-to-test-on with smart enablement of HOW-to-test using machine/tools. It ain’t automated testing or manual testing and getting rid of the latter or machines find issues on itself.
#3 On Minimalism
I have always practiced minimalism, of doing least work with superior outcomes. Have never been a fan of more tests and therefore needing to tools to accomplish these in the context of software. Of course I exploit tools to brilliant work. Let us apply this to ‘doing SmartQA’.
We talk about left shifting, of TDD, of wanting to find issues earlier. We emphasise units tests and automating these. Are we shifting the objective to doing more unit tests? The purpose was to produce ‘cleaner units’, implying heightened sensitivity to issues via TDD and writing good code in the first place, of adopting cheaper static means to uncover these may be missed before resorting costlier automated unit tests.
Doing SmartQA is really about ’not doing’, well doing minimally really. It is not doing more and therefore needing to adopt tools. So heighten your sensitivity, build good code habits, use mental aids like smart checklist and of course exploit software tools to do the heavy lifting of tests. After all, don’t we all want to adopt wellness rather than expend effort to diagnose potential illness? And I bet you want an doctor to check out before they ‘outsource’ the finding to machines.
#4 Brilliant engineering
Is testing a mere act of uncovering bugs? I think not. It is really a mindset to clarify a thought. When we develop something, in this case code, a smart testing mindset enables us to step outside of being the producer into
the shoes of end users, empathise, see their point of view, appreciate what their environment looks like and understand what all can go wrong so that we produce clean code. At the worst case, put hooks inside code to give us more information as to how code is being buffeted, so that we may examine later and refine the code.
Doing SmartQA is not just about finding bugs but getting into the mindset of ‘Brilliant engineering’.
#5 See better, cover more, test less
A good ‘world view’ enables us to ensure great coverage in testing. Is coverage limited to execution only or does it allow us to see better?
Coverage is about enabling us to see better from all angles. It is not about merely ascertaining if test(s) could-be/are effective. Enabling a viewpoint from USERS, ATTRIBUTES, ENVIRONMENT, CODE, ENTITIES allows us to see from multiple angles, sensitising us to deliver brilliant code with less testing/validation. Of course it does help us significantly judge the quality of test cases and testing also.
Viewpoints from USERS, ATTRIBUTES, ENVIRONMENT, CODE, ENTITIES
Doing SmartQA is more than just doing, it is about significant enablement to see better, heighten sensitivity and accomplish more.
You may find this article “50 Tips to SmartQA” interesting. Check it out!
“A typical accident takes seven consecutive errors” states Malcolm Gladwell, this notion is reflected in Mark Buchanan’s book “Ubiquity” too. This article dwells upon ‘How do you ensure that potential critical failures lurking in systems that have matured can still be uncovered?’
—
“A typical accident takes seven consecutive errors” quoted Malcolm Gladwell in his book “The Outliers”. As always Malcolm’s books are a fascinating read. In the chapter on “The theory of plane crashes”, he analyses the airplane disasters and states it is a series of small errors that results in a catastrophe. ” Plane crashes are much more likely to be a result of an accumulation of minor difficulties and seemingly trivial malfunctions” says Gladwell. The other example he quotes is the famous accident – “Three Mile Island” (nuclear station disaster in 1979).
It came near meltdown, the result of seven consecutive errors – (1) blockage in a giant water filter causes (2)moisture to leak into plant’s air system (3) inadvertently trips two valves (4) shuts down flow of cold water into generator (5) backup system’s cooling valves are closed – a human mistake (6) indicator in the control room showing that they are closed is blocked by a repair tag (7) another backup system, a relief valve was not working.
This notion is reflected in the book “Ubiquity” by Mark Buchanan too. He states that systems have a natural tendency to organise themselves into what is called the “critical state” in what Buchanan states as the “knife-edge of stability”. When the system reaches the “critical state”, all it takes is a small nudge to create a catastrophe.
Now as a person interested in breaking software and uncovering defects, I am curious to understand how I can test better. How do you ensure that potential critical failures lurking in systems that have matured can still be uncovered?
Let us look at what we do- We stimulate the system with inputs (correct & erroneous) so that we can irritate latent faults so that they may propagate resulting in failure. When the system is “young”, the test & test cases we come up are focused on uncovering specific (singular) faults. i.e a set of inputs that can irritate singular faults and yield possibly critical failures. This is possible because the “young system” is not yet resilient and therefore even a singular fault bumps it up! We then think that our test cases (i.e. combinations of inputs) are powerful/effective. But these test cases do not yield defects later as the system becomes resilient to singular faults.
As the system matures we need to sharpen the test cases to irritate a set of potential faults that can create a domino effect to yield critical failures. Creating test cases to uncover singular faults in a mature system may not useful. It is necessary that test cases be at a higher level of system validation (i.e have long flows) and have the power to irritate a set of faults.
Should we resort to uncovering critical failures only via testing? By creating test cases at higher levels that have the power to uncover multiple types of faults? Not necessarily. We can apply this thought process at the earlier stages of design/code too. Using the notion of sequence of potential errors and understanding what can happen.
If your drive in India you know what I mean … the potential accident due to a dog chasing a cow, which is charging into the guy driving the motorbike, who is talking on the cell phone, driving on the wrong side of road, encounters a “speed bump” , and screech *@^%… You avoid him if you are a defensive driver. Alas we do not always apply the same defensive logic to other disciplines like software engineering commonly enough…
