These are the slides taken from a talk I gave at Australian Testing Days 2016 (#ATD2K16).
I’ve been working on the transformation of a traditional, off-shore QA department into an involved and collaborative group of thinking testers.
There are constraints imposed by cultural differences, physical distances and the biggest challenge of all: the practices that the team was hired for, trained in, and previously rewarded for, are now the exact things you want them to stop doing.
This talk will provide some practical tips for changing testers’ hearts and minds in an offshore context.
I started on this journey less than a year ago when I took on the role of “Senior QA Manager”... Yes I know, we can’t assure quality... That’s a battle for another time
Having had my last experience with “formal testing” back in the old mainframe days (hard to believe I know)... One of the first things I discovered was...
Traditional, factory style testing with its static templates and reusable scripts worked well back in the days of waterfall projects and green screens.
But consider testing of a mobile app in an agile project. With a mobile device, the number of scenarios to consider is vast. The device can have concurrent and conflicting apps running. There is network connectivity to consider. There are many different gestures that can be performed on top of merely entering data. On top of this, you have to be able to release your software fast
How can the same approach, using the same methodology, and the same templates, be used to test BOTH of these systems? We don’t expect developers to build apps using the same techniques and technology as we did back in the green screen days. Yet adherence to such archaic processes in testing is enshrined as “BEST PRACTICE”. It makes no sense.
So with all that in mind, you decide it’s time to break out of the 1980’s testing paradigm and try something that can better cope with the demands of today’s software.
The idea of Context-Driven Testing was first put up by Cem Kaner, James Bach, Brian Marick and Bret Pettichord in their book “Lessons Learned in Software Testing” in 2001.
I’m not going to talk too much about Context-Driven Testing, there’s many people here who know a lot more about it than I do, if you don’t know much about it check out context-driven-testing.com where you can find the 7 “basic principles” along with the following summary –
Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.
I like to think that this approach demands that testers be skilled practitioners who, like a master craftsman, are able to produce and use the required tool for the job.
So what might a context-driven tester look like...
I think of Felix the Cat!
Whenever he gets in a fix He reaches into his bag of .... heuristics
What if your testers have been set up as a traditional offshore team, isolated in their test factory? My team is in Manila and there’s our pyramid setup with the larger group of lower cost junior staff who execute the step-by-step tests that were written by more senior staff . Everyone has been hired, trained and previously rewarded for this factory test approach. It’s what their friends at other offshore companies do too. They’re used to it. They’re good at it. It’s what they know.
About 9 months ago I first started reading up about Context Driven testing and all the other options it opens up like Exploratory testing, Session based testing, Risk based testing, visual mapping, agile testing... I thought - this will eliminate the giant piles of over-detailed scripting documentation, remove the tedium of being a 'testing monkey’ for those executing the scripts... Instead people will be free to think and learn and use their own judgement!
I was so excited, I felt like:
I thought I would try a “soft launch” approach so I ordered “Lessons Learned in Software Testing” and Elisabeth Hendrickson’s “Exploratory Testing” and a few other relevant books and started a little library in the office. I forwarded on a few articles to the team and made a few suggestions here and there... And the overall response was....
One example – I sent an email on “when should we go to the effort of entering a bug in JIRA” suggesting that we should determine if there are alternate courses of action depending on context. For example, if you’re sitting next to a developer and you get on well with them and it seems like a small thing that could be easily fixed, you might try talking to them first. But basically, use your judgement and make a call on it based on your context.
I got a reply asking “... do we have a related mandatory QA guideline or process implementation regarding this matter?"
My goal is to have a team that's confident in applying a context-driven approach to testing. But how to get there?
I started thinking about the best way to set up this kind of change and came up with three factors – Culture, Communication and Coaching.
But underneath it all.... This is what it’s all about.
When you are working with an offshore team – “Cultural Differences” is something that everyone is aware of but probably don’t spend a whole lot of time thinking about in detail. - different language, customs, whatever... - expectation even if unwritten, that the offshore staff will be expected to adjust to onshore rather than the other way around.
- Started on some research of the differences between Filipino and Australian cultures
- Danger in discussing others’ culture – observations not intended as any criticism but information for me to use on how to adjust my approach.
Harvard Business Review article (https://hbr.org/2015/12/getting-to-si-ja-oui-hai-and-da) on cross-cultural negotiation
Guessing that Australia is between US and UK According to this the Philippines ranks very high on avoiding confrontation. Some have pointed out that the US author has used her culture as the frame of reference here – is that a problem? All these things will be relative...
From their website: “The hofstede centre offers valuable tools to help you visualize cultural differences and their impact... The model of national culture consists of six dimensions. The cultural dimensions represent independent preferences for one state of affairs over another that distinguish countries (rather than individuals) from each other. ” There’s other tools such as one to work out your own personal preferences relative to your or another country.
HOFSTEDE 6-D MODEL – Australia vs Philippines. Focusing on the biggest differences in the relevant areas of Power Distance & Individualism. Power Distance is defined as the extent to which the less powerful members of institutions and organisations within a country expect and accept that power is distributed unequally. Philippines is hierarchical society, this is acceptable and normal. Australia has a less formal hierarchy, more consultative.
Individualism - the degree of interdependence a society maintains among its members. Philippines is a collectivist society - close long-term commitment to the member 'group', loyalty is paramount, employer/employee relationships are perceived like family links. Australia is individualist – people look after themselves. In business, employees are expected to be self-reliant and display initiative.
- This leads on to how trust is formed in different cultures - Putting the countries on this list in the Hofstede model there is a definite correlation between high individualism on the left and low to the right cognitive – based on intellectual factors, respect for “someone who knows their stuff” affective – based on relationships built by shared experiences, emotional closeness, empathy in cultures such as Australia that rely on cognitive trust, many of the relationships and activities that would build affective trust are seen as ‘unprofessional’ Many of the countries that we offshore to from within Australia would fall towards the affective side of the spectrum – this effectively is a barrier to trust!
Compared research with what I have observed or heard from my team where I thought these characteristics might affect the adoption of CDT.
Themes like following instructions, doing what you’re told without making trouble.
Let's face it along with lowered costs of course this is why companies chose to offshore software testing particularly... if you think of the factory method of checking where it's important to be able to follow directions precisely, do as you're told quickly and efficiently and with great attention to detail be able to mechanically reproduce results.
But if good context-driven testing is about asking questions, self-directed learning, critical thinking and being able to challenge each other... Need to be aware of potential resistance and use TRUST to help the transition...
It’s pretty universally acknowledged that one of the major difficulties in working remotely across countries is communication. Time differences Language barriers Cultural differences Technology challenges (bad phone line, internet bandwidth) Challenges around informal conversations
Quite a well-known and generally agreed observation Note the PERSISTENCE REQUIRED COMMUNICATION TAKES EFFORT!!!
Face to face – travel *both* ways Video, try always on video so that you can just discuss things immediately without needing to schedule a meeting Conference calls – work on ways to improve these Chat – it’s not just about the tool, but how you use it
It’s so common to have things discussed and decided in a ‘hallway meeting’. Regardless of whether its an onshore or offshore hallway, it’s absolutely critical to either stop the impromptu meeting until you can call in the others (either by phone, wandering over to the always-on video monitor, whatever) or else you MUST inform them afterwards of what you talked about and whether any decisions were made, and encourage their feedback. Yes this may seem like a lot of effort but it will be repaid in spades when everyone is on the same page and knows what’s going on. Not only will this result in improved quality but better morale as the whole team will feel more valued when they’re included or at least informed.
This is what we miss out on when working remote from team-mates. There can be feelings of guilt if you use chat message, or a even part of a phone call for non-work related topics but we wouldn’t hesitate to do that in face to face conversation why not just ‘check in’ with the team, or at least have some introductory chat? This is part of building trust! Because of the ‘guilt factor’ there may be a need to specifically encourage this!
You can have a non-work ‘channel’ in Slack or a chatroom or such but this doesn’t replace the need to have real conversations
“Science may never come up with a better office communication system than the coffee break” If you have access to a webcam and video link, why not actually schedule breaks at the same time Not for a work meeting, just a social chat over coffee or a meal Sharing a meal is a great way to get to know people
It will be weird at first!! But work at it!!
There’s a lot of resources out there to help with remote communication, one of my recent favourites is COLLABORATIONSUPERPOWERS.COM
What else can we try??
I’ve embraced the “unprofessional” idea of being FACEBOOK friends with many of my team mates from our Manila office. The Philippines being the SELFIE capital of the world (and Gene there on the left, our in-house Selfie guru) there are always plenty of photos to celebrate the good times (and even the not so good times can be good times... The shot on the left was taken on a Saturday afternoon when we were all in there working to meet a deadline!)
If you know what’s going on in the lives of your team, you have more to talk about
Any change especially a big change like what I’m asking, needs guidance. People won’t “just do it” even if logically, you can’t see any reason why this should be the case. Nor will the best results be achieved by MANDATING them, especially when the very nature of what we want to introduce is to try and encourage people to think for themselves and take responsibility for their own professional actions, rather than just following authority.
Here’s one of our teams showing off their “chicken goggles”
Why workshop in a safe place? Because you’re asking people to do uncomfortable things You don’t just do your new moves on stage without rehearsal or try the new play in a big game without practice!
You need to be aware of cultural impacts that may increase the FEAR of FAILURE
Change is hard and it takes time. Trying to effect a change across distance is HARDER and takes LONGER
Be patient and persistent. THERE IS NO MAGIC BULLET.
And this will include assumed “skills” that aren’t directly related to your testing goals! Things like how to think critically, how collaborate, to deliver bad news, how to disagree or say NO.
The assumption that all professionals will be able to learn things on their own, won’t hold. Recall the individualism gap – in Australia, employees are expected to be self-reliant and display initiative. In other countries, not so much. In Australia the education system these days focuses on collaborative learning techniques, in many other countries rote learning is still the norm.
Start off by EXPECTING to have to teach, and make “how to learn” one of your topics
This is simply “Learning by Doing” as you practice skills such as Delivering bad news to a PM Saying NO “Using the standup to make your testing visible” (Katrina Clokie) – being more specific about what you did
This format also invites others to critique your work and provide feedback which in itself is valuable
Blue – Manages the process White – Facts Red – Feelings Yellow – Benefits, Positives Black – Cautions, Negatives Green – Creativity
You can literally get people to wear a hat while you’re discussing a topic. This gives people “permission” to be whatever the hat says, and this makes the environment even safer for them to practice expressing a viewpoint that they may normally shy away from. Also the act of wearing the hat makes it a bit silly so the fear of failure may be lessened.
Getting people in the team to speak up is always a problem but for some reason most people in the Philippines have no problem with getting up and singing... So surely this activity is custom made!!
Three ways I know of to play, each involves improvisation with an unknown slide deck: One person presents, the slides advance automatically (say after 30 seconds) One person presents, they advance the slides manually and get extra kudos for finishing the deck within a time limit eg 6 minutes Relay – the slides advance automatically and people in a group take turns standing up to present a slide.
One of the great things about this game is that it’s almost impossible to be good at it, so everyone’s on the same level. It also gets your creative ideas and improv skills going, quite a few people including Michael Bolton have noted the useful similarities between testing and improv skills.
So having investigated the cultural context, worked on improving communication and started a coaching plan... where are we in the great Journey of Transformation towards a team of thinking testers who are confident to break out of their factory mould and try a smarter approach?
After 6 months.... I’m starting to see people step outside their comfort zone – speaking up more in meetings, offering feedback to others, volunteering to do internal cross-training presentations, taking initiative without asking for permission Travel both ways – including testers onsite using BDD collaboration which has been very successful Meetings are more like knowledge sharing and less like ‘reporting to the superior officer’ Overall level of confidence seems to be increasing – someone told me when I was wrong Starting to get more feedback about ideas when I post articles, more enthusiasm about trying new things Employee engagement survey results are significantly higher than last year Have had employees who previously quit come back again
I think that the groundwork has been laid to change our testing practices...
Though I need to recognise that these things won’t change as fast as I want them to, my team is now better prepared for my next round of workshops where I’ll be sharing what I learned in the Rapid Software Testing class!
Transforming an Offshore QA Team
an Offshore QA
Testing today's complex software requires a
You want to break your team out of the