Don’t request the kitchen sink

More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.

These are the phases of a recent project:

  • Environment Acceptance testing
  • Hardware and integration testing
  • Component testing
  • Component- integration testing
  • Installation test
  • System testing
  • Functional testing
  • Regression testing
  • Security testing
  • Performance testing
  • Operational acceptance testing
  • Service Level testing

It’s a challenge in the vendor reply. The vendor will want to reply to all test phases in order to be compliant with the tender, and not loose points. There is no room for elaboration or discussion if you want in on the bid process.

Quite often the requester comes back and say “we didn’t want all those weird testing things, we just want something that works for us”. But when the contract is signed and the work set in motion the project team have challenge to make the testing practical within the framework of the contract. This goes from both sides. Many good hours can be wasted with unwinding cumbersome contractual terms.

What I usually do in such a situation is to bundle the contract’s testing scope into fewer activities, and setup a mapping so that everything is covered. That is if the client allows me to make the activities practical and context-driven. If not – my hands are tied, and we deliver according to spec – even if the chapters of the test plans are set in stone.

Let’s work towards better deals for testing activities. If you are looking to prepare a BID include a test manager – and have a discussion of the value-add and learning of testing up front. There is no one book of how to do testing. Instead spend the time and money figuring out your context. Figure out what phases are on the client side, and what is on the vendor side. Have a test management consultant on retainer for before and after the bid process. Do something to discuss your test strategy and put the guidelines in the contracts, so that the vendors can propose a solution.

Don’t request everything and the kitchen sink too

Everything and the kitchen sink
Everything and the kitchen too

 

 

Advertisements

Test ALL the things

TL;DR: We can add testing to all requirements and all business risks. Testing to document requirements and to debunk risks provides valuable information for the business. Let us not limit testing to things that can be coded. The intellectual activity of trial and learning is happening anyways, we might as well pitch in with ways to find important evidence for the decision makers.

Test all the requirements

Traditionally testing was all about testing the functional requirements that could be coded. Non-functional requirements was left for the specialists, or plainly disregarded. I know I have done my share of test planning, with a range of requirements left “N/A” with regards to testing. Especially performance scope, batch jobs, hardware specs, data base table expansions and virus scanning have been left out of my functional test plans…

When I look at a list of requirements now – I see that we can indeed test all the things, or we can at least work on how to document that the requirement is fulfilled. Some of the requirements are actually quite easy to document. If it’s on a screen somewhere, take a screen shot and attach it to a simple test case. Done deal really. Additionally with a testing mind-set I can think of ways to challenge the details. But do we really, really need to fill up a disk to establish if it’s exactly a 1 Gb allocation – probably not. Do we really really need to document all requirements – yes in some contracts/contexts it’s important for the customer to know that everything has indeed been established. Sometimes the customer doesn’t trust you otherwise, sometimes the tests are more about your ability to deliver and provide evidence that matters.

Test all the business risks

Look into the business case of your project and find the business risks. Sometimes they are explicitly stated and prioritized. A a recent Ministry of Testing Meetup we looked into a case for a large national health system. We looked at the tangible benefits, intangible benefits and on the scored business risks.  What worried the business and management most was budget, time and whether the new system would be used in a standardized way. There is an opportunity for testing here to help address, document and challenge the most important business  risks. Traditional testing would usually look at functional requirements that can be coded or configured, and miss totally to address what matters most to the business.

OK, how do we test the project costs? How about frequent checkpoints of expected spending – would that be similar to tracking test progress. Perhaps – let’s find out. Testing is all about asking questions for the stakeholders and solving the most important problems first. Can we help to analyse risks and setup mitigation activities – sure we can. We just have to step out of our traditional “software only bubble”.

MEME - Test ALL the things
Meme ALL the things

 

 

 

 

 

 

 

Read also: Many Bits under the Bridge, Less Software, more TestingTest Criteria for Outsourced SoftwareThe Expected, Fell in the trap of total coverage.

Links: “A Context-Driven Approach to Delivering Business Value”, Cynefin In Software TestingTesting during Application Transition Trials

 

Create, Maintain, Move and Close

Usually when we talk testing it’s about the road to production. It’s about getting requests from the customer/Product owner and shipping it. We tend to forget that there is more to the life cycle of application than adding to the pile. Inspired by the old CRUD I identify the following stages in the application life. Create, Maintain, Move and Close. Testing can add value all of the four modes, with twists for each one.

Create: “oh shiny” – Creating an application is usually novel, but the more times you have build similar applications it becomes routine. Some applications have to be build from scratch, others merely configured. It matters a lot if you are building a unique app – or if it yet another roll-out of a COTS application. The testing in “create” usually focuses on bugs to be fixed before go-live, and very little on what happens afterwards. Building a new  application is usually a strategic decision to the business that solves a problem or builds on a potential. Requests are numerous for new things.

Maintain: “ship, but don’t destroy production” – At some point the customer sends you more requests to the stuff already build than new features. Application maintenance is all about balancing new features and updates to existing features. Existing features are being used by the end users, and they will eventually request updates and bug fixes. Fragmentation, merging and branching becomes and issue – especially if you maintain the application as a solution for a range of customers. Customers might want to differentiate between their requests – as they won’t want to pay for bugs in previous releases, but rather want to pay for new additions.

Move:  “It has to work as before, just with a new team“. To many businesses maintaining an application is not their key area; They might be a public organisation with no need to have their own staff of developers. So “Application Outsourcing” becomes a thing for many applications, and with deals being won and lost – it will happen that  the development tasks moves from one supplier to another. Testing can make sure that processes are in place in the new location and that the state of the application is known in the new location. The testing during “move” doesn’t involve the functionality of the application, but rather the ability of the new team. Sometimes the hosting of the application stays they same,  in other cases it is the hosting of the application that changes and nothing else.

Close: test that it’s gone” Sometimes IT strategies and businesses decide to close down an application. Perhaps it’s being replaced, perhaps it’s redundant after a long time. Examples could be hospitals moving from one patient journal to another or whole systems being sunsetted. It could also be the closing of end-of-life applications (Windows servers, HPQC etc). The value to the business is knowing the application is gone, and the information in the old systems not trusted anymore.

It is very much possible to have testing in all modes of the application life cycle. Similarly it is very much possible for testing to add value in all stages of the software development life cycle. It’s a matter of perspective.

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.

 

Writing myself a new car

I honor of the World Autism Awareness Day 2017: I have reward systems for myself and my two sons with autism. The principles are as follows:

  • Reward the behavior we want more of. Don’t reward required activities, but reward when we choose to do help with chores. Ignore when we choose not to, do not remove credits.
  • Rewards are things you would not get otherwise. Verbal praise and encouragement are given even so. You have to earn it – and get it when you finalize (a deal is a deal).
  • We use token economy and postponed gratification. Training for the mash mellow test improves forward thinking.
  • Rewards are usually LEGO. Specific piece request from Bricklink.  Every token/mark is a ten’er (DKR 10).

The boys (13+11) have been rewarded for doing the dishes, preparing food, taking out the garbage etc. Initially 15 tokens gave a trip to McDonalds, but as mastering progressed the rewards became bigger. One time 50 tokens/marks was needed for a reward. The options to help (“The Mark Menu”) was at one point over 20 chores. Over time they lost interest in saving but did the chores anyway, so some of the chores where made required. One day the oldest added “Do not fight” to the list of required (non-rewarding) activities 😉 Next up is to save for a game on Steam..

I’m being rewarded every time I run (5K, outside. Half a mark for treadmill), for my morning exercises and a few other thing I struggle with. I have just finished a sheet of 140 marks that I worked on since September 2016). The new target is to buy myself first a Bugatti and then a McLaren. Not a new minivan..

I am going to write myself a new car

I hope this drives the right behavior

Similar posts on leadership and praise at work: In a star team – the team gets the starsI know it is your job – but thank you anyway

Similar posts on autism: Pragmatic choices of what is important and possibleStakeholders,

Similar posts on drive and motivation: More than carrots and sticks, 16 points that may rock the boat

Many Bits under the Bridge

I’ve been in the testing business for 14 years – when I started in late 2002 it was all about using HP Test Director 7.6 – in a browser… There was only one model of testing, v-model, and only one book of testing the ISEB (later ISTQB) vocabulary. And only one expected output of testing: Testers designed test cases, executed and perhaps wrote both a test plan document and test report document. Test process improvement was a thing, but even so testing was often a pointy cog…  

Many Bits under the Bridge Later

It is not about the test cases any more, it’s about being part of a team – that delivers an IT solution to the business. First of all, if it’s just about the test cases then it is a race to the lowest paid off-shore location, a run to the bottom in repetitiveness and mechanic activity. Checking! with more focus on crossing the t’s and dotting the i’s. We have tools for that now – the plates are shifting.

When testing professionals puts “writing test cases” on their LinkedIn description. It seems to me that they are stuck in the testing world of 10 years ago. Standing still and not seeing that Testers are Knowledge Workers – not workers of producing artifacts. It is much more important to see beyond the visibleUncovering better ways and seeing testing as an activity to provide information to the stakeholders, based on experiments and observations.

Skill up and be smarter! And don’t listen to old tapes – it’s not worth it :).

See also this from QA Symphony & Ministry of Testing:

The Software Tester: Modern vs. Traditional [Infographic]
The Software Tester: Modern vs. Traditional [Infographic]

Co-creating smarter testers

Co-creating smarter testers” is the byline of the Ministry of Testing, a small company with a great impact that I have been following and supporting for 7 years* now . I have attended TestBash’es, webinars, challenges, discussions and memes. And now for the first time in Denmark – Anders Dinsen and I are bringing the world known Meetups to Copenhagen (Aarhus 2017 you’re next).

Ministry of Testing – Copenhagen

Copenhagen, DK
224 Members

The Ministry of Testing exists to advance the software testing industry in a fun, safe, professional and forward thinking way.Our meetups exist as a way to bring people toget…

Check out this Meetup Group →

The topics so far are:

At the first meetup we split into three groups, discussed risks and how to TEST THEM RISKS. Dearest to me was the discussion of stakeholders and new places to test. Great to see that even with very little information, we can still do a rapid testing based on business objectives. There is so much more to testing these days.

600_457785753

1: since a EuroStar 2010 t-shirt competition 🙂