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?

Advertisements

Shifting is more than Shift Left

Links on the topic: Shifting is more than Shift Left as presented at the OnlineTestConf Fall 2017.

My own writings:

by @KatjaBudnikov #katjasays
by @KatjaBudnikov #katjasays

Teaser for Online Test Conf 2017

I’m speaking at the Fall 2017 Online Test Conference on the topic: Shifting is more than Shift Left 

Change is happening to the testing activities. Shift-left automates and codifies the testing activities. Shift-right does it for production.

This session will be about a couple of other trends, changes and shifts that’s happening to testers and test managers.

– Shift-Coach, where It’s more about coaching teams.

– Shift-SME, where it’s more about business savvy.

– Shift-Deliver, where it’s more about the road to production

9

Blogposts:

Teaser for Experiences in Testing Infrastructure Projects

I’m presenting at UKSTAR 2018 on the Topic: Experiences in Testing Infrastructure Projects. The content is a continuation of my materials and talks about testing outside the SDLC, in this context operations and infrastructure. It’s additional problems and examples compared to “How to test in IT Operations” at Nordic Testing Days 2016.

UKSTAR 10% OFF ANY TICKET WITH CODE
UKSTAR 10% OFF ANY TICKET WITH CODE

Relevant blog posts, but not talk content:

The talk is in the same field as this talk – by Mike Talks @testsheepnz although with no applications on top… and other stories 😉

 

Shift-Right, you wild one!

The Shift-Right label is that more and more testing (and checking) can happen on the live application in production. Some call it monitoring, some call it Testing in the Wild. It is a very wild idea for some people and some contexts #YMMV. It may very well be the best way of testing in some contexts.

Once I consulted on a network stabilization and delivery optimization project for a consumer bank. They had many issues in their production environment… I strongly advocated that they did test controlled and structured in production on the network changes and other operational activities. (I have talked about “How to Test in IT operations“ at Nordic Testing Days 2016). More on testing during IT deliveries in Shift-Deliver.

Shift-Right is trend that people have covered well before me, here are some pointers:

The key is really as Alan puts it “testers should try to learn more from the product in use” and with that comes the tools of Google Canary builds, NetFlix Chaos Monkeys etc.

kabuum

This trend goes along with Shift-Coach, Shift-Left and Shift-Deliver discussed separately. Initially I considered shift-right to be regarding consulting, but after hearing Declan O’Riordan at DSTB 2016 I realized that shift-right was the right label for test in production, testing in the wild etc.

Similar posts regarding things in the wild: Bugs HappensThe Kcal bugTradition is a choice and Can you see beyond the visible.

The Shift-Coach Testing Trend

Shift-Coach is when testers and test managers trends towards being coaches and facilitators of the testing activities. Shift-Coach is more about leading the testing than leading the testers to paraphrase from @DevToTest Joe DeMeyers blog post.

The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.

In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.

Shift-Coach trend is visible when Alan Page  talks at Test Bash Philly 2016:

You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?

Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.

This trend goes along with Shift-Right, Shift-Left and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“ and coined the labels on the EuroStar Test Huddle forum.

legocoach
Drive the Testing – Coach!

Trending: Shift-Left

TL;DR: Shift-Left is about testing early and automated. Shift technical with this trend or facilitate that testing happens.

Shift-Left is the label we apply when testing moves closer to development and integrated into the development activities. The concept is many IT years old, and there are already some excellent articles out there: What the Shift Left in Testing Means (Smart Bear, no date), “Shift left” has become “drop right” (Test Plant 2014), Shift Left QA. How to do it. Why it matters (Work Soft, 2015).

To me Shift-Left is still an active trend and change how to do testing. This goes along with Shift-Right, Shift-Coach and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“.

Here are some contexts where Shift-Left happens:

  • Google have “Software Engineer in Test” as job title according to the book “How we Test Software at Google“.
  • Microsoft have similar “Software Design Engineer in Test” as discussed by Alan Page in “The SDET Pendulum” and in the e-book “A-word
  • A project I was regarding pharmaceutical  Track and Trace, had no testers. I didn’t even test but did compliance documentation of test activities. The developers tested. First via peer review, then via peer execution of story tests and then validation activities. No testers, just the same team – for various reasons.
  • A project I was in regarding a website and API for trading property information had no testers, but had continuous build and deploy with even more user oriented test cases that I could ever grab. (see: Fell in the trap of total coverage)

The general approach to Shift-Left is that “checking” moves earlier in the cycle in form of automation. More BDD, more TDD, more automated tests, continuous builds, frequent feedback and green bars. More based on “Test automation pyramid” (blog discussion, whiteboard testing video). Discussing the pyramid model reveals that testing and checking goes together in the lower levels too. I’m certain that (exploratory) testing happens among technicians and service-level developers; – usually not explicitly, but still.

To have “no QA” is not easy. Not easy on the testers because they need to shift and become more SET/SDET-like or shift something else (Shift-Right and Shift-Coach and Shift-Deliver). Neither is it easy on the team, as the team has to own the quality activities – as discussed in “So we’re going “No QA’s”. How do we get the devs to do enough testing?

Testers and test managers cannot complain, when testing and checking is performed in new ways. When tool-supported testing take over the boring less-complex checks, we can either own these checks or  move to facilitate that these checks are in place. Similarly when the (exploratory) brain-based testing of the complex and unknown is being handed over to some other person. Come to think of it I always prefer testing done by subject matter experts in the project, be it users, clients, testers or other specialists.

We need to shift to adapt to new contexts and new ways of aiding in delivering working solutions to our clients.

jollyrum