February 1, 2014
Family and fun, LEGO, Softwaretesting
change, coffee, decisions
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  – and boy 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 for a dairy snack (oh the irony) later alleged that this decision was made on an empty stomach. 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 . And the scenario from the minister of transportation had become no laughing matter.
Your user is not you - http://www.developsense.com/blog/2013/12/your-user-is-not-you/
The baristas wept as there was no ecological skimmed milk
1: DK video: http://larslars.net/blog/2009/04/derfor-fik-vi-storeb%C3%A6ltsbroen/
2: Similar to this one http://www.youtube.com/watch?v=b2UrushQ86I
3: Why being hungry is bad for decision-making http://blog.bufferapp.com/8-things-you-dont-know-are-affecting-your-decisions-every-day
4: DK text: http://www.landbrugsavisen.dk/Landbrugsavisen/2006/5/26/Ingen+frisk+maelk+over+Storebaelt.htm
January 2, 2014
Autism, Family and fun, Softwaretesting
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 woman came to us looking a bit puzzled – she had never bought a tree herself, and the tree been bought was not for her. All she knew was that she had volunteered to do charity help to a down-and-out family. They wanted a tree for christmas – but could not themselves. I can only guess that this specific christmas tree was the family’s perfect tree. The cost didn’t matter to the young woman 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.
See also: Acceptance criteria are more than what can be measured, Look for Minimum Viable Testing, Without Timing – Quality, Schedule and Cost is nothing, Value of Information for Decisions , 16 points that may rock the boat, When do testing happen? Are you looking too hard
December 13, 2013
Enterprise IT, Softwaretesting
atWork, collaboration, communication, exploratory, knowledge, learning
A key driver in implementing enterprise knowledge management is to reduce time to information (77% are seeing faster access to knowledge). But that goes for LinkedIn and Twitter too. Using twitter professionally helps you meet the famous people and help you see the communication layers at conferences. Case story: Today I was reading about test processes in a regulated environment, and got curious towards exploratory testing in that context. So I reached out to the #twitterbrain and asked the giants, whose shoulders I am standing on*:
- Griffin Jones @Griff0Jones, help clients struggling with regulatory compliance and context-driven software testing problems.
- CAST 2011: Cast 2011 What Do Auditors Expect From Testers
- What is good evidence – Let’s Test 2013
- WREST – Workshop on REgulated Software Testing
- Johan Åtting @JohanAtting Chief Quality Officer -atSectra’s Medical Operation
- turned the testing from a traditional scripted approach into a context driven approach and introduced exploratory testing.
- ensuring that the company are regulatory compliant with e.g. FDA, MDD, CMDR, ISO13485, ISO14971 etc.
- James Christie @james_christie
- interested in testing’s relationship with audit and governance.
- dedicated to the audit, control, and security of information systems.
- Michael Bolton @michaelbolton Program Chair of EuroStar 2013 and key guru pointed me to an article by James Marcus Bach @jamesmarcusbach on the topic.
- Keith Klain @KeithKlain Head of Barclays Test Service retweeted on the fallacy on the evidence of scripted testing.
- Claire Moss @aclairefication (my favorite retweeter) and many others retweeted
Within 2 hours I had both relevant references, a debate on the pitfalls and base for further details. Follow the tread of this tweet: https://twitter.com/jlottosen/status/411473074312052736
*: really, not to brag – I have met both Griffin, Johan and James, and they know me too :)
December 13, 2013
AlsoOnFlickr, atWork, context, itil, solution, value
Reading some quality process documents I found the following definition:
- To detect and remove errors before the computer system is put into production
- To demonstrate that the computer system is fit for intended use
But when we look at the ITIL definition of the value composition of a service – it looks fit for use, as above: follows the requirements, sufficient - what the customer gets. But also – at an equal base, it looks at fit for purpose: it has a positive effect on the business, it solves a business problem, solving the right problem. The product is a solution. If the problem isn’t solved, the product doesn’t work.
see also: Uncovering better ways Softwaretesting is only dead, if it stands still I didn’t open it
November 20, 2013
Enterprise IT, Softwaretesting
agile, atWork, business, change, context, cost, decisions, exploratory, gofigure, leadership, unknown_unknown, value, wicked problem
I am uncovering better ways of developing solutions - by doing it and helping others do it. Through this work I have come to value:
- Apply the costs to add business value – over cutting costs
- Being flexible and open – over adding predictability
- Providing information for decisions – over ensuring the reliability
- Solving the right problem - over solving it the right way
- Seeing the end result - over being nit-picky and detail orientd
- Suggesting examples and cases – over having one-size fits all
- Do something good enough – over doing something perfectly
- Get something shipped – over achieving total coverage
- Being prepared for change – over following a script
- Share information and connections – over hoarding and hiding
- Appreciate good efforts – over taking things for granted
- Trust and empower people – over controlling
- To lead and help – over managing
- Challenge and question – over keeping quit
- Suggest and discuss privately – over critiquing publicly
- Being empathic - over focussing on rightfulness
- Quality as a relationship - over quality as fixed attributes
- Training and mentoring - over certifications
That is, while there is value in the items on the right, I value the items on the left more.
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
November 16, 2013
brain, communication, conference, goto, gotoaar, knowledge, unknown_unknown
Key takeaways from [ Presentation: “ǝnןɐʌ: Why we have it backwards” Track: When the Agile Manifesto isn’t enough | Shmuel Gershon | GOTO 2013]. Special mention for the best hand-made/home-made slides – get them here.
Software is a knowledge storage medium
Think about it – where do you have your know-how, your calendar, your to-do list, google it… IT is the digital tool we use to store our knowledge, to enable us to do the things we want to do. Shmuel has a great historic overview over the evolution of places to store knowledge. IT and software as of now has among other things the ability to be updated fast, to tell about the intention of the solution, the ability to self-modify and change the outside world directly.
We can start using the word knowledge more:
Value is often to learn something new
November 16, 2013
Enterprise IT, Softwaretesting
agile, atWork, business, decisions, goto, gotoaar, mvp
Key takeaways from [ “Why Agile doesn’t scale, and what you can do about it” | Dan north (@tastapod) | GOTO Aarhus 2013 ] If you want the full version see his full slide deck here.
Being agile is about getting something out the door – it’s very good in doing SHIP IT - Tweak it – think it build it. Wax on – wax off. Being agile is about people and tools and is a great approach for problems that allows to be solved with these borders.
The challenge is in the more complex domains with a bigger solution, a bigger problem, a bigger program with many people, many dependencies, many teams. In these (NP?) problem domains other factors come into play: Governance, Customers, Money and the organization as a whole (see slides regarding Agile Adoption Patterns).
In the later contexts agile as a delivery model doesn’t scale without project governance and portfolio management to oversee and prioritize based on strategic returns on investment. Shipping any minimum viable product from time to time in a larger context requires more oversight on “are we nearly there?” “are we ensuring delivery?” “are we ensuring credibility?” .. are the many global teams going agile in each their direction?
The same goes for the testing efforts – agile scales to a certain point, and at that point the scrums, the state-models and so on are a part of the solution engine. It’s what’s tests something, but with size comes the need to know why we make the decisions we make – and are we there yet?
Disclaimer: GOTO Aarhus 2013 is sponsoring my attendance as a blogger.