SmartQA Community

#46

SmartQA Digest

The sufficiency of test cases has always been an interesting challenge.The cliched notion of code coverage is sadly insufficient, being an unidimensional measure. “The smart coverage framework” outlines a refreshingly simple picture as a smart coverage framework.
 
In this edition of SmartBites are four snippets of brilliant advice from Sudhir, Zulfikar, Girish & Jawahar – “Have extreme ownership mindset”, “Focus on the big picture”, “Build with quality, not test after” and “Understand operating conditions & implementation to test well” as SmartAdvice #1
 

Oh, in this week’s SmartBits, Srinivasan Desikan outlines “The evolution of dev” and what it means to testing.

beEnriched

SmartQA smart coverage pic

The smart coverage framework

T Ashok @ash_thiru on Twitter Summary Coverage, an indicator of test effectiveness is really multidimensional and has not been dealt with rigour most often(excepting for

Read More »

expandMind

Necessary but not sufficient book

Necessary but not Sufficient

I have been a great fan of Dr Goldratt having read all this books, my favourite being his first book “The Goal”. This book “Necessary but not Sufficient” is written as a “business novel” and shows the fictional application of the Theory of Constraints to Enterprise resource planning (ERP) and operations software and organizations using that software.

Read More »

SmartBites

||VIEWS FROM INDUSTRY LEADERS||

smartbits

||NUGGETS OF LEARNING||

Necessary but not Sufficient

I have been a great fan of Dr Goldratt having read all this books, my favourite being his first book “The Goal”. This book “Necessary but not Sufficient” is written as a “business novel” and shows the fictional application of the Theory of Constraints to Enterprise resource planning (ERP) and operations software and organizations using that software. 

Here is an interesting comment by Alistair MacDonald (from Goodreads) “The stance of the book on the value of software is that “software is necessary but not sufficient”, Ie: software is a necessary evil. I think this is an accurate view of software: it’s valueless without the ability to reprogram humans to use it correctly. The book applies this concept to change in general; Ie: providing a systems approach to fixing a human problem is only half of the solution, you also have to change the mindset of the users so they are able to buy in to the paradigm shift that the system enforces. There is a hidden world of beauty among all of this, which is that the original meaning of software was “people to run the hardware” (prior to hardware having the ability to operate on procedural instructions from memory). So, “we need the software”, but “we can’t expect results without changing the users”.

An excerpt from Jack Vinson’s blog on this : “With regard to the story in the book, I enjoyed it for what it was.  It follows the usual path.  The vendor and implementer see they have a problem meeting their forecasts.  They come upon the idea of selling bottom line value, rather than the usual justifications that their industry offers.  And they discover just how hard it is to turn “visibility” into a number that means anything to the bottom line.  Eventually, they hit upon a way to think about their software in a new way – a way that is inspired by Theory of Constraints.”