Kill your darlings and treat your tests more like cattle than pets, are among some of the heuristics currently around for managing your environments and automation test suites. These heuristics tells me that the environments and automation are in a state of product or even commodity, while previously the tests and environments where like darlings and pets – named and nurtured.
Continue readingQuality
Relations – are about half of IT
You can’t have IT projects without relations. Relations matter more than it seem.
Continue reading3 Visual Models on Quality
Besides the visualization of the delivery pipeline it can be a good idea to visualize your quality model. There’s more to it than V-model, Agile/Scrum and other old models. The following models are at least as established and practice based as any old book …
Continue readingExpectations around Testing
I usually mention that the work I do as a test manager is more around managing the testing activity, than managing testing specialists. “Managing the testing activity” to me is about:
- Identifying the expectations are around the testing activities
- Facilitating the performance/execution of the testing activities
- Administration and documentation of the testing activity
- Make the people doing the testing self-reliant
… in Context
The project context is the most important frame: it is all about the projects
story, risk profile, culture, traditions, deadline, budget etc. I am as Context-driven as contexts allow, in the classical “Seven Basic Principles of the Context-Driven School” sense*.
As I am motivated by finding solutions and making them work** my drive is more along the lines of “accelerate the achievement of shippable quality” [Modern Testing Mission] than “finding the problems that threaten the value of the product” [Rapid Software Testing].
Focussing on achievements over problems seems to work for me in the contexts I’m in, regarding enterprise transition, infrastructure projects and the implementation of commercial standard systems.
Setting a Frame for Expectations
Finding the “test solution” (or test strategy) that fits the project context is the key activity to me. The rest of it, is mostly about implementation – that too can be quite interesting. I like that too, but plan first!
First of all we have to realize that the testing activities we choose are limited and affected by or context (and biases). We can never test everything and think of everything to test. Based on the context restrictions (time, space, money, etc) the project gives me, I make a reduction of the testing theories and principles into a definition along the lines of:
In a specific context – testing will be a finite activity, to investigate if the shared interpretations of the requirements are implemented – at some time, for some configuration, evaluated by someone (that we trust), where nothing odd happens.
A reduction of the testing activity
Let me be the first to say: It’s not theoretical perfect! But it’s practical and based on context. The reduction gives me an achievable goal-oriented focus. It helps me to iron out what the relation is between the thing under test and someone whom it matters to.
Ironing out the Expectations
If there is an underlying risk that things will change a lot, then we can argue for test automation to multiply the configurations and the number of “runs” we can complete. Not all IT projects are around software development, so test automation practices and tooling might not be in place.
We can ask Open Questions to explore the boundaries of the shared understanding. We can discuss: how much total test coverage is needed here? We can challenge the requests for the kitchen sink – but also direct the testing to what matters. I have found that it is better to slowly impact the projects with questions from within, as discussed on the Guilty Tester Podcast, than break down traditions up front. We can look into “who” is doing the investigation and how much we trust them.
To make the agreements around the reduction of the testing activity explicit I establish a “Test Plan” document. I would often prefer to do without, and have a mutual team agreement – or even a mind map. But I know the enterprise contexts, too well to know, that shared expectations are best written down (even though it being an imperfective as well).
It’s all about the context and the expectations, really.
*: Even “CDT” is a context/model, and thus is flawed. One of the flaws of the model is that all test approaches are equally valid (as long as it adds value to someone who matters) and thus that no approach is never better than any other. Not even CDT..
**: See: Innovation in Testing, Less Software more Testing.
You don’t have to be a boss to be a leader
It’s really that simple, yet awesomely profound. And a typical Gerald Weinberg quote, like my other favorites of their points:
- No matter how it looks at first, it’s always a people problem (The second law of consulting)
- You’ll never accomplish anything if you care who gets the credit
- Things are the way they are because they got that way
- Quality is value to some person
Regarding the last quote; which was later extended with “who matters, at some time“. Once I had an argument about how to deliver quality. The other side held towards IEEE definition of delivering the expected. But even when they did, they failed to see that the unmeasured and irrational parts affected the value to the customer. I agree completely with The Cowboy Tester that knowing works of Weinberg is a measure of seriousness.
Weinberg worked not only with testing, but among other things also consulting and organisational change management. I did not know that when reading “Making Sense of Change Management” (Cameron & Green 2012). I literally jumped up and started laughing while reading the quite serious elaborations to the Satir Change model – the authors found that Quality Software Management: Anticipating Change (1997) is a “masterly book on change, but with a title that might not appeal to everyone“. It might not appeal to change scholars, but definitely appealed indirectly to a lot of people in testing.
Recently (August 2018) Jerry died aged 84. Not a boss – yet a leader.
Diversity is important for testing, prejudice isn’t
I want the field of testing to have high diversity
- Different personality types:
- we need people to get ideas, and people to finish them
- We need people to see the strategic view, and people to get into the details
- Different backgrounds
- We need people that can code
- We need people that understand the business domain
- Different business domains
- We need testers in the field of software development
- We need testers in the field of IT / ITIL service delivery
- We need device testers, embedded software testers….
- We need testers that understand the GxP regulations
- We need testers that understand rapid and agile delivery
- Different people
- Parents, singles, people with kids and without
- Young people, experienced people
- People who take it as a lifestyle, and people to whom it’s just a job
…most of all people. People who knows that things can be done in many ways. Let’s get rid of the prejudices that testing is for the detailed and i-dotting only. Testing is about bringing information to the stakeholders about what works and what doesn’t – it’s never about “failure is not an option”.
Recently I was required to do a Cubiks Problem solving test. It’s a 12 minute online test in word patterns, calculations and geometric patterns. Apparently I “failed” to complete all in time, but had a high degree of right answers, so my score was “average” #whatever. That apparently made me perfect to the testing area… OH NO – it only tells you that I put pride in my own work. Everything else is pure speculation and prejudice, as mentioned by Gerry Weinberg in Psychology of Intelligent Problem Solving there is a challenge with these kinds of tests for problem solving – they test, but not for problem solving.
Testing is about solving problems – business problems. Like can we ship?
See also:
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
…
Softwaretesting is only dead, if it stands still
[ Software Testing Club Blog | January 23, 2012 ]
Here are some quotes from actual test mission statements from the last 10 years. Test always is changing. Come to think of it, it’s only dead if it stands still.
2003
We discover and measure the quality of the system:
– to test everything is utopia,
– we should test something, something new, something old (and something blue?)
2006
The primary objective for testing is to reveal the quality of the delivery. The revealed quality is documented in test reports, that serves as suggestions for decisions on approval or rejection of the delivery. Key principles: early involvement, structured testing, based on V-model, documented, COTS tools (TestDirector)
2008
Testing is the structured activity of identifying the quality and improving the quality of the an IT-supported product or project
– Identification of quality = Preparing and executing a test activity
– Improving the quality = Evaluation, fixing and retesting of raised incidentTest provides information about the quality of IT-supported product or project, with that information:
– Quality of products can be improved
– Project decisions can be based on facts
– Processes can be investigated for improvement
2011
Testing has the mission of providing information to the project about the quality of the business features of the solution.
Testing is about learning about the quality solution, not about confirming, verifying or assuring.
Test is about adjusting, not about following a strict script and knowing everything up front.
Originally at my SoftwareTestingClub blog – more from my STC Blog here: All oracles are failable, Testing decommissioning of ICBMs and software and Testing a new version.
Complexity is a Matter of Perspective 