Category: Software Testing

Update: Sam Connelly Tester Profile V2

I used canva to create a resume, I had fun putting it together. You can view V1 here: Sam Connelly Tester Profile

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

Here is a mindmap that I’ve been using to help my Mobile App team test, I’ve printed a laminated version of this and I take it to planning meetings. There are many other mindmaps out there too.

I have my first software testing article published in the testing trapeze. The article is about the Robotics Challenge that I ran at Tyro. I also talked about this challenge at the Agile Australia conference.

I have an issue with the word “Manual Testing”. Say we compare a “Manual Tester”, an “Automatic Tester” and a “Developer”. When a developer builds a tool that helps them program it is not called “Automatic Programming”, it might be called a “Compiler” or some other new word. Developers do manually write code with their hands but it’s not called “Manual Development”, they use the tools and resources that are available to get the job done. Testing is the same; we use the tools and resources available to help get the job done. “Automatic Testers” manually write scripts with their hands, why are they different from “Manual Testers”? We test with our minds just like developers create with their minds. I’m a tester first and foremost; my goal is to find issues in software. What are your views?

(As a side note, this rant is heavily influenced by James Bach)

I am talking about software testing but these ramblings could be expanded to other types of product based testing.

First of all, what is a “good” tester? I think it is someone who finds issues with software and is able to make someone else understand that issue. Some people say testing is about providing quality of software. In response; I say, “bah humbug”. The way I get a sense of “confidence” about the quality of the software, is by thinking up scenarios that I think will test the boundaries of the software yet still cover the majority of the functionality. If I test the boundaries and find no major defects then I will be relatively confident that the software does what it is intended to do. I say relatively confident because no one can ever completely guarantee that software works as expected.

In no particular order, I find the following qualities make a “good” tester:

Curiosity: Is being eager to learn about the product you are testing, ask lots of questions, be curious about testing a theory/idea/hypothesis that you have about the functionality of the software. CAUTION: curiosity might lead to passion. (*gasp* Can someone actually be passionate about testing?)

Rescourfulness: Being able to find/confirm information from several sources. Sources can be ambiguous, boring to read, hard to find etc.

Letting your voice be heard, don’t be a push over and sit quietly while people talk about the product. If you think a detail has been overlooked, raise it

Being able to humbly receive constructive criticism, acknowledge everyone makes mistakes (even you) and learn from them, this leads to good team work

Communication: If you cannot explain an issue effectively, how will you make someone else (with minimum effort on their behalf) understand that issue? Try to always improve your communication skills so people are less likely to misinterpret what you say.

Creativity: Being able to think up the most amount of scenarios that will test the most coverage in the least amount of time. Making testing fun is a challenge because by gollies testing can be mundane, repetitive and infuriating (at times). I had fun moving Darth Vadar into Tasmania and installing an electricity meter on his death star, as even Darth Vadar has to pay for electricity. If you get the chance to make up test data, have fun/be creative with it.

Obsessiveness/attention to detail/pedanticness: this can be both a good/bad thing. Attention to detail is good, helps pick up on issues/defects that might have been missed, obsessiveness means when I want to understand something fully, I won’t be happy until I’ve satisfied that learning itch, often giving me a better understanding of how it works but I might spend the whole day trying to understand GPS coordinatates and spherical approximations of the earth to try and calculate the straight line distance between two GPS points, making my own excel spreadsheet with the formulaes when there was a simple webpage that already did that for me.

 

All these will help the tester gain an understanding and to find issues, thus achieving the goal of being a “good” tester.