Testing "Big Picture"?

Hi all!

First let me introduce myself: my name is Erkki Pöyhönen (or Poyhonen for those with keyboards without funny dotted characters :-) and I come from Helsinki, Finland. Some might remember me as the EuroSTAR programme chair of 2004. I recently moved back into a consulting role after few years in a R&D management role.

I really enjoyed some of the posts in here, especially the one about the maturity. For most of the past decade I've been concerned about testing competence. That's why I'd like to share my recent quest to the testing big picture.

In large companies test teams or units grow an internal testing culture. It is a natural way to manage complexity: based on our experiences we learn self-evident ideas, what is important, what is possible, and so on. This means that after a while two organisations in different contexts (differing business situations, working with different technologies or producing different products) have developed different sets of axioms -- "self-evidents".

I suppose this really is natural and good for individuals and teams in general. The hard part comes from having to co-operate with other organisations or adapting to the changing conditions. If testers are not aware of their culture or their context, they might totally devaluate everything coming from a person from different organisation. This can be seen in attitudes into literature, training or cross-organisation co-operation; it is easy to dismiss quite valid outside information saying simply "that was not relevant for us; it is made for another organisations; we are special". BTW: good, welded teams share that elite feeling, so feeling special is not bad as such. It becomes a problem only when it prevents us to learn from others for being different in a vague way.

As discussed not so long ago in software-testing mailing list (a wonderful email list of the context-driven testing school with rather high S/N ratio; somewhat slanted to agile thinking) it might be more useful to have 5 times one year experience of different organisations than having a 5-year experience working in similar projects. I agree. And I'd add that working for both product and project organisations is useful, and working both in industrial setting and high-tech IT industry.

Working with one product year, year out (like in Telecoms used to be quite common) allows both testers and developers to optimise their approach and practices for efficiency. But for example changing into another technology can be a disaster. Or a test team might work parallel in tens of different projects for many customers in varied businesses. Of course the focus would be more into adaptability and learning, but achieving repeatable practices or sustained organisational improvement might be harder.

My newest project is building a repository of generic testing information that is useful for induction, competence development and process improvement. Building such a beast for any certain context is simpler: find the relevant sources and then assume this is good for us to know. Trying to be useful for a wider audience means: identifying context behind all sources and material, highlighting the assumed context-dependencies and sourcing the generic ideas from context-specific material.

Suddenly many common words are not so common any longer. Example: a test plan is for many "a reviewed text document, based on a template and that nobody reads". For others it can be a wall in the team meeting room. Or if the main constraint is delivery date it can be very unproductive to assume that quality is the driving factor.

Good news is that we need not fight over certain testing terms with religious intensity, if we identify we come from different contexts. It becomes more important to learn the "one step up" definition - what does this thing really mean, and not focus on how does it look like in different organisations, or "what do we ideologically hope this should mean for everybody".

It is easier to look for material supporting my current view than take the small extra effort to learn from sources of other contexts. But sticking to a strict "one testing" viewpoint takes energy, is counter-productive and prevents us from developing our industry forward. Widening my horizons and listening to (and getting to know) people from different industries has exactly been the biggest pay-back for me from attending testing conferences. And where else to do this better than in EuroSTAR again next December?