Shoot, Neglect or Train?

How you treat the bringer of (bad) news tells me a lot about the organisation and potential for business growth. Go Read Accelerate – that book is full of insights. One of the models, is the organisational types from Westrum:

[ Screen capture from the Kindle issue of Accelerate ]

Andy Kelk has a to-the-point description about Westrum on their blog:

To test your organisation, you can run a very simple survey asking the group to rate how well they identify with 6 statements:

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture

• On my team, information is actively sought.
• On my team, failures are learning opportunities, and messengers of them are not punished.
• On my team, responsibilities are shared.
• On my team, cross-functional collaboration is encouraged and rewarded.
• On my team, failure causes enquiry.
• On my team, new ideas are welcomed.

The respondents rate each statement from a 1 (strongly disagree) to a 7 (strongly agree). By collecting aggregating the results, you can see where your organisation may be falling short and put actions in place to address those areas. These questions come from peer-reviewed research by Nicole Forsgren.

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture

So when a passionate person comes to you with (bad) news, what do you and your organisation do? Do you reflect, ignore or hide the request? Do you say that it’s not a good idea to bridge the organisation? Do you raise an Non-conformity and set in motion events to bring “justice”? Do you experiment to implement the novel ideas and actively seek information?

FAIL = First Attempt In Learning.

A 30 Days Agile Experience

In September 2017 the Ministry of Testing had a crowd-based knowledge sharing event called “30 Days of Agile Testing” with a small learning activity for each day of the month. As with the similar security event I set up a weekly schedule at work to meet for an time-boxed hour and discuss 3-5 selected topics each time.

Our score was 17 topics discussed – some more discussed than actually tried out. Hence the half marks on the poster on the window below. Me and my coworkers work on many different teams – so to dig into specific team tools and processes was out of scope.

Here is a few of our findings:

• Day 3 – YouTube is full of videos on agile, but our Chinese colleague cannot view them. They can though view videos locally on the Dojo and TestHuddle.
• Day 4 – We discussed the Agile Manifesto in relation to GxP/regulated projects. GxP and agile can work together, when you control your deliveries with for instance ATDD. See DevOpsDays Seattle 2017: Continuous Delivery Sounds Great But … and How to build agility into a regulated project?
• Day 12/26 – We need the test cases in many contexts, but do we need the Test Plan specifically. Perhaps we can reduce the test plan to “Requirements/scope”, “test cases” and “staffing” as in Plutora Test.
• Day 13: Perhaps not an IDE, but then learn some other technical tools that is not automation: See 30 Days Of Agile Testing! Day Thirteen and 6 Technical Testing Skills that Aren’t Automation
• Day 18 – Put the testers and test management tasks on the sprint board. Adjust the burn down for part time people. Keep all testers and other people in the project in the loop.

Links to “the Club” on some of the topics we selected:

• 30 Days of Agile Testing, Day 1: Agile testing books
• 30 Days of Agile testing, Day 2: Mindmap of what agile testing is
• 30 Days of Testing – Day 3 Videos
• 30 Days of Agile testing, Day 4: The agile manifesto
• 30 Days of Agile testing, Day 8: Talk to a developer, rather than creating a ticket
• 30 Days of Agile testing, Day 12: Test documentation
• 30 days of Agile Testing, Day 26: What does your Test Plan look like?

 

 

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 teenagers (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 hope this drives the right behavior”

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

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

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

3 Sessions of Security Testing

One way to collaborate in a team is to achieve shared knowledge together. An example of this is the online activity of “30 days of testing” that The Ministry Of Testing has been putting out to the online community to participate it. My test team has a “Work Group / Special Interest Group” with regards to security testing, so when a 30 day challenge for security testing came up, we scheduled sessions to learn from the topics provided (see below).

As we are testing consultants doing work for our customers, we scheduled 3 sessions – initially for an hour. At the start of the hour we picked 4-5 topics from the list, and worked our way through them in a prioritized order – within the time box of the hour. Come to think of it we might as well have used the Lean Coffee format. As we have team members two places in DK and one place in PH, it was a skype call using screen sharing. After the call I  summarized sending out a “link mail” to all in the testing group (DK and PH). Evaluating the sessions we extend our ordinary scheduled WG meetings to make room for collaboratively investigate additional security testing topics.

12 From the list: ZAP, Google Gruyere, threat models, HTTP proxies, posture assessments, tiger boxes, recent hacks (elaborated by Troy Hunt), OWASP top 10, OWASP SQL injections, adding data integrity testing into a test plan, share ideas for security testing internally and externally, discuss security testing with regards to EU GDPR compliance.

7 Not on the list: Naughty Strings form GitHub, Bug Magnet plugin, How real persons names trick IT systems, how to be careful with custom license plates, DDoS attacks, IoT privacy failures, Chaos monkeys/Siamese army and little Bobby Tables:

XKCD: Exploits of a mom

To sum up, we have learned about: what tools that can make testing easier, where to read about vulnerabilities and and simple exploits, understand how personal data and logins are used and stored, how to pitch security testing based on fear of breaches and safety concerns, testing the requirements for “by design” security.

30 Days of Security Testing

Testers are Knowledge Workers

Treat your testing people as knowledge workers, not rote industrial resources. The later is a spiral to the lowest value, the former is about giving the business valuable knowledge. A modern tester is a knowledge worker – whose prime area is finding information, filtering information, relating information and presenting information. It is a non-linear process, that requires a touch of both creativity and consideration.

The best testing tool is the brain, and the knowledge worker ponder the problems both consciously and unconsciously. They can work without using the hands or legs, but not with a simple headache. It takes a lot of thinking and collaboration with the stakeholders to identify what questions about the product has value to the business. The (context-driven) knowledge focused tester focus both that it works, and that it adds value to the business.

The business focus are far from the classic mindset of testing established around the millennial (2000). where testing is about finding defects and going through the motion of deriving test cases from specifications. – I know I’ve been there. That era is long gone, even dead at some time to Whitaker and Alberto Savoia. Be provoked or even insulted, but it’s the future.

But wake up – it’s not where the testing world is today. The old tools of design techniques and coverage metrics makes less and less sense to the business. They are old-school and classic approaches, in the not so cool way. The cool kids on the block are poppin’ tags – getting new stuff, sharing and exploring. They know that change is the new normal and that what works in one situation doesn’t work in another. Their primary concern and focus is getting knowledge to the decision makers. They are the knowledge workers

I help you help me help someone else help …. help you help me help each other help us all

Enjoying collaboration with other #testing folk

— James Thomas (@qahiccupps) March 23, 2016

Read for your kids – special interest edition

If you are a parent to (early) school children you should know that it is important to read  to your kids. Reading the words out trains vocabulary, recognition, imagination, wondering etc etc. So I read subtitles from movies… because

The kids currently have Star Wars as their special interest [1], and wanted to see the “people” movies. The have played the scenes via the LEGO Video Games (GC) and have a range of the LEGO sets – so they had the basic plot already. Feature movies like Star Wars are usually subtitled in Denmark – while animation movies are dubbed [2]. So in order both to keep up with “PG” [3] and helping them read the titles – I get to watch the movies and read the subtitles…

Poor daddy, it’s almost as hard as when they has to finish the ice cream they can’t 😉

In the last months the (soon to be) 9yo have cracked the reading code and have gone from LIX11 books to the shorter subtitles. The 11yo have rest covered, but some of the longer texts are tricky (I’m looking at you – opening Scroll).

I tried reading Harry Potter (in Danish) but even if the story was very elaborate and detailed it didn’t catch their interest. Neither did classics from when I was a kid (Sorry Bjarne Reuter), so I had to rethink the acceptance criteria for “read for your kids“.

See these two kids are not as easily motivated – it has to tie into something they can see a direct interest in. Their autism makes them very picky on the choice of subject. What I try is to meet them where they are, expand their competencies and give them a lot of positive feedback until they master it on their own.

Links: People are people – despite their labels, They are just people, The yardstick of mythical normality, Acceptance is more than what can be measured

1. special interest, as in overly dedicated into the topic and cannot talk about anything else.
2. The Danish “dubbers” are usually world class, luckily.
3. Episode 3 is still to come, though.

Lego Role Models

Who had the family’s largest LEGO set this Christmas – it was the 11-year-old and their 8 wheel 42008 Service Truck – 1276 pieces, power functions, pneumatic, gears and 44 cm forcefulness. There was no band merchandise, no glitter or similar gender framing. Quite a project – as is the story about the “Research Institute” mini-figure set.

FDA, Exploration and time to information

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.
• 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 

@Griff0Jones you got links to FDA approved context & exploratory testing (besides #CAST 2011)?

— Jesper (@jlottosen) December 13, 2013

*: really, not to brag – I have met both Griffin, Johan and James, and they know me too 🙂

Mapping testing Competencies

[ Recognise and Acknowledge Your Skills  | Ministry Of Testing – The Testing Planet | June 2013]

The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.

Tester Skills Matrix

Encourage change in the world of software testing

[ Teatimewithtesters.com August 2013|Let’s Talk (Common Sense) ]

Ultimately, testers will fail when they are measured against unrealistic expectations, and testing will fail when it is bent to fit a mold more appropriate to manufacture than to research. We’re worried about where this is heading, about a possible future where testers have driven themselves into irrelevance due to an insistence on cookie-cutter practices that add little and cost a great deal. We’re worried, in a world increasing dependent on software, about what this means for software quality. As the stakes of software failure increase, it seems to us that testing practice is lagging behind.

The ISST sees the development and growth of a global community of testers as the primary means of developing such a supply. A vibrant community will capture the interest and attention of testers who have a desire to learn, whilst events such as conferences, training, webinars etc. provide a means for testers to share information and ideas. We will encourage and support such activities.

Of course, a supply of skilled testers guarantees nothing: other than self gratification, there is little point in having a skill if no one will hire you to use it. But imagine how different the industry would look if even a handful of large enterprises were to say to their vendors: “Sure, cost is important, but we don’t want to spend money on stuff that doesn’t add value. Give us testers who are skilled, who can speak our language and who will work with us to figure out what’s important”. Imagine how it would feel if a large commodity testing vendor were to declare, “OK, this doesn’t really work, we’re going to do something different”. Imagine if a significant number of hiring managers were to consider the ability of prospective testers to think and communicate, rather than their ability to repeat methodological buzzwords. Such a change cannot take place solely within the confines of the testing community. Such a change must take place in the minds of those who make decisions: about how to source testing, about who to hire, about how testing is viewed on a given project. Therefore, the ISST will pursue an advocacy agenda and seek to engage with executives, project managers and developers in order to raise awareness of the issues of skill and value, and to encourage a change in mindset.

Disclaimer: I am a member of ISST and an advocate of context-driven testing.