Getting Testing in Early

Even before there is an “system development life cycle” – testing in the form of thought experiments and  evaluation can take place and add valuable information to the context.

My test management tasks are often about the next thing coming up. Bids for outsourcing agreements and application development often comes with a large document of test activities to be answered and elaborated. In this role I am the the subject matter expert (in test), and while have to write the tender reply for my domain. Sometime down the line the bid materials becomes an actual project, but by then I’m onto the next thing.

Sometimes I draw an analogy to the Secret Service advance team arriving two weeks before the president, setting up protection and identifying gaps – while then moving on to the next location before the president even gets there.

Another example of advance work for test people, is where the organisation uses frequent releases of systems. While the majority of the test effort is put into the release currently being tested, some effort must go into looking into the frame of the coming release. In the coming release the test manager can look for headlines to test, review initial high level design and find flaws and conflicts in the release content.

Sometimes I draw the analogy to the blue and gold teams of US nuclear submarines. While one full crew is out sailing/delivering, the shore team prepares, trains for the next big push.

Testing early can also be in the form of running simulations on various business case scenarios. Business simulations is all about experimenting and evaluating. For novel solutions prototyping, wire-framing and user experience activities helps develop minimum solutions to be tested for viability by the customer.

In the article “Continuous Testing in Dev Ops…” we see testing happening during Plan and Branch. In the article “A Context-Driven Approach to Delivering Business Value” testing can help establish viable market, match to vision and in identifying business risks.

testing related to revenue generation may focus on functionality or regulatory compliance; testing related to revenue protection may focus on maintainability or legal defense; testing related to supporting revenue may focus on business process improvement or cost reduction.

Testing is a lot of things – also outside the SDLC.

 

Value of Information for Decisions

If you ask “what is the ROI of context-driven testing” it is the same as asking:

• What is the value proposition of providing information to the stakeholders?
• Will management and customers pay for information?

Let me tell you a story: Just today I finally got around to changing tires on my car. Three months ago I bought a campaign voucher for a cheap switch of winter tires to summer tires – so it was about time. I booked a time and went to the shop with the summer tires in the trunk. BUT then … the front tires where out of shape due to wrong “tracing”, brake cables and other stuff worn and empty for lubrication. sigh!

So … the shop had to repair those critical defects (yeah, the vouchers a good business generator, #I’mOKwithThat). They gave me the keys to a replacement car for the day for free. And we discussed fixing some other stuff – the tricky ignition was Deffered/FixedUpStream but the defective brake lights added to the work order (New bug raised due to a hunch). I got an estimate and went for the day. The quote was pretty close, the repair on time and the requirements verified on the release bill. 

And then they provides me with a list of a few things they noticed along the way. 

• I probably paid for an automated test and configuration of a “trace” balancing – I assumed it there.
• We did discuss scope, price, schedule and timing – along with bug triage
• The shop did provide me with enough information and estimation up front to base my decisions on
• As the product owner I did not pay directly for the list of test ideas not covered – but I appreciated it!

The shop could have just swapped the tires for the voucher cost – and noticed nothing else. They could have chosen not to tell me about the additional bugs. They could not have offered me a replacement car for the day. They probably where more expensive than a moonlighting garage dude – I known now what the difference can be.

I value that they provide information to aid my business decision-making – besides just swapping the stupid tires. They will probably get repeat business from me – directly or indirectly. 🙂 And yes, Scott, they did have free coffee

Without Timing – Quality, Schedule and Cost is nothing

A project usually has to be on target on Quality, or at least on agreed quality. 

A project usually has to be on Schedule, or at least on agreed schedule.

A project usually has to be on target regarding Costs, or at least agreed costs.

It is an ancient IT project manager mantra, to control these parameters using change requests and change management – typically due to events during the project. It takes to long, it’s too buggy, it costs more etc. etc. To change one parameter – you have to change one of the others. In example (and strictly in some context) – even adding more testcases will increase cost or influence the schedule (discuss).

But there are plenty of examples (of Government IT projects) that are on schedule, on cost, on quality – yet they fail the timing and after a number of years delivers a system on an obsolete platform [true story]. More recent examples – bank D launches their banking app first, get all the press – and a month later bank N comes around – on agreed schedule, agreed costs, agreed quality… and get very little of the “hype”.

When contemplating the business decisions – what seems right now right now might be wrong later – considering the Timing.

Acceptance criteria are more than what can be measured, An Expected Gathering

…

I’ll fix this later 🙂

Workshop facilitation using LEGO

As well known, LEGO is synonymous with “Play well” – for both kids and AFOLs. But seriously, LEGO is more than that, consider:

[LEGO Serious Play]

LEGO SERIOUS PLAY uses LEGO bricks and elements and a unique method where people are empowered to “think through their fingers” – unleashing insight, inspiration and imagination. In a very direct way, you will be able to see what everyone knows inside the company – and what they don’t know they know! Within a surprisingly short time, an organization can have a clear, shared direction with people who are confidently aligned and committed to a course of action.

[ Lean LEGO – The red brick cancer ]

If you would build a LEGO time line of your processes, would they be mostly red and yellow? Or would they be mostly green?

Besides the  Build a Tester Workshop where I elaborated on how LEGO mini figures could facilitate a discussion on both tester types and team skills. Recently I have had the personal opportunity to participate in a facilitation training, where LEGO bricks and figs was used to illustrate team members, represent user personas and user innovations. So the thing is – what do you need to get started? Choose your pieces by context: Customised Minifigures, city people or a huge pile of bricks?

I’ll fix this later

from http://geekandpoke.typepad.com

Innovation is about the unknown – deal with it

Innovation and software testing is about the unknown – deal with it!

[ The Biggest Obstacle to Innovation? You. | May 11, 2012 | HBR blogs by Leonard A. Schlesinger, Charles F. Kiefer, and Paul B. Brown ]

when you are leading innovation, the world is anything but predictable. You are creating something that has never existed before and so you simply don’t know how the world is going to react. By definition, innovation deals with the unknown.

And that’s why you are the biggest problem when it comes to innovation. If you keep using prediction reasoning in situations that are simply not predictable, you’re bound to be disappointed and frustrated.

You need a different way of thinking. 

See also More standards are not the solution, What you have learned becomes irrelevant, todays innovation becomes tomorrows commodity

What you have learned becomes irrelevant

[ Share more, Learn more | MARCH 18, 2012 | Henry Singer ]

the shelf-life of the body of knowledge for a particular technology is growing ever shorter

what you have learned in the past becomes increasingly less relevant

we need to change the balance of our time spent learning, doing and sharing in favor of sharing and learning

to continue to perform the work and deliver the services that are in demand

See also Work Smarter, not Harder, todays innovation becomes tomorrows commodity

Seriously joking or joking seriously

If joking is only taken jokingly
and seriousness only seriously
– both of these, it seems to be,
have been taken too literally

[Danish saying by Piet Hein, my translation]

see also for heaven’s sake, don’t make any changes to our mother-ship

The weekend formula

The more people that are in their pajamas after noon, the more weekend.
The more laundry to sort, the more weekend.
The more the boys play with LEGO trains peacefully in the morning – double the more weekend

But Where is Perry?

See also [DK] Om at kunne udsætte sine egne behov

The most well-known person from Denmark is