Thoughts on test process improvment - Ownership and Commitment

Remember my list from a couple of weeks ago?

• Know where you are (Current situation)
• Know where you are going (Target situation)
• How to eat an elephant
• Learning
• Ownership and commitment
• Process first, then tools

Today: Ownership and commitment

Any successful process improvement is as I see it almost 100% depending on whether the people who has to “live with” the process  takes ownership, participates in the definition and implementation of the process and acts as ambassadors of the process for the remaining part of the organization

Here I would like to point you in the direction of the ADKAR  model (Awareness, Desire, Knowledge, Ability, Reinforcement), created by Jeff Hiatt. The model is a goal-oriented change management model which was developed to guide activities during the change process.

 

(ref. http://www.change-management.com/tutorial-adkar-overview.htm)

• Awareness of the need to change (culture, process)
• Desire to participate in the change and support it
• Knowledge of how to change
• Ability to implement the change within the day to day work
• Reinforcement to ensure that the change is kept in place

I like to use a combination of Ambassadors who can champion the process, super users who can support the implementation of process and tools, guilds and knowledge networks to create a forum for knowledge sharing and functioning as sparring partners and early feedback, and of course retrospectives on a regular basis to ensure that feedback from the projects are gathered and used to the continuous improvement of the process.

So here it is; my keywords and focus areas when I am a part of test process improvements... or process improvement in general. Focus on the people and on doing this as an iterative process.

Thoughts on test process improvement - Tools

Remember my list from last week?

• Know where you are (Current situation)
• Know where you are going (Target situation)
• How to eat an elephant
• Learning
• Ownership and commitment
• Process first, then tools

Today: Process first, then tools

We often identify tools to support the improvements we make, but the key here is that the process identifies needs for tools – not the opposite. Maybe a certain tool is given e.g. a certain test management tool is mandatory within the project. But we can still customize the tool to fit the process – not the opposite.

Involvement and ownership is again important here - involve the team and relevant stakeholders when identifying the needs for a tool; what value do we want from the tool, what requirements do we have. E.g. when evaluating a test management tool; Do we have requirements for traceability to requirements/user stories?  is it easy to access (yes I know this is not a testable requirement :-)), can we make the overview we need for our testcases? I don't in any way think you should write a requirement specification, but at least write down some checkpoints which are crucial for you (I think we had about 20 things) so that we evaluate the tools based on the same questions.

Evaluate several tools against the list, don't just take the one that comes first in a google search ;-) Talk to other testers, get inspiration from them - what tools do they use. I prefer getting my recommendations from people using the tools rather than people selling them :-)

At my current assignment we evaluated 5 or 6 different lightweight test management tools and ended up with two that we presented to the test team, from that we did our final selection.

This is one of the places where I would recommend the use of pilots; don't start introducing a tool using a big bang approach "as of tomorrow the entire organization will be using tool X to ensure test case management." We had a small project we could try it out with first, setting it up for them, introducing it and of course supporting the use during the first release. We also created a sandbox project that everybody had access to, thereby giving the people a playing ground where they could learn without being scared of ruining stuff :-)

  

We of course did some tweaking during the first project to make it fit the project, but after that we could reuse most of the lessons learned to create a setup to the main project and thereafter new projects to come. This is not "one size fits all", we created a basic setup to start up with, so that new projects shouldn't start from a blank canvas, but of course the configurations were customized after their individual needs.

When implementing the tool as a part of introducing the part of the process it supports  I think we need to focus on several things:

• Make the value of the tool visible - what will change and be easier?
• Ensure that sufficient introduction/training/information about the tool is given.
• Find ambassadors in the project, someone who can help advocate the tool if necessary, someone who is always present within the project rather than a distant support.
• Find super users in the project, again it is crucial that it is someone who is always present in the project so that help is close by.
• If possible - make your tools talk together! find tools that can do more than one thing :-) I our case we chose TestRail as a test management tool, and Jira for taskhandling and defect management - and for people it felt natural to work with the two together because of a good integration.

Thoughts on Test Process Improvment - Learning

Remember my list from last week?

• Know where you are (Current situation)
• Know where you are going (Target situation)
• How to eat an elephant
• Learning
• Ownership and commitment
• Process first, then tools

Today: Learning

Learning is both on an individual level and in the organization as a whole. As individuals we need to learn about the new process, we need new skills to follow the process e.g. learn about test design techniques because we now have a strategy about structured test and wants to ensure the most efficient testing to be done. About tools if new tools appear because of the changed processes and of course also changes in culture and responsibilities in the team and for the individual team members.

But also on organizational level we need to learn. We may take inspiration from the Deming cycle or  PDCA – Plan, do, check, act.

I am a big fan of pilot projects, let’s not implement the process improvements big bang in the entire organization, but rather create pilot projects where we implement and learn from the experiences we gain.

We plan the test process improvement project by creating the roadmap, breaking the project down into smaller tasks, creating a backlog. As described above we need to prioritize the backlog and identify quick wins. We plan how to implement it – identifying the pilot projects to involve. The pilots should also be a part of the prioritization of the backlog, they know the current situation better than anyone and can supplement our knowledge from the assessment.

Based on the backlog we do; create the necessary process to support the individual backlog items and we implement them in the pilot projects. Again I recommend including relevant members of the pilot projects and also other projects in the creative process of creating the process parts.  We also ensure that the necessary training is conducted as a part of the “do”, we need to ensure that the people in the pilot projects are “dressed for the job”.

When the pilot is running we need to move to check, supporting the pilot projects and follow up on whether the changes have the anticipated effect. In some instances we can define formal KPI’s for this check, but often interviews and retrospectives are more valuable – you tend to get more information and feedback during that than from a KPI.

Based on the feedback from the pilot projects we can now act, we need to improve what we have already created and make it support the feedback we got from the “check”.  And round and round and round it goes J now this is a cycle that runs continuously, an iterative process of test process improvement.