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.

Advertisements

Recruit for Curiosity

Recruiting for testing roles these days should be mostly about curiosity, problem-solving and less about productivity and text book knowledge. Recruit for right brain skills – not so much operational process jockeys. 

Recently at UKSTAR 2018 Simon Prior talked about his investigation into University programs and their rare courses in testing. This lead to his twitter discussion under the tag: #makeAtester where the top responses of skills required was curiosity. Quite in line with the State of Testing Survey 2017 that lists key communication skills as most looked for when hiring for testing roles. Both surveys establish that testers are knowledge works.

IMG_3614

Similarly HFresearch have compiled an analysis that even on a management level the trend is to hire for creative thinkers over “operational experts that improve business performance and productivity”.  Talent focus should be on right brain thinkers over – The wonks who spend all day staring at spreadsheets, focused on execution “left-brained” activities are less in demand .

But where do we find curiosity training?

If that is the skills we are looking for perhaps we should stop looking at university programs in computer science or engineering, when we want to recruit testers. I have a computer science master degree, and that was really theoretical and while it somewhat focused on problem solving, the lesson was rarely about thinking outside the box.

I think I would rather higher with business domain skills and train testing theory, than hire a process jockey with no experiences in besides textbook examples. That’s also how I came into testing myself, practical activities first – formal training later.

Perhaps it’s not as such important to have an university degree to get into testing. Though it helps 🙂 A diverse background is important, I know of librarians, laboratory technicians and humanities majors that bring good competencies to the testing field.

Finding one higher education that focuses on building curiosity, whole picture thinkers is hard – perhaps dungeons and dragons, as also discussed at the conference?

Less Test Managers, More Test Coaches

One of the trends/shifts I experience in testing & test management in particular is the Test Coach as discussed initially here: The Shift-Coach Testing Trend (Oct, 2016). Recently (Aug 2017) it came up again in a Twitter thread, where Stephen Janaway stated the inspiration to the title of this blog post.

Less Test Managers and more coaches. That’s how I see it going.

Fittingly as he inspired the first post with his talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015. This post is a further elaboration of the Shift-Coach test management trend. Here are some of my experiences:

  • I have been assigned to an agile development team to introduce them to 3 Amigos, Test data driven test automation and such things. The purpose of my involvement was to enable the team to continue the practices without me, and without testers besides the business analyst / product owner (See The domain expert is the tester) as they are doing Shift-left. Similar to an agile or scrum coach, my approach was to look at it as a change in the way of working.
  • Another project is an infrastructure project, there are no testers only technicians configuring Cisco routers that by software can replace firewalls, iron ports, VM servers and other network equipment. The project has to implement 80+ of these, so I setup both a test process and an ITIL change request process acting as a test and release manager – another quite frequent trend. I could continue in the project for the duration, but instead I setup guidance and leave when it’s sufficiently in place.

This might be similar to a test architect, a (internal) test consultant activity. It has nothing to do with diminishing testing. Rather I see it as more testing happening, something that would not have been done without the coaching from a test manager. It’s all about finding a test approach that is fit for the context.

Here are some things others have written:

The competence of the test coach is to have enough change management expertise (people skills) and test management expertise (domain skills) to know how to coach and facilitate the change. Should test coaches test too, perhaps when required, but not necessarily. The activity is primarily to up-skill the team to continue on their own.

The “Test Coach” is a trend similar to “shift-left” and all the other shifts in testing and test management. I see it as a pattern, and what I read from the threads and discussions is that many test managers gradually shift towards test coaches.

2017-07-03 13.57.42

The domain expert is the tester

Sometimes the best tester is the domain expert, the person that knows all the in’s and out’s and corners of the system. I have worked with testers that have had hands-on on a system since the late 1970’es, but I also know testers of mobile app’s that marvel in being the subject matter expert of the domain. Sometimes the professional tester doubles as agile Product Owner(1) too given her vast knowledge. The tester becomes the the SME …

The subject matter expert, though, is usually a business analyst, or perhaps a User Experience expert. Those persons might have a better stand to be testing the system, than testers with no prior knowledge. Often the SME is the best tester available. I see this happening in a shift-left setting – but also in settings with a heavy user and business involvement. Like SAP releases to enterprise systems – where the business users and SAP architects still spend a month off their “actual” work (user acceptance) testing corporate configurations and customization.

The UAT is not dead, but the classic role of the tester testing on behalf of the business is declining. The business would rather test their own, with in-house subject matter experts. The field is active, as there is tool support for this activity. Panaya(2) is a tool that specializes in managing the UAT of a corporate system like SAP, and one of the key elements is that test cases can be broken up in steps and handed over between persons. Not even classic HP ALM’s handle hand-over between testers well. While ALM’s support that the tester does the testing, Panaya supports that tests are distributed across many people. People that have other (“real business”) tasks during the work day.

Testing can also be pushed even further out to the users with crowd-based testing, beta releases etc. In both crowd-based and UAT-based testing, the role of the pro’ tester is missing but the testing is still happening. IT’s being done by the most skilled – most valuable for the task.

So what can we as testers do when our tasks are gone – skill up, go with the change and become the expert – or move out to other skills: Coaches, delivery leads etc.

2015-12-18 13.49.28
The expert says 5 pieces should be in the build – though the customer is OK.
  1. If she doubles as scrum master, she’s probably more a Test Coach
  2. this post is not sponsored. I’m just making observations – not recommendations.

 

Getting Testing in Early

Even before there is an “system development life cycle” – testing in the form of thought experiments and  evaluation can take place and add valuable information to the context.

My test management tasks are often about the next thing coming up. Bids for outsourcing agreements and application development often comes with a large document of test activities to be answered and elaborated. In this role I am the the subject matter expert (in test), and while have to write the tender reply for my domain. Sometime down the line the bid materials becomes an actual project, but by then I’m onto the next thing.

Sometimes I draw an analogy to the Secret Service advance team arriving two weeks before the president, setting up protection and identifying gaps – while then moving on to the next location before the president even gets there.

Another example of advance work for test people, is where the organisation uses frequent releases of systems. While the majority of the test effort is put into the release currently being tested, some effort must go into looking into the frame of the coming release. In the coming release the test manager can look for headlines to test, review initial high level design and find flaws and conflicts in the release content.

Sometimes I draw the analogy to the blue and gold teams of US nuclear submarines. While one full crew is out sailing/delivering, the shore team prepares, trains for the next big push.

Testing early can also be in the form of running simulations on various business case scenarios. Business simulations is all about experimenting and evaluating. For novel solutions prototyping, wire-framing and user experience activities helps develop minimum solutions to be tested for viability by the customer.

In the article “Continuous Testing in Dev Ops…” we see testing happening during Plan and Branch. In the article “A Context-Driven Approach to Delivering Business Value” testing can help establish viable market, match to vision and in identifying business risks.

testing related to revenue generation may focus on functionality or regulatory compliance; testing related to revenue protection may focus on maintainability or legal defense; testing related to supporting revenue may focus on business process improvement or cost reduction.

Testing is a lot of things – also outside the SDLC.

 

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

Many Bits under the Bridge

I’ve been in the testing business for 14 years – when I started in late 2002 it was all about using HP Test Director 7.6 – in a browser… There was only one model of testing, v-model, and only one book of testing the ISEB (later ISTQB) vocabulary. And only one expected output of testing: Testers designed test cases, executed and perhaps wrote both a test plan document and test report document. Test process improvement was a thing, but even so testing was often a pointy cog…  

Many Bits under the Bridge Later

It is not about the test cases any more, it’s about being part of a team – that delivers an IT solution to the business. First of all, if it’s just about the test cases then it is a race to the lowest paid off-shore location, a run to the bottom in repetitiveness and mechanic activity. Checking! with more focus on crossing the t’s and dotting the i’s. We have tools for that now – the plates are shifting.

When testing professionals puts “writing test cases” on their LinkedIn description. It seems to me that they are stuck in the testing world of 10 years ago. Standing still and not seeing that Testers are Knowledge Workers – not workers of producing artifacts. It is much more important to see beyond the visibleUncovering better ways and seeing testing as an activity to provide information to the stakeholders, based on experiments and observations.

Skill up and be smarter! And don’t listen to old tapes – it’s not worth it :).

See also this from QA Symphony & Ministry of Testing:

The Software Tester: Modern vs. Traditional [Infographic]
The Software Tester: Modern vs. Traditional [Infographic]