The business side can be hard to read. Also coming from the back story that testers long for objectivity – and “just” want to state the facts for the decision makers. I know, I’ve fallen into that trap many times.
We need to be able to read the business strategy and prepare the test strategy accordingly... and business decisions first.
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’sworktowardsbetterdealsfortestingactivities. 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.
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”.
Good testing is much more than confirmation of explicit requirements. It’s figuring out the implicit requirements, what blocks the business and what drives the business. Businesses are not driven by SDLC’s but by decisions and strategies. IT road maps are just a representation of the business strategy, an engine to build business solutions on. The is much more to the business than the software solutions and related risk mitigation.
Very often the biggest business risks are outside the project scope. When we look at it this way we see that testers and testing activities has an opportunity outside the classic project life cycle. Testing is about experimenting with a IT solution, to evaluate if it fits the business requests. IT solutions that supports the business exists in many forms, I am certain that explicit testing (*) can add value in other parts of the IT landscape.
Here is a model of an enterprise IT landscape consisting of business ideas, solution development, operations and end user devices + support. Solution delivery is boring in the sense of well-known software creation and maintenance. What if the item under test and the requirements are around network, servers, end-user devices and IT support tickets. I am certain that it’s valuable to test business cases before the project is even formally assembled.
TL;DR: Testing is always something that we choose to do – and how we test is similarly a matter of choice. As is Christmas traditions. .. it’s just man-made rules, we can choose to change them.
So I was discussing what we should have for Christmas with the stakeholders. One of them wants the traditional rice pudding, the other wants – untraditionally: chicken. And you know what – that’s ok. Traditions are guidelines, not rules – we can make new traditions, just by choosing to.
Testing in production used to be a great no-no. I’m still feeling odd when we do it, but I have come to see it as another tool of the trade. It has a name now “testing in the wild” TTitW as has been presented at EuroStar 2015. Also this is how Netflix have been testing for years, from GitHub, as it is open source too (!).
You might argue that changing testing (in the wild) is not allowed. I will challenge that assumption – being allowed to do something is a choice too. You choose to follow the the process frameworks, requirements, rules… and you can choose not to. The tradition of manual predefined testcases are so four years ago!
Sometimes it’s just a matter of saying up-front, that you are tailoring the process. So choose an approach that actually gives meaning and value to the stakeholders and context. Deconstruct the traditions and commercial bodies of knowledge and make some new!
I wonder if… the Norwegian and Swedish texts are correct on this picture:
“I wonder if“is surely among the things that I as a tester say or think a lot. You will also hear me cheer when we find a critical bug. Every defect / bug / observation / issue / problem / incident we find is our chance to learn about the product. It’s a natural part of the game to find things and then to handle them. Defer them if so inclined, mitigate the risks, fix the bugs, update the processes – but always take a decision based on the new knowledge you have.
Yes I could, but the thing is it would need longer runs. I run with the Running Club Tuesdays and Thursdays before dinner. As a simplified example – if dinner get’s delayed the kids won’t eat as well, then they can’t fall asleep – and will need to eat past their bed time. They will sleep too late, and we (the parents) will have less time to the evening chores and being together. Every time there is something I’d like to do, there is always something else that matters that doesn’t get done.
“Come to X-conference – it’s just a matter of priority if you’re one of the ones”
Sure, it is – that’s easy for you to say. But €2000 + travel is out of my private pocket, missing work hours is out of my pocket, being away from family is out of both my time and their time. And really €4000 is a lot of money in a family with two kids with special needs – where the income is one job, one early retired. Also it’s a stupid argument, as I can point to heroes of testing that I consider “one of the ones” that like me aren’t going to both this and that.
I can do a Test Bash, write blog posts* and articles for the Testing Planet etc.
Discussing relevance of testcases, user stories and requirements is an age-old challenge in IT development. Sometimes we think we know the usage of our software so much better, than the users – that we laugh and say: That would never be the case. But it may very well be.
”The reason for undertaking the largest national construction project is so that the capital region can get fresh milk.” That’s what the minister of transportation said [1] – and oh we laughed. Why would we invest billions, 7 years and 18 km bridge so that one part of the country could supply fresh milk for the other (that had it’s own dairies).
A commercial[2] for a dairy snack (oh the irony) later alleged that this decision was made on an empty stomach[3]. But it wasn’t – with regular ferry service since 1883, the people wanted to cut the time from 90 minutes to 15 minutes, with all the added benefits of increased trade, travel and traffic.
The link opened in 1998 and a stormy night in 2006 the bridge closed for traffic. No big deal – it happens. It so happened that it closed for 22 hours. And hence the ecological milk dairy on the ”countryside” couldn’t deliver milk for the ”capital” side [4]. And the scenario from the minister of transportation had become no laughing matter.
Quality comes in all shapes and sizes .. like Christmas trees. This Christmas I was out selling trees at the local “shopping center ” with my oldest.Most left with a tree that satisfied the acceptance criteria – explicit as well as implicit – yet still no one came with a requirement spec…
Heuristics from the merry christmas tree salesmen:
The tree looked at first – is usually returned to and bought
Do A/B split testing between one or two trees
Too many options makes selecting even more confusing
One family’s reject – is another family’s perfect fit
Context is important – like how much room inside, how many people, how many kids
The closer to deadline – the less options
No one notices the wicked branches, when the music plays and the tree is lit
After christmas it doesn’t matter how picky you were with the details
A young person came to us looking a bit puzzled – they had never bought a tree herself, and the tree been bought was not for them. All they knew was that they had volunteered to do charity help to a down-and-out family. They wanted to purchase a tree for christmas – but could not their own home. I can only guess that this specific christmas tree was the family’s perfect tree. The cost didn’t matter to the young person at all – but the implicit value even more.
Many decisions are never about the monetary (sunk) costs. Hence your customer makes seemingly odd decisions – and that’s OK.
Complexity is a Matter of Perspective 