Response to “the end of manual testing”

This blog is a response to this blog by Michael Bolton titled “the end of manual testing”. While attending EuroSTAR in Copenhagen in 2017 I had the joy of having a good chat to Michael about this topic.

Let me speak from my experiences; I’m bored in my current role and I’m looking for a new job. I have recent experience in observing what the Sydney market is demanding vs how I view myself. If I could choose my own label I would call myself a product risk investigator because it reflects my views in the value of what a tester brings to the table. Now I personally don’t refer to myself as a “manual tester” even though most of my work has fallen under what the market would call “manual testing”.

So how do I market myself for new job prospects? You can check out one of my recent software testing resume’s here. Did you notice that I never refer to myself as a “manual tester”? I try to highlight my technical skills in roles that the market would call “manual testing” because of the negative conations associated with the label of “manual tester”.

As part of my job hunting efforts I reached out to the recruiter who placed me in my current role. He seems to have a good pulse on the Sydney job market for testers; I reached out to him on October the 31st and the next day he had scheduled me a job interview with a startup in Sydney. He then secured me 2 other interviews and I had 3 interviews in 3 days just before I came to Copenhagen for Eurostar this week. I’ve already received positive feedback from 1 of these interviews. However all 3 of these roles have had a focus on trying to find a technical tester who can help the company test API’s through some sort of coding efforts. No one appears to be hiring a pure “manual tester”. Some job descriptions that I’ve read have said stuff along the lines of, “some manual testing will be required but the focus of this role is definitely writing code”. These type of job descriptions trigger warnings in my head along the lines of, “maybe these guys don’t understand skilled testing?”. I almost feel like this phrase “manual testing” is a dirty word. Maybe I should just come out as a loud and proud Manual Tester? Next week I’m aiming to have 3 more interviews before assessing all of my options and moving forward. These next 3 interviews have been set up via applying to jobs via LinkedIn/Seek/Career portals, reaching out to an old colleague and reaching out to recruiters who are involved in the meetup space.

In Summary; I’m being pushed towards more technical testing because those skills are more marketable and I’m struggling to market myself as a skilled exploratory tester. I agree with Michael; “manual testing” doesn’t exist but finding a company who shares my understanding of testing is pretty hard. Now why is that?

I don’t enjoy my job

I have a few issues with my current job:

  1. I feel insanely guilty for not finding my current role to be the most exciting thing I’ve ever done. I’m contracted out to a client, and I can’t officially say who the client is but there is just so much hype around this client for supposedly being the best tech company to work for and sometimes it doesn’t always match that hype. I find my work boring, a little repetitive and not exactly challenging me. However it’s meant to be the highlight of my career. And when anyone asks me, “how’s working at X?”, I feel like I should respond with, “it’s amazing…” and go on to list all of the amazing benefits.
  2. The scale of the Client makes it hard to feel like an essential part of a team.
  3. In my current position it would be nearly impossible for me to convert to a full time employee and I don’t even know if I want to pursue that path.
  4. My current employer isn’t as supportive of my conference speaking engagements as I’d like them to be.

 

Don’t get me wrong, there are many things I enjoy about the role;

  1. My favourite thing about my job is getting to tell people that I work on a product that nearly every one uses. I’ve always enjoyed working on tangible products.
  2. the free food/coffee barristers is pretty sweet too.
  3. Being surrounded by smart people who care about the products they are building.
  4. It’s an amazing thing for my personal brand

 

I also feel like I haven’t been in my current position long enough to really justify looking for a new job. I’ve only been on the Clients project for around 10 months. I know there’s a bit of a stigma for changing jobs too often. This thought also makes me feel like there’s something wrong with me for wanting to change. I’ve experience some mental stress in my current role that’s not really founded in much; from bouts of imposter syndrome to not being motivated to work.

I think I’ve come to realise that the following things would be important for me when I do look for a new job:

  1. Feeling a part of a well gelled team, I know this takes work and I always go the extra mile to build a team culture. My energy for work comes from other people. I’m not that type of “highly motivated self starter” person who is satisfied with the sit in the corner on a computer all day doing work type of role.
  2. Being in an environment where I feel comfortable being vulnerable. E.g. I’ve had struggles with depression so being open about mental health is important to me.
  3. Getting supported for community engagement, e.g. having speaking at conferences as part of my role would be an ideal thing to have.
  4. Be in a learning environment, there are many companies that say “we are constantly learning” but often don’t put that into practice. There’s often a disconnect between what companies say they do and what they actually do.

 

I think I’m in a really good position to be very picky about my next role. I can see 2 potential and appealing paths forward. Either get more technical or get more people oriented.
By technical I mean I could start leaning towards mobile app development, growing my interest in Data Science, picking up some more DevOps skills, get into test automation etc.
By people orientated I mean moving towards product development, maybe picking up some user research skills, maybe looking for something with a support focus etc. It would be awesome to incorporate some sort of outreach/education efforts as part of my next role.

While going through highschool/uni I worked in supermarkets for 7 years. I actually think that work was more engaging than most of my work in tech has been. I’m missing that strong connection to people in my current role.

So I’ll be keeping my eyes open to any new positions and I have a good sense of what I’m looking for.

Hackathon Fatigue

I’m currently participating in GovHack 2017 at the Sydney location (add a 2017 year in review link like this 2016 one when available). It’s the first hackathon I’ve attended this year. When I first moved to Sydney 4 years ago I participated in 4-5 hackathons the first year and it’s slowly died down since then. Even though I love the atmosphere, the community and the collaboration during hackathons; I am suffering from hackathon fatigue.

Last year at GovHack 2016 I tried to participate. I turned up to the opening evening but was struggling mentally. I was going through a relapse of depression and I could not hold it together enough to participate. Reflecting on this, I’d always walk away from a hackathon mentally exhausted and last year I was overwhelmed with the thought of “I can’t handle this stimulation right now”. Going back to work on the Monday after a hackathon always felt hard and would trigger an existential crisis week that involved continuous thoughts of, “fuck I’m tired”. It’s the combination of socialising with all of these new people, trying to frantically work on an idea and eating food that I wouldn’t normally eat that really throws out my routine/mood. I often turn up to work on Monday after a hackathon not rested and with a complaining digestive system. This is my first hackathon since my weight loss surgery which has put a control on the amount of crap that I can eat but I’ve still turned up to last day of the hackathon feeling exhausted. I’m all hackathoned out and I do not have the motivation to submit a story.

Do you suffer from Hackathon fatigue? How do you overcome it?

Agile and Stress

I was having a chat with an old colleague on LinkedIn today (Brian Osman) and we were talking about Agile. The question was, “how does Agile at Tyro differ from <Client>*?” My conclusion was that by focusing on certain “Agile” rituals an artificially high stress environment can be easily created.

Here is this conversation:

Bosman:

Samster! How’s it going at EPAM? All good I hope 🙂 . Hey just a question – do you guys *do* agile and if so how does it compare to Tyro?

 

Samster:

There’s lots of people in EPAM who do agile but in the <Client> office in my little corner there is no mention of agile, no Kanban boards, no daily standups (in my team). Every team is encouraged to develop their own process. E.g. my manager at <Client> often doesn’t come into the office until 10:30-12pm so a 9am standup just wouldn’t work. He has kids and often works from home. I know the EPAM cloud support guys we have here in Sydney have standups and mostly deal with support tickets so their work is fairly regular.

So with my manager we have a sync doc that I fill out every day on what I’m working on with a breakdown of roughly how much time I’m spending on tasks. Roughly half my time should be spent on bug triaging and trying to mainstream that process across some of the Sydney teams (about 70 developers/designers/PM’s and researchers) and the other half of my time spent on helping those teams with feature testing. This sync doc is in place of a daily standup and we have a sync up once a week where we go through it and look for improvements. There’s no sprints, no regular retrospectives. The <Client> guys will tend to work based on quarters (3 month cycles). Higher up management will set certain goals for the quarter and every team will set their own goals that hopefully line up with those.

So atleast in my little bubble at <Client> there is very little”formal” Agile but product excellence is a heavy part of the culture.

The funny thing with Tyro’s agile is it didn’t really support flexibility. A bit of an oxymoron in a way.

The context of <Client> and Tyro is vastly different too. Often the guys in the Sydney <Client> office have to collaborate with people all over the world, so they will often have conference calls with guys from Mountain View in the morning, often taking these calls at home and maybe conference calls with India in the afternoon. I have a weekly sync with one guy in India who helps lead the team that is responsible for communicating with public transport providers. The ops team for <Client> project that I’m working on is based in Seattle.

On a side note, I have heard stories of <Client> bringing in agile experts for coaching/consulting to learn about it. They usually bring in the guys that write the books on the stuff because <Client> has that kind of pull.

 

Bosman:

That’s awesome! It’s something like I just read from a <Client staff member> and something I like…lower case agile. Figure out the problem yourself and make your own rules (but don’t break the law….and be nice!). Thanks Sammy! I’m writing a report for a team I’m coaching at <Somewhere> and they want to compare this with places like <Client>. I think they’ll be surprised 😊 .

 

Samster:

Yeah. Otherwise things are going pretty well. No one has kicked me out yet. There have been a few days where I felt I wasn’t good enough to be at <Client> but it wasn’t really as stressful as starting at Tyro was. I think a lot of companies aspire to have a culture like <Client> but that’s actually pretty expensive, but nicely liberating. I think companies also often miss the point of <Client>’s culture, I guess they see the free food and games rooms and think that’s all you need to emulate <Client>’s culture.

I think the whole point of agile, is the being able to adapt to a rapidly changing environment. In the context of <Client>, sure there are some areas of the business that are constantly evolving but focusing more on product excellence tends to put a slower spin on things. There’s a focus on facilitating fast feedback but it’s to help make work easier, not to adapt to the market. There’s no mantra of ship it quickly, but there is a huge amount of effort put into supporting engineers get new code into production. Even <Client> uses a giant spreadsheet of manual test cases for Android/iOS <Client> maps apps on top of all of their other checks and balances.

There is a lot of process involved with getting a new feature into <Client> maps.

Maybe the over emphasis on”Agile”, and adapting quickly creates an artificially high stress environment. There’s always this push to beat competitors to market, to get this work out the door this sprint, to be constantly, “Go Go Go”. People don’t function well under stressful situations and that constant stress can’t be that healthy.

 

Bosman:

I agree with your point …. I don’t know if they’ll meet their growth targets and I don’t know if staff will feel happy about being ALWAYS under the pump so to speak…

 

*<Client> = I work client side as a contractor. I can’t officially say who this client is (because contract) but I get to help test an android app you might use for mapping and navigation. The Client is pretty well renowned in the tech space.

Where’s your local experience?

We had an amazing Sydney testers discussion group today on sharing stories around our job hunting experiences. One comment that came up was on local experience and I wanted to elaborate a little more on it.

I would say there are atleast two ideas behind why someone would care about local experience. Unconscious bias and culture fit. I have helped with interviewing some people in my last company so I have some insights to share. I would say that unfortunately there is some bias against people who don’t have English as their first language. People will use the rationale of poor culture fit to justify their unconscious bias.

I would say that unfortunately in Australia we have a bias against people from India, the massive call centre outsourcing efforts have not left us with great impressions. So there is an association with strong accents and having many issues with communication. Someone who’s applying for a job here with an Indian background just has a few extra hurdles to overcome, it’s not really fair but by asking for local experience we can justify to ourselves that you wouldn’t be a good cultural fit. We also imagine that you might be coming from a larger hirachical corporate structure, where there is a lack of innovation/self motivation. We imagine that if you did have an issue with your boss here you wouldn’t let anyone know about it because that’s what we understand about your culture.

Agile

change is the only guarantee in life, how can being agile help you; add value, facilitate fast feedback and imrpove processes

Here’s my rant on Agile:

Agile is a bit of a buzz word these days. If you aren’t doing Agile, there is a tendency to think you are missing out. At it’s core Agile is about adapting to change. As a tester, I’m often asking myself, “How can I add value?”. You can be doing all the Agile in the world but if people aren’t collaborating, you are still going to have a shitty experience/product. One way we testers can adapt to change is to facilitate faster feedback. Tests/checks that run during the build phase are an examples of facilitating faster feedback, continuous integration/delivery is also another example.

There are a lot of Agile ceremonies out there and people saying they have the “Best” way to do Agile. THERE IS NO BEST WAY! But Agile is about people, collaboration and products that add value. You don’t have to have an Agile business to try and introduce some Agile practices into your team. I enjoy the Agile ceremonies that encourage collaboration, reflection and adapting to a changing environment.

Some people think Agile is anti-process. This is not true in my experience. It can be some of the most process driven work that I’ve been exposed to but it’s about creating and tweaking the right process for the right context. Ensuring that any process adds value and making sure it supports collaboration rather than hinders it.

I think businesses have a tendency to use Agile as an excuse to change requirements at the last minute but still expect high quality software. Changes need to be backed by evidence (validated learning) and have buy in from the teams building it and cannot change at the whims of some manager. And don’t get me started on the over emphasis of Automation Testing as the only “Valid” form of testing in many Agile development teams.

/End rant

Do you have any rants on Agile you’d like to share? What has worked for you? What hasn’t worked so well?

My take home message is to question the value you add and also seek out ways to facilitate faster feedback.

Further Reading:

Agile Manifesto

Diversity in conferences

are you struggling to attract diverse speakers at your tech conferences?

take a leaf out of Katie Conf’s book and challenge yourself to find those female speakers. All of the speakers at Katie Conf have names that are based on the name Katherine and are actively involved with their tech communities. If they could organize a theoretical conference with only Katie speakers, you can easily find a few women to talk at your conference.

If you are still struggling, maybe you could approach speak easy, this group help mentor potential speakers who come from diverse backgrounds.

Free Range Testing

Co authored with Brian Osman

Often at Tyro, we’ve thrown a tester into a team with developers with little structure. The testers and their teams are encouraged to make their own process. I’m tempted to call this free range testing (hence the title of the blog), it’s like letting the tester roam free to see what happens.

We acknowledge that there are no best practices, testers use the context of their team and their risk radars to drive their testing efforts. Testers have different interests, skills and risk radars and this feeds into their unique way of testing. We also acknowledge that testing is a team effort, the tester is a positive influence in their teams testing approach/culture.

This was also stressful, my first 3 months felt like I was drowning and many testers sympathise with this feeling. There is the information overload of working in a new company, often a new industry for most new testers and there is also the stress of trying to figure out how to add value to the team/company. The lack of structure compounds the “sink or swim” feeling. Around this time, I was struggling with a nerve injury and a relapse of depression.

We’ve tried different approaches to ease that stress, some testers may spend a week or two getting familiar with the context of Tyro before being dropped into a team, we now mimic part of the Developers on boarding process too. I’ve recently been pairing for a few half day sessions with a new tester to help them get on board; to help navigate the language, tech and business context. I also get to expose this new tester to my attempts at influencing the testing approach within my team. fresh meat, mwuhahaha.

We have moved from having the test team being outside the engineering practice, isolated and a gatekeeper to being embedded within the engineering practice; where the tester is the champion of testing for their team. We couldn’t have done this change without Anne-Marie.

Champions of Testing

By definition, a champion is someone(s) who;

enthusiastically supports, defends or fights for a person, belief, right or principle.

Each tester is a champion of testing by becoming a champion for testing.  By the value of  work that is undertaken and the value added to their delivery team, a tester can very quickly increase their credibility.  As an oft-times lone tester amongst developers, the credibility card should not be underestimated nor discounted.  Increasing credibility and value can help a tester champion (that is to say enthusiastically support, defend or fight) the idea that testing is important and vital to modern software development.

When we talk about testing, we are meaning software testing which in one form is;

executing a program with the intent of finding errors” (Myers, 1976)

… a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimise the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” (Kaner, 2006).

At Tyro, the encouragement is for testers use their personal freedom to continually optimise the value of her work or in other words, become context driven.  The context allows the tester to optimise their approach to testing in both an individual sense (for example exploratory testing, using scripts, tools, test cases, scenarios or whatever may be useful) and in a team sense (for example test strategies, processes, developer tests, team quality and so forth).  By so doing, the Tyro tester champions testing by the valued added work that they do.

In a larger sense, a Tyro tester is also encouraged to contribute amongst the tribe(s) and Engineering as a whole.  This may be achieved by the work done in different guilds or being involved in different initiatives.  A tester may also deliver compelling tech talks which in turn help increase their standing within the engineering community.  This helps fuel a testers sphere of influence and thereby championing testing.

Sometimes though a tester may need to be more forthright in their approach with the team by advocating for quality or taking lead in different initiatives.  A example of this was the Java de-serialisation issue whereby Marina (as a member of the security cabal) and working alongside developers, took the lead in making sure that the various team areas this issue touched was tested by the appropriate tester.  In this sense, the test team championed testing together with the work by the developers and helped provide a Tyro solution.

So why would this be considered championing testing?  Unlike some places, Tyro gives people the opportunity to really use the skills that they have acquired and to be able to use them in a way helps the engineering aspects of Tyro to grow.  Most often, Tyro will turn a typical corporate blame game sessions into meaningful and value learning sessions and this, alongside, the test work performed by testers, makes for a wonderful opportunity to showcase (or in other words champion) the value a tester can bring to a Tyro world that is predominately developer focused.  Thanks to this and the guidance given at a test practice level, champions of testing is encouraged and ultimately allows a Tyro tester to produce their, valued approached to their team (aka free range testing).

In this regard, it has to be acknowledged that champions also included senior management who encouraged and led the idea that testing is absolute to helping good development to flourish.  With the drive and encouragement from the top, Tyro has a culture of advocating quality and of the tester producing the best work that they can.

 

Formality and Ceremony vs. Freedom and Responsibility

In most companies that I’ve worked in (well, the larger ones anyway), there has often been a marked dependency on formality and ceremony.  In one large 200+ tester shop, the formality that was determined by the development model, the high degree of separation from developers and over reliance on a large, expensive test management tool (as well as leadership from a mostly non-test, very conservative senior management group) meant that formality was the valued ‘value’ for that testing practice.  Along with the formality, the ceremony required to either elicit requirements (as in elicit the requirements NOT stated in the functional specifications or test the words that were written) or present the screeds of artifacts that had to be producedto satisfy the development model, often meant that testers were relegated to writing and template filling as opposed to actual testing.  I saw first hand the efforts put into creating documents outweighing the efforts put into actual test activity.  As one of two senior managers who had relevant testing experience, the ability to make significant changes was hampered by the culture of the environment.

When i compare this with the culture at Tyro, it is like comparing night and day.  The testing culture within Tyro lends itself the other way – towards freedom and responsibility.  Now that is not to say that its chaos – from it.   A culture of freedom and responsibility still requires guidance, process, frameworks if you will.  The greater the freedom someone has, the greater the discipline that is required.  This is essential in the current testing climate at Tyro whereby the testers have the freedom to determine the best approach to testing that will add value to their teams.  Thankfully, we are not bound by some archaic, test management tool driven process but rather by what approach will best suit.  In this regard, it was absolutely vital that the overarching culture allowed this happen otherwise great testers may not have had the opportunity to flourish.

 

Trust

Tyro has a culture of trust. I imagine this is one of those things that is easy to say but hard to live. There is no one asking me to justify my work. It’s up to me to create my own testing process with my team. Each tester has to come up with their own testing process. This can be stressful because it feels like no one is providing any guidelines or approach. The lack of formal structure is nerve wracking because that structure in a previous context use to be a comfort. That structure helped me to understand where I stood. I had to figure that out on my own at Tyro. We trust everyone to make their best effort with the information they had at hand, we don’t blame people when things go wrong but everyone does jump on board when trying to fix something.

 

Summary

Tyro is a unique environment.  It is a disruptor in the marketplace and it is an innovator on the testing front.  Whilst most banks favour, formality, and heavy weight process and artifact based testing, Tyro aims to produce the best work available through activity.  Working alongside developers, questioning the product, looking for leanness and efficiency, adding value and bringing a context driven approach to testing.  It has not been an easy road.  It has taken alot of encouragement (via coaching) to produce good testers (and in some cases, outstanding testers) with the courage to create, innovate and articulate their own methods.

Thanks