Transcript

[Aaron Hodder] Our first speaker, Shay, embodies authenticity. The first time I spoke to her, it just leapt out to me, that's why I'm so excited to have her as part of our conference. 

Shay is going to be talking about her experience going from a large government organisation to a digital agency.  So, please join me in welcoming Shay.

[Applause]    

[Shay Naiki]  Can you hear me all right?  Cool.  Welcome.  I'm super nervous, so, give me a minute to... get in the zone.  

Hi, welcome.  I'm talking about Creating a collaborative culture in the testing world:  lessons from life in a digital agency.  

So, as Aaron said, I'm going to be sharing a little bit about my experiences and my journey.  Creating collaborative culture within my own team and the people I work with or in the past.  

This is me.  So, I'm going to start off with my mihi.  And since it’s Matariki, I thought it’d be appropriate.

Ko Shay Naiki taku ingoa,
Ko Tararua te maunga,
Ko manawatu te awa,
Ko Kurahaupo te waka,
Ko rangitane te iwi no rei ra tena kotou ka toa.  

Woo.  Okay.  

So I went into the testing world, while being a subject matter expert for a large government organisation.  I have had a totally different role, and I was a frontend user at Work and Income, working as a case manager.  So, quite removed from “testing”. 

As a user, I just entered details and pushed and got an outcome.  I didn't have to think about what happened when I pushed that button or how that outcome came about.  I have since learnt that it was called logic, and all that kind of stuff.  

As a subject matter expert, I was meant to be in Wellington for a two week gig, and that turned into a four year secondment,  and then a few years as permanent Test Analyst. 

I was part of a large testing unit, and specialised in a system that was at the end of a very large, integrated ecosystem.  

I moved to Alphero. This was a whole different kind of area for me, to what I was immersed and buried deep in, at an organisation like MSD.  

Alphero is a digital agency. They create beautiful mobile apps and websites, which some of you use every day.  

When I moved there, I joined a very small, highly skilled test team, who were front-end mobile and web specialists.  They were pixel perfect.  They could point out margins and paddings that were pixels out.  To me, they looked all good.

I didn't even know about margin, opacity, contrast, or anything like that.  Let alone on mobile or web applications.  I had been looking at a legacy system that had a blue screen.  

So, moving to the digital agency, I was out of my comfort zone, but I was keen to learn and excited to be in the digital space.  

Fast forward a few years and I'm now the manager there and I'm still learning new things every day.  That's just a little bit about me and my background.  

Crowd participation here would be lovely.  Um...hands up.  

Have you got experience in a large organisation?  Cool.  

Are you in the mid to large science, QA or a test team?  So you're not the only one by yourself?  

[Laughter]

Do you work to a set prescribed methodology?  

Do you have control of things like test data, accessing databases, and even naming conventions?  

We have so much diversity and experience here in this room.  I hope that some of the things you might hear in the talk might resonate with you.  

So a day in life at Alphero.

At Alphero, I'm part of a team of 4 and the best description of Alphero QA is…layers.  We work across multiple projects and BAU releases, for various clients from a range of industries.  So, we've got large government organisations, utility companies, advertisers, to good old startups.  

At any one time, we can be working across those, and we’ll have varying degrees of maturity.

We work collaboratively with our own internal teams. So we've got sales, marketing, project managers, strategy, design, developers… everyone.  

We also work with external client teams.  Some of them are based in New Zealand and some are based overseas.  So, a real mixture.  

We’ve really put an effort to work with the QA teams, because they're our people.  

And also, attend all the different types of ceremonies. You’ve got kick-offs, retros, and standups.  Sometimes up-to four a day.  We do some testing somewhere in that day.  

No one day is shaped the same, and there's always lots going on.  Lots of variation or juggling.  Sometimes on the rare occasion, I do miss being in a waterfall project thinking I want to work on one thing for one period of time.  And then I remembered my previous experiences, and I'm like, nah, I'm good.  

This is one example of the kind of stuff that we test.  So this is Andrew in my team, testing the movement application on an iPad.  This is us having fun.

The Alphero crew are here today.  So have a chat with them if you want to know more about life at Alphero.

Leads on to the types of work.

So I mentioned before the industries we work with.  This varies the type of work that we do.  

For some clients, it's UI only. Does it look pretty? Does the build meet design?   

Others, it’s for checking accessibility. Doing the API stuff, End-to-End kind of deal.

We adjust as we need to.  Sometimes it can be up to three or four different companies, all working together ish, to kind of bring the app to life, or to maintain and enhance.  That's a lot of people.  And we aren't all together at any one time.  

So, again, more layers: the client team, my team or Alphero, we may have an internal integration team, and sometimes one other team. So that's the layers.  

Very rarely do these clients have test teams. But when they do, they vary in size.  The way we work with them, sometimes it starts off rocky, and sometimes it's all good from the get go.  All very random.  

Some just don't have teams at all.  They haven't invested that time and money in that space.  So UAT is usually done with someone with arms or legs, or a Product Owner, a Business Analyst, or someone similar.  

Each of those teams involved have their own perspective and deliverables to work towards. But at the end of the day, all the teams really want to do is get the best quality product to users in the market.  

And yet we test across mobile. So you got your iOS, Android… Oh I don’t have to tell you all this.  On a range of operating systems, some were as low as iOS 5, which is very old and clunky.  We also test across multiple device brands: Samsung, Oppo, all that jazz.  

These are driven by user analytics.  So we also have to be aware of user analytics.  We have a large range of physical devices that we use and we maintain.  We also share those with test teams. So we usually ask them to come say: “Hey, since you don’t have those physical devices, come hang out with us, and you can use them.”  Part of the collaborative process.  

When we don't have a particular device, we just use emulators and kind of go from there.  On top of that, we do all the web stuff, you've got your browsers, Chrome, Firefox. All driven by user analytics.  

Most recently, I've been testing streaming devices: Apple TV, Chromecast dongle…I definitely wasn’t used to any of those…and kind of in-built TV applications.  Which has been really interesting.  It's taken the enjoyment in entertainment out of watching the telly, using those for testing.  But, yeah...still fun.  

That is one type of work that we do there.

The other part is really the managing relationships, the communication of results, communicating any needs, wants or requirements.  A little bit of negotiation and also, pivoting and switching, which has its challenges.  

Challenges.  So, I asked you a few questions in the beginning, in the hands up section.  That  was basically to get you to think about your current work situation, or your previous experiences.  

I was at a large government agency. I was part of a very large team.  I was working to a prescribed methodology… it wasn’t really like prescribed. More Waterfall like Agile. And I have control of certain aspects.  

When I moved to Alphero, three distinct challenges early on have really sat with me the whole time.  When I was putting this presentation together, they naturally made the cut.  

The first one.  First one, putting this together, it was from my earlier time.  So one of them is, I felt like I had no control.  This was massive on me.  I'm not a control freak, but as a tester, I like to have certain control of certain aspects to my role.  I think inherently, testers are like that.

Here are some examples.  So, one of them was creating user data.  Not a big deal for some people.  But for me, I was like, ah, why can't I do these things?  I’ve been able to create my own data, or searching for existing data, previously. But now I am not able to do this.  It was like, why?  Why can I not?  So, one client was to create a ticket with what I needed, and then I had to wait.  That wait time could vary.  Sometimes, it didn't even come.  Uhh.  Very frustrating.  

Another client's process was to use a predetermined list of data that had already been created. But the data would be corrupted or was no longer available in the environment. Thanks to a data clean or a refresh, that no one had bothered to tell us about. Again, very frustrating.  

Another bit of this was environment configuration.  Previously, I had been able to kind of determine what was required in my test environment; be it code parity or data from production.  And here, I couldn't do anything.  I would often get environments that were so far removed from being production-like, or had the latest kind of builds I needed to do my testing.  I would happily do my testing and think, ah, it's all working.  Then it would go to UAT, and it would fail.  Doesn't look good.  Again, frustrating.  

And these were two things that I felt were basics to ensure quality, but I couldn't do them.  

There's a quote that I like from a guy that I think is pretty cool.  Tim Tebow.  

So even though I couldn't control those aspects, I could control my attitude, yep.  Easier said than done sometimes.  

And if I put in as much effort as I can, without kind of getting a bit deflated. And focus on the things that I could control, or the big picture or the overall "why" we're doing stuff.  

The second one could be a little bit weird… but to me, it was a loss of identity.  I had been going to meetings and I was hearing “the Vendor” or “the tester”. And I'd think, who are they talking about?  Then I realised it was me.  I thought “Uh?”  I mean, being called those wasn't that bad, but it wasn't that great.  I'm actually Shay the person. I have value. 

And it didn't really set a positive foundation for a collaborative working environment I felt at the start. Which is already hard enough as it is, a tester or QA or someone who's seen as a blocker or a hindrance to releases, and all that old school stuff that goes along with that mindset.  

But this was super important to me.  “Hey, man, we're part of this team.”  If I want to work with a test team, I have to really introduce myself to them.  And being referred to as “the third party” or “the tester” really doesn't help.  And I was also dealing with impostor syndrome.  I thought “uhhh gosh, I got all that other stuff going on, and now I’ve got no identity. How do I get that back?”

Then the third one: context switching at pace.  So, I talked about those layers before and all the clients are not the same.  The context switching at pace was a deal.  But it has two passes. 

There's the switching between the types of work and the bits and pieces.  I'm not talking about multitasking like doing an email and a spreadsheet, and chatting at your friend while having a cup of tea.  It's more around the, kind of...yeah.  Different bits and pieces.  

The other big one is mental switching.  Mentally, you're in the zone, you're concentrating, you're in there doing your stuff. And then, you get interrupted for various reasons. Usually it's like “Hey, so and so's away. The client wants this important thing to be a priority.  Can you get it done now?”  

You think, uhhh.  Okay.  Now I've got to mentally stop what I'm doing, think about what am I picking up? What even is the work or the problem?  Who do I need to talk to?  Who do I have to work with?  Is there a tight deadline?  Is there a lack of rigour or is it an extremely rigid process in place?  

Also, if you're doing web-based work, and you've now got to switch to mobile, that also takes some time to mentally switch.  

The P1 hotfix stuff, that's on the fly stuff.  The other stuff, if you know in advance and plan, I'll do four hours of one client in the morning and three in the afternoon or planning it out over a period of time. 

The context switching was massive.

So how did I overcome or accept these challenges?  These probably should be in a different order; shouldn’t end on Tears.  

Mindset and tears.  For control, just let it go.  Let stuff go.  You can't do something about it.  Not going to waste any energy, just give it up. If you’re okay with that. 

So with the data setup stuff, suggests “Hey, how can we work better, share better data, is there a reason why I can't create data?  Is it a security thing or...is there someone else wanting to have control?”  Various things.  

Then for the environment, just kind of check “Hey, is the environment ready?  Does it have what I need to get my job done?”  

Then for the loss of identity, is properly introducing myself and making a point to really talk to test teams because that's who I'm really working with.  And also, just to kind of get a vibe from each other.  You can tell whether someone will be openly sharing information or if you'll have to work harder to show the big picture, show value, all that.  

And then those all contribute to culture.  

Collaborative culture, to me, is just not one thing but a collection of feelings and action.  When you Google collaborative culture and culture, there's a few words that kind of pop up: value, environment, safe, supportive, learning.  A few keywords that come to me are these things.  

Safe.  Is the environmental culture that I'm working in, is it safe?  Is it safe and inviting for anyone else to join?  Is it safe for my internal team to be able to discuss things openly?  Be transparent and accountable?  

The other word is supportive.  Are we being supportive of each other?  Are we being supportive of the process?  

And the third one, that I like, is genuine.  Is it genuine?  Are the interactions that we're having with each other, through those layers, genuine?  Do I make the people I work with feel that their feeling with me is genuine?  How do I show collaborative culture?   

I like to have a proper introduction.  

I like to say “Hi, Aaron.  I'm Shay Naiki.  QA at Alphero.  Yes, I'm the manager but I also will be the lead tester.” And then that way, he knows a little bit about me.  

I also try to build rapport.  Let's go have a cup of tea.  I like free tea.  We also like to discuss how each person works.  

“Hey, Aaron, how do you like to work?  What's your process?  What's your personal preferences?  Tell me a little bit about what you like. Also, how do you like information reported back and tickets?” 

I thought people had, like, a pretty much similar process but it has varied.  Some have one line.  Some have 50 lines.  The variation is wild.  

And then, boundaries.  What boundaries do we have that we know of?  What boundaries are we comfortable to blur?  What boundaries are we not comfortable to blur?  

Also, being flexible.  Are we being flexible enough to let stuff go?  Flexible enough to be like “Hey, good job, you did a wonderful release.  It was really lovely working with you.”  

And be flexible like “Hey, I know I'm supposed to test these five things, but I can't at the moment because I have five other projects on.”  

And also, no blaming or Blame Culture.  

This one can be quite big and large.  Every now and then you forget that you are on the same team, and your goal is to get the product to market to the best quality.  Sometimes you can just be so frustrated with a person that you just went 

“You should have picked that up in DevTest. You've wasted my time.  Where are our unit tests?”  Or

“Why didn't they test that in UAT, when it’s their scope? Now it's gone to production with a bug.”  Yeah, blame.  

Big picture.  Does everyone know what we're about?  Everyone know how we're working?  Big pictures are one of those words that describe how you want it to be.  

Also a real duty of care. So because we don't own those products, we have to show that we really care through all of those different layers in various ways.  

Sometimes, it's kind of capped by “Oh, we found bugs in production.  Okay.  Cool.”  

For me, it's really like, through every interaction I had, I had quality conversations, we cared about the product as a team.  We hustled to get it across the line and all those kinds of things.  

And also, saying "thanks."  

I don't know if we thank each other that often, or enough.  And that's how I grew.  Contribute to the collaborative culture.  

Really, it's all just finding the balance.  Finding the balance between workload, expectations, within yourself, your test team, project managers, delivery, stakeholders, while ensuring quality through every layer of that. Everybody owns quality.  Sometimes it's more visible than others.  

And it usually falls to the QA team because you've got "quality" in your title.  

Okay.  Let me just wrap this up...so, key things that I've learned along the way,    and these are really large,    is that I create the collaborative culture that I want others to be a part of.  Not just fellow testers.  In my organisation, I want strategy, to feel comfortable enough to come to the QA team and be like “Hi, team, I've created this document, could you just give it a quick check from a QA perspective?”

I also want other test leads to feel like they can participate or contribute to my culture.  All those things.  Cup of tea.  Just sharing some support.  So, there's a few client groups that we work with that have gone through restructuring. So you sent out a message to say “Hi, team, I know you're going through a hard time.  Care for a cup of tea or chat, if you need to?”  Stuff like that.  

Collaborative culture is not defined by one thing.  It's many things, like I said: feelings and actions.  And everyone contributes to this.  

And lastly, be kind.  Be kind to yourself and each other.  And that's what collaborative culture is to me.  Thank you.

[Applause]

Recommendations

• Burnout to Brilliance book

References

• Mihi (Māori introduction)

• Alphero

• Work and Income NZ

• MSD (Ministry of Social Development)

• Tim Tebow