Naive Innovation in Software Testing
Recently I came across an interesting article about naive innovation. The idea behind naive innovation is that a person with the right mindset and passion for a certain area is a great candidate for innovation, even without having the same subject matter expertise as a domain expert who lives and breathes the subject every day. While this particular article talks about innovation in the health care industry, my mind was immediately mapping this idea to the software testing world.
Traditionally in the software testing evolution, we have always talked about the need for independence and an unbiased look at the software without being fully privy to system internals. This was how black box testing and other exploratory forms such as rapid software testing came into the mainstream. However, this also caused a disconnect between the testers and the rest of the product teams, which agile helped fix in a large way. Today, a naive tester—one who explores the application without being fully told what is expected—is certainly more innovative and creative with test scenarios and coverage.
Then came a stage in the testing evolution where domain knowledge became very important for software testers. Testers who were not only horizontal players with the testing know-how but also vertical players with the domain understanding were more in demand. This is applicable even today but may be seen as contradictory to the concept of naive innovation.
While a certain level of internal understanding and domain knowledge makes a tester effective and thorough, it may bring about one-dimensional thinking in execution style. Techniques such as design thinking and naive innovation help bring creativity and sometimes better solutions for an existing problem than doing it in a given way. Neither method is fully right or wrong, fully sufficient or insufficient. It is important for the tester and the test team to understand the scope of work at hand, determine the right balance in techniques, and embrace both to bring the required level of effectiveness and creativity.
Watch out for the FDH (Fat, Dumb, and Happy) teams in an organization, which are those wanting to fall back on just one area or those not wanting to stretch bounds—a team that wants to only have a horizontal focus and does not want to understand the domain workflows—or similarly just wants to stick to workflows and does not want to be creative and innovative. This is an important area for test management teams to focus on to continue to innovate as a team in both tactical and strategic operations.
We all understand innovation is important, and a mix that includes naive innovation is certainly worth a try within the overall testing strategy. Crowdsourced testing may be a good place to start, as the crowd-sourced users are often naive testers who aren't privy to the system under development.
