Your Mileage Will Vary

Looking at all the podcast, conference and community chatter you could get the impression that everyone else’s projects always follows the latest trends and hottest principles. That everything is perfect, and everything is a success – and that all new ideas are working right off the bat.

First Try… ish

It almost sounds as if testing has to be in a specific way, and that what you experience is wrong or less worthy. That there are no failures, no scrum-fall projects or old legacy systems. It sounds like everything runs smoothly on an up-to-date CI/CD K8 technology stack with all the bells and whistles.

Hmm.. no.

Don’t worry, listen to the “Guilty tester podcast”

Every single project/company/context is both it’s own mess and it’s own best. There is a huge difference between all the worlds companies and all the countries traditions around IT. Sure, it may happen – let me tell you the world of IT projects is a weird place, and that’s OK. So take all the stories of successes with the added American car commercial catch phrase goes “your mileage may vary” [YMMV] or as we tend to say coming from a Context Driven point of view “It depends“.

It depends on your context if modern testing is a thing for you, it might work in an enterprise setting of commercial standard systems. Using Robot Desktop automation in testing might work better in that setting, but then again it will probably not be a good fit in your average software development project. In a context of developing software business-to-consumer the web features is more importation than in an enterprise setting. And round and round the practices and approaches goes and goes…

If you look a little beyond the borders of your own project you will see similarities to others doing the same, but also the diversity in approaches, successes and failures. You are not doing all of it wrong.

You are not doing it wrong

– you’r mileage is just different.

Advertisements

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 his 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” by Bach, Bolton. Once I had an argument about how to deliver quality. The other side held towards IEEE definition of delivering the expected. But even when he did, he 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.

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 listNaughty 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:

exploits_of_a_mom
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
30 Days of Security Testing

Connected online

Apparently my Internet habits are very teenage like… I miss my WiFi and cannot leave the phone in the pocket. What I am is a digital settler, connected to my processional community.

I realized this at a training recently, where it was noticed that I had my phone out DURING CLASS. Was it FOMO – no, I just had a thought about testing to share on twitter. As I would usually do during conferences and my working day. We had a good laugh about me always needing my internet and my phones. I took it as a compliment, as that would mean that I was a YOUNG digital rookie, sharing and collaborating. .. like only the cool kids would do.

young-luke

When I model  myself to the Teaching Trios model – I am a digital settler by age/ introduction time. But collaborating and having an online professional interaction is not based on age, nor should it be frowned upon. Online community interaction is done by all ages, diverse and really nothing new. It’s past hype, and not ground breaking. There are models now of how communities evolve and function. And the business, career and personal benefits explained over and over again.
Yet I have more followers on twitter than the company I work for. Sometimes when someone else at work shares curated testing papers, I have seen it already and have met the people who wrote it. (Read Meet the famous people)
When I model myself towards Simon Wardley‘s three-stage model (Pioneers, Settlers, town planners). I don’t jump anything brand new, but I do want to take the groundbreaking and turn it into a framework for others to succeed… So to my kids Netflix is TV, and my mom follows me on Facebook to see what I’m up to. (no good, I swear).

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

19ad6-cycle

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 wonder if

I wonder if… the Norwegian and Swedish texts are correct on this picture:

2015-10-29 21.38.35

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.

awesome

Here are some other things I often say:

revert_thatsodd  strange

Originally at the Ministry of Testing Facebook page,  but the twists above are mine.

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, women, men, 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: