Dusting Off Our Testing Methodology

I'm doing some volunteer work with a non-profit software company who makes an app for other non-profits to track the people they serve as well as data collected during their encounter.  Kind of a neat project and something I didn't really think about until I got connected with this group.  It's a pretty lean (not Lean) organization, with only a director, some services folks, a couple of developers, a couple of tester/support people, a business analyst/support person, and an admin assistant (who also happens to be my wife).  

I got connected with this company because my wife talked with the director of the company, and he needed to do some regression testing of their app and my wife told them about my role, and how we have R&D tools to support various stages in the SDLC, and I may be able to help. The company I work for supports various volunteer activities and I thought this could be a good one for some of the testing folks I know, instead of the traditional build a house or make care packages, so I was up to help and thought I could get others to help as well.

After talking with the director, what I found was not so much the need to do regression testing, they definitely need that, but they needed a testing methodology to tell the who,what,when,where, why and how of testing their app.  Luckily, I was instrumental in writing our testing methodology for the Verification & Validation piece of our CMMI appraisals about four years ago, so I decided to dust that off and see if it is transportable outside of our organization.

Looking at our methodology docs from afar, I'm not sure those fit the newer (at least new to us) development methodologies like Agile or Lean, but was made for Waterfall or what we call "WaterScrumFall" (waterfall in requirements, iterative in construction, waterfall in testing and release).  Our testing methodology concentrated on the different types of testing (unit, functional, UI, workflow, load, stress, etc...) and categorized those into testing categories (requirement, white box, black box, performance, etc...) and where they fit in the traditional development phases (inception, elaboration, construction and transition).  We then defined each of those and came up with a matrix to show which ones were mandatory or optional for each project type (major or minor release, service pack or hotfix).

We supported this matrix with a document that defined the different testing types, so everyone in the organization could speak the same language.  But after presenting it to the non-profit/smaller organization, I'm not sure lining them up to the traditional development phases will work for Scrums or Lean groups.  Inception, elaboration, construction and transition can be jumbled together and where one starts and one ends can be confusing. 


So with that in mind, I need to rework our methodology and adapt it to Agile and Lean development processes.  I think defining the test types is important, but I need to change when they should be run and what resources should do it.  As I go through that, I will update my blog on what we are doing and how it woks within and outside our organization.