Future Quality Improvements for Mifos

Look at how author/speaker Tom DeMarco defines quality:  a product's quality is a function of how much it changes the world for the better.    By that definition, our product quality should be off the chart!  What changes can we make starting today to make the world better?   We are focused on delivering better software, and delivering it to the customer more frequently.  How we do that and not sacrifice quality?  Here’s how:

Simplify the product

Intentionally make Mifos less complex for the developer, tester, administrator, and user.   This means reducing complexity on two levels – functionally and architecturally.  

  • Review our product roadmap with an eye towards simplification. 
  • Scrub the backlog queue in the issue tracker to find areas of the product we can deprecate or redefine.  If it’s a broken feature, let’s fix it or get rid of it. 

For the code, simplify through static code analysis (Sonar) and source code analysis tools (PMD).  Simplification includes using Spring Framework or other tools to make Mifos more modular and to take advantage of well-tested open source libraries.    Let’s set the bar higher:

  • Turn on PMD per module and ensure that first, all new modules will have no PMD violations.
  • Make all remaining application modules are clear of PMD violations. 
  • In Sonar, we comfirm will have zero critical violations. 

No open bugs

Why do we have bugs lurking in the product that were reported years ago and have been deferred over and over?  If part of a feature is broken, and no one complains, is it worth keeping that code?  We and our customers are confused about what works and what doesn’t.  Let’s clean up our open bug list:

  • Ship future release with no known open bugs in refactored areas, and no P1 or P2 bugs in the entire product.  
  • As second step, ship with no open bugs and no documented “known issues”.

 

 Better testing

We need better coverage, and better tests.  We need the freedom to make changes with confidence that our software will be accurate, responsive, and easy to use.   While we have introduced more test automation in the past 18 months, we need to improve our test automation coverage.  This doesn’t mean just quantity of tests.  We need to be smart about the tests we add and have better insight into our test coverage.  Each test must add serious value or be removed.   

  • When a bug is found in the field, that’s a test case we missed.  We will analyze why it wasn’t found internally and add a regression test case at the appropriate level as part of our normal process.
  • The typical test automation pyramid shows the majority of tests for a product to be unit and integration tests.  At the top are UI-based system tests which test the application as an end user.  In the middle, are functional tests that can access the application at an API or service layer which we currently lack in Mifos.  

 

                                                   

Test Automation Pyramid

Quantity Of Tests

 

Conclusion

In short, if we simplify the product, have less bugs, and better testing coverage, a high quality product with a faster release cycle should be a byproduct of those efforts.