Featured

Testing Pearls Of Wisdom

As you may or may not be aware, I’m currently half way through helping to deliver a software testing bootcamp. This involves me working as part of a team of instructors (who are all working testers) to give sessions on various topics to those wishing to pursue a career in software testing.

I’m enjoying the course a lot, as aside from learning loads it has made me reassess some of my core values, and try to put them in a pithy, easy to read way that can translate to different audiences.

I decided to create Twitter/LinkedIn posts using tools like Canva to create the images below, and I’ve been pretty amazed at the positive response.

My philosophy on growth

"If you learn the why, you can always Google the how"
“If you learn the why, you can always Google the how” quote

I’ve learnt this from years of watching developers and other testers, whilst also letting my Imposter Syndrome talk me into thinking that doing exactly as they were doing somehow translated into me being rubbish at my job. I attended a mock interview recently, and one of the responses was “we don’t expect you to have the answer to your fingertips every single time, just tell us your thought processes to how you know where to find the answer”. I Google stuff every. single. day. I couldn’t debug an automated test without using Stack Overflow, and I lean on others for guidance and support both in work and outside it. And this actually makes me better at my job – because often my instinct is proved wrong, and I can refine what I’ve done long before I’ve taken myself down a rabbit warren of mistakes. And judging by the 200+ comments on this post, a helluva lot of people feel the same.

Automated Car Analogy

Quote "Automated software testing is like driving an automatic car.  The car takes care of the checks, like wipes, lights and gears. This frees up the driver to focus more fully on the unexpected and more complex twists, turns and bumps in the road."
Test Automation Analogy: Automated Car

I came up with this one when driving my car (my first ever automatic, nothing fancy mind) back from the supermarket. I noticed a car in the opposite lane with its hazards on, and it took me fully 5 seconds to realise it had stopped on the road so that the driver could visit the Tesco over the fence. Not a great bit of driving, and the cars behind were similarly confused. I thought to myself, if I’d have been thinking about that for 5 seconds and had to concentrate on the road as well as gear changes and wipers (it was raining) I’d have probably stalled. But my automatic car took care of those checks for me, giving me that head space I needed to assess the dangers, or lack thereof, in front of me.

Automated testing is just the same – get those repetitive regression checks taken care of by the machine, and allow the driver to explore the application at leisure.

Bug Reporting = Archaeology

Quote "Reporting software bugs is like digging for dinosaur bones.  The best thing you can do when you find something is to uncover as much as you can before you confidently shout "It's a T-Rex!""
Bug Reporting as Archaeology Analogy

I’ve got to thank @TheTestingPeers for this one, as they refined my original thoughts. This one works on a few levels, as identified by David Maynard and Russell Craxford. Firstly, in archeology people dig in teams of different experts – so you can call on the right person to help you figure out what you are seeing as part of your analysis.

Secondly, archaeologists have to document the position of what they have found, in much the same way testers do (e.g. this is on chrome version 88.39393) – adding this detail instead of just shouting “I’ve found something”, when something may turn out to be a chicken bone will save the team time and earn you a reputation as someone who’s opinion can be relied upon.

Thirdly, archaeology, just as testing, is mostly about what you don’t find. You can asses the quality of a piece of software by its absence of bugs (as long as your testing the right things) as much as by the existence of them. Knowing something isn’t a T-Rex, and being confident of that assertion, is just as mighty.

Summary

I hope you’ve enjoyed these pithy analogies. Feel free to share with anyone who would benefit from seeing them.

Featured

Creating A Test Automation Portfolio Episode 4: API testing for Restful Booker using Postman

Intro

This blog continues my journey of creating a test automation portfolio, which has been ongoing for a few months now. Although I’ve covered API testing in an earlier post, I wanted to include Postman as the tool of choice, partly because its something we use at work, partly because I want to get better at it and partly because its such an industry leading tool.

I’ve already had a go at using a Newman call to run a Postman collection through the Microsoft DevOps Azure CI Pipeline – you can check out the code for that here as I won’t be referring to it again in this post. I find terms like DevOps and CI a bit scary when I read them in blogs, and I don’t want to put you off reading on, Postman is a super simple one to start with I promise!

Postman Image

The Project

I continued my magpie tendency and avoided reinventing the wheel by Googling “Postman tests for Restful Booker API” and hit gold with an amazing GitHub Repo from Joanna Denni. She had created a really great and easy to read repo with some excellent README instructions.

The great thing about the pretend hotel booking website Restful Booker is there is a limited number of really clearly documented API endpoints, so its easy to get a good amount of test coverage, and practice testing GET, POST, PATCH, PUT as well as DEL calls. Mark Winteringham (its co-creator) recently tweeted about the sheer number of requests which are sent to the public server, so there must be plenty of other people learning in this particular sandpit.

Tweet from Mark Winteringham About the Popularity of Restful Booker

Key Features

I wanted to develop what was already in the repo to support my learning by:-

  • Install the original repo, and get it up and running.
  • Get the existing tests to run (very straightforward, also includes pre-request script examples which is v. cool)
  • Add in a few new tests from scratch including MOCKs, randomised response variables and params
Example set of tests for a GET endpoint and below actual code snippets (for improved accessibility)
pm.test("Status code should be 200 OK", function () {
    pm.response.to.have.status(200);
});
pm.test("Response Content-Type should be json", function () {
    pm.response.to.be.json;
    pm.response.to.have.header("Content-Type", "application/json; charset=utf-8");
});
pm.test("Response should contain at least one bookingid", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData[0].bookingid).to.not.be.null;
    pm.expect(jsonData[0].bookingid).to.be.a('number');
});

Here is a video of the tests successfully passing against the public Restful Booker site when executed via a Postman Collection Runner. I did 2 iterations which gave me 130 test passes in just a few seconds – not bad eh!

Video of test execution using Postman’s Collection Runner

The Code

I’m still learning the inner circle workings of GitHub, so I have a lingering doubt that I’ve gone about this in the wrong way, but this time instead of forking my own branch I took the original code and generated pull requests for my additional work. The code can be found here:-

https://github.com/joannalaine/postman-restful-booker/pulls

Pull Requests demonstrating the additional work I have added to the original brilliant repo

Lessons Learned

I think the idea of “API” testing is massively offputting to a lot of people, because it feels super techy and “backend”. In reality, particularly when using Postman, I’ve found it way simpler than a lot of UI type automation. It is also very maintainable once you know what you’re doing with variables etc. Feel free to use this code as an example to get you started!

The other thing I’ve found about Postman that I love is the amazing amount of online help available. The Postman learning center is great, and a big shout out to the incredible Danny Dainton, who has helped me out a tonne too.

I’m now over half way through my Test Automation Portfolio, which is a pace I’m really happy with. Yaaaaaaaaay.

Onwards!

How RuPaul’s Drag Race Has Taught Me to Be a Better Tester – and Why You Should Watch it too!

OK. So I have only just discovered that the new season of reality TV show RuPaul’s Drag Race will air on Netflix Saturday 2nd Jan 2021 in the UK. I cannot tell you how ludicrously excited I am by this news. 🥳

If you’re not familiar with the show, it is a competition with a $100,000 prize fund, where Drag Queens from all over the world compete to win “the race”. It is incredibly popular, and I have loved watching it for years.

It seems a tenuous link, but I honestly think my all-time favourite TV programme has a lot to teach us all. Here are a few lessons I’ve learnt from the show:-

The power of community

If anyone is looking to join, build or grow a community this year, Drag Race is the perfect example of how to do it. It respects its roots, celebrating what came before it such as the iconic “Paris is Burning” documentary and the Stonewall uprising. It also embraces and celebrates all that is weird, “other”, non-conformist and challenging. As testers (and as people), we need to embrace other points of view, and be a part of a psychologically safe workplace. It might sound wooly but it makes the difference between dreading coming into work or staying around for years and years. RPDG provides a space for everyone spectacularly if, like me, you’re into the Testing Peers concept of culture-add not culture fit.

The importance of being authentic

I’ve always loved that Drag Race Queens are selected because of their “charisma, uniqueness, nerve and talent”. A drag act might be all about image and looks, but that alone won’t get them a ticket to the final. What matters is what you do and who you are. Queens who don’t fit the looks mold but excel comedically or are super kind or super talented do spectacularly well.

“Club Kid” looks celebrate the unusual and unique

I’ve always liked that I work in an industry where I’m not judged on my looks. That I come to work most days with no make up on, my hair tied in a crappy bun wearing an old jumper and jeans and that makes zero difference to people’s respect for me or their view on how well I can do my job. Trying to hide who you are at work to fit in is exhausting, and as a long term strategy will likely fail for you. Be yourself, and support others who want to be authentic too.

You will fail. Success comes to those who keep trying.

RPDG has become a phenomenon. It has spawned so many successful global careers for the contestants (who win or lose, yes you Porkchop) that they are often willing to come back and try again. Many who failed to snatch the crown first time around try harder, work on their failures and return to take the “All Stars” title – another RPDG series which takes past contestants and puts them through their paces once again. A lot of the contestants have endured genuine and profound hardships to be who they are, and to even make it on to the show in the first place is rightly considered a major life win.

The power of resilience and persistence in testers is a mighty one too. RuPaul himself says “what other people think of you is none of your Goddamn business” – and I believe this to be 100% true. Do not waste your time stressing about what others think, or being afraid to be the one who says “I don’t understand this”. Push those boundaries Queen.

Shea Coulee, runner up then crowned winner in 2020.

Don’t take yourself too seriously

From the pun-tastic names (“Bagga Chips”, “Heidi n Closet” and “Lattrice Royale”) to the tasks and even the guest judges, everything about RPDG has its tongue firmly in its cheek. Be prepared to work hard, but know life is for living and enjoying yourself.

I always work best in teams with a healthy approach to their work life balance and who enjoy lifting those around them to be positive and have a good experience at work. If your only focus is on delivery on time at all costs, this will lead to burnout, low morale and all the best people leaving. I’ve said it before and I’ll say it again, just don’t be a dick.

I intend to add to this post in future once I’ve watched the latest season (and probably gone back and watched the previous ones for like the 10th time too) but after the year we’ve had I would wholeheartedly encourage you to jump in to the the craziness and life-affirming goodness that is Drag Race.

Can I get an amen? ;o)

Creating A Test Automation Portfolio Bonus Edition: Codeless UI automation using TestProject

I recently completed a marathon project to create 5 working test automation frameworks from scratch, which form a Test Automation Portfolio.  This article is a bonus edition of that portfolio, where I use TestProject to create the same tests in an earlier framework using their codeless solution. (hint: it was insanely easy).

TLDR:

  1. You should consider writing a test automation portfolio if:-
    1. You think you might need to show off your automation skills e.g. to an interviewer
    2. You want to learn more about automation by getting your hands dirty
    3. You want to improve your visibility as a tester and share your knowledge with others
  2. You should consider using TestProject’s codeless test automation for your Test Automation Portfolio if:-
    1. You want a quick (like, lightning quick) way to create tests
    2. You’ve been frustrated by how long it takes to get a fully fledged automation framework set up in the past and want an easier solution
    3. You want to see how far IDE type solutions have come since “the bad old days”

The Project

I had created a test framework which executed a few basic tests such as login on the OpenCart admin demo website – this is a great one to use for testing because it has a lot of features.

I wanted to wrap these tests up into a suite so I could run them all together.

Winning Features

Test Project is the first codeless solution I have used since early Selenium IDE, and I’ve got to say that codeless solutions have definitely come a long way since then! Test Project feels much more solid to me, and yet super easy to get started and have something up and running in no time at all.

The test recorder is a great feature if you want a quick solution.  For example, in an earlier framework I’d spent hours trying to get my head around relative locators in Selenium 4 to identify a tricky logout button that didn’t have a nice user friendly ID in the DOM. I wanted the code to be easily readable, so didn’t want to map some crazy CSS query, and I really struggled to identify the element.

Here it is:-

With the Test Project recorder, all I had to do was click “logout” and it added a user readable step into my test case, no manual intervention required. To someone like me, this is literally hours saved.

Not only did I use the recorder to create all 3 of my test cases, but I also tried out the new sharing feature to pass my test case from one user to the next.  This felt like Postman to me, being able to easily send someone else my code and for them to accept it and run it right .  

You can read more about this feature here.

I was even inspired to do a few video tutorials! Here is how easy it is to create a test:-

And here is a video about how to create a “run” consisting of several tests:-

The code

The codeless solution has some great features that genuinely surprised me.  Once you have written a test, such as login, you can add that test into another test, to avoid re-writing code that you need to maintain in different places.  

Also the use of parameters such as Username and Password was fantastic.  You can set project (global) or test specific variables and even make them secret.  The great benefit of this is if a parameter changes or you want to use a different user you only need to go to one place to update and it will propagate through all your tests.

Thanks to the sharing feature, I thought it would be helpful to share the links to my tests with you. Feel free to import them into your solution and see if it works!

Login:- This test clears the default username and password, types in a new one and logs in.  It then validates the user has landed on the correct page.

View Orders: – This test logs in (reusing the login test above to reduce duplicate code), opens the menu bar and selects sales -> orders.  It then validates the orders page is visible.

Logout:- This test logs in, clicks logout and validates the user is returned to the login page

Lessons learned

Getting the chance to add Test Project into my portfolio was an enlightening experience for me.  I learned how easy it is to over engineer an automated framework, particularly if you only want a quick and easy solution.  The speed with which I was able to get up and running and produce parameterised tests which could run on any browser installed on my machine was a game changer.

Summary

I would definitely turn to codeless solutions in future as the fastest way of getting off the ground, and the fact Test Project has some many features to increase maintainability, such as global parameters, test imports and the ability to share test cases with other team members, means you don’t have to worry that you’re somehow “not doing it properly”.  I also love how you can convert the tests into coded tests using the SDK if you want a more fully fledged solution, as this allows you to start off small, and as your skills mature the framework can grow with you.  If you are interested in creating a test automation portfolio for yourself, I’d encourage you to take a look at Angie Jones article here for inspiration.

Creating A Test Automation Portfolio Episode 5: UI Web Browser testing using Cypress

Cypress Logo
  • OVERVIEW
  • Languge: JavaScript
  • IDE: VSCode
  • Runner: Cypress Runner, called from NPM
  • Source Code Management Tool: Github via Github Desktop
  • Type of Tests: UI / Web browser automation
  • Websites Tested: Opencart and todomvc

Intro

This blog continues my journey of creating a test automation portfolio, which I started back in at the start of August (aka that time when it was occasionally sunny and not just bleedin damp and cloudy all the time!). This time I wanted to talk you through my exploits using the increasingly popular web browser end to end automation tool Cypress. I’d heard quite a few people say this tool was easy to pick up with lots of great documentation, so I thought I’d give it a go.

The Project

By now you won’t be surprised to hear that I did what lots of folk, both experienced and newbies do when starting using a new tool – I magpied, and yes, that is an actual noun, who knew! My sources of information including code were:-

Gil Tayar’s “An Introduction To Cypress” Tutorial on Test Automation University (note this was created a few years back and some features of the tool e.g. cross browser execution have moved on since, code base is still solid though)

Marie Drake’s wonderfully easy GitHub Repo On Cypress Fixtures and Login Example Code

Toby Steed @ Learn Automation’s series on Cypress including a very handy cheat sheet

I decided to focus on two learning sites – todomvc as per the original TAU course material, and Opencart’s demo website, as this gives lots of scope to add new tests in future as my familiarity with the tool grows.

Key Features

I wanted to develop what was already in the repo to support my learning by:-

  • Install the original repo from the TAU course, and get it up and running.
  • Get the existing tests to run
  • Add in Marie’s login tests
  • Refactor them to work against the Opencart website
  • Add in a few new ones based on the extensive Cypress docs and Toby’s cheet sheet
list of key features from the Cypress Website

I did indeed find Cypress an easy one to pick up and get working, a few NPM commands from within the VSCode terminal is all it took. There aren’t any libraries to import as cypress takes care of this for you, as well as adding a load of useful example code. So far so good.

Another handy feature, although I’m told its not the best idea to rely on this exclusively, is using the Selector playground to identify and copy Cypress elements – or even the full Cypress command – which can then be inserted directly into your code. Tidy. Here is a video:-

video of using Cypress Selector Playground to identify elements

As far as the code itself goes, its a new syntax to get used to, but fairly readable, and adding the reference types code at the top of the page ensures if you do get stuck examples are only a hover away:-

/// <reference types="cypress" />

describe('todo actions', () => {
    beforeEach(() => {
        cy.visit('http://todomvc-app-for-testing.surge.sh/');

        cy.get('.new-todo', {timeout: 6000}).type("Clean room{enter}");
    });

    it('should add a new todo to the list', () => {
    cy.get('label').should('have.text', 'Clean room');

    cy.get('toggle').should('not.be.checked');

});
code screenshot showing cypress help shown when hovering over a command e.g. “visit”

The Code

I tried to learn from my earlier mistakes here, and just started my own repo from scratch. I am really getting used to the Github Desktop app, which personally I prefer to the new CLI.

You can take a look at my code on GitHub here.

Here’s a visual of the key elements:-

screenshot of VSCode showing key features of my Cypress codebase

To run the tests, simply go to the terminal window (terminal -> add) in VSCode, navigate to the correct folder and type

npx cypress open
screenshot of terminal window with npx cypress open command

This then brings up the in-built Cypress testrunner, which is a nice UI interface you can use for execution. I tested the code against a number of browsers by using this dropdown and selecting the relevant spec (Firefox is now officially out of beta as per release 5.3.0):-

selecting to execute tests in Chrome, Firefox, Edge, Electron Browsers

This video shows me executing the login tests using Cypress UI. Take a look at the very clear step by step results panel on the left hand side which you can actually use to rewind through the history of your test execution to see what was happening at each step, which is another user-friendly feature:-

A video of the login tests executing against opencart – note failure is correct as incorrect details did not prevent login

Lessons Learned

The more I work on this stuff, the more I see appreciate that getting a framework off the ground is the easy bit. The hard part comes when refactoring tests, and coming up with a structure to make them as maintainable as possible – also doing those tricky edge cases which take up 80% of your time but are only 20% of your tests.

Just one last repo to create, and I’ve saved it til last on purpose, Selenium Webdriver.

Wish me luck!

How can we help you develop your career in the next 12 months?

If you were asked this by your boss, do you know what you would say?

Its a question that’s been posed to me this week, and I’ll admit I’ve been a bit stumped by it. When jobs seem scarce on the ground at times, just keeping hold of mine has felt like enough. But I’m northern, and if a gift horse is on the loose I’m not likely to be asking it to open wide and say “ahhh”. :o)

Would you ask for something reasonable and achievable, or go for broke and ask for something bonkers hoping you’ll meet in the middle somewhere? Would you say you want to learn something that you’re interested in, something which may advance your career, or something that will help your employer? Have you been asked this before and wished you’d have given a better answer?

Tweet or DM me @Beth_AskHer with any insight you have on this.

The Best Career Advice I’ve Ever Had

Is this:-

Google it.

And I’m only half kidding here. I hit my teens in the mid 90’s. This means I grew up using actual libraries, and “finding things out the hard way”. And it was largely really time consuming, incredibly frustrating and often inaccurate.

Like most kids I was really into music, and used to record the UK Top 40 on the radio every Sunday. Then, I’d painstakingly rewind and listen back to our favourite “choons”, patiently writing the lyrics down in the back of my mate’s school books like some weird human Lyrics.com.

Sometimes I’d get lucky, and find a good set of song lyrics had been written down in Smash Hits magazine (remember that kids?), but often, if I couldn’t make out what the words said we’d just be completely stumped. Or I’d have to make an uneducated guess – e.g. “A scrub is a guy who thinks he’s fly/he’s also known as a bus stop” (TLC, No Scrubs) or “You put me high / upon a bannister” (Boyzone, You Needed Me). My god we were cool.

Smash Hits Magazine Song Lyrics Cut Out Feature

Then Along Came The World Wide Web.

I’m pretty sure everyone can remember the first thing they Googled/Asked this weird posh guy called Jeeves. Mine was this, and I stand by it –

What Are The Lyrics To Hanson’s MMMBop?

And to this day, I still know those lyrics. In fact I’m convinced I’m one of the only living people who does actually know them, because a) Hanson have been consigned to history’s musical rubbish dump and b) they’re pretty bloody unintelligible lyrics. Go on, I dare you, give it a go:-

Hanson MMMBop (official video)

I remember being genuinely floored when the actual words to the song came back on my screen – yes it took a good two minutes for the page content to slowly appear, and yes, my Aunty needed to use the phone so turned the internet off shortly after, but still, it was magical.

So, you may ask, what has this got to do with testing career advice? Answer: everything.

Near enough every problem you’ve had as a tester has been experienced and overcome by someone before you. Sometimes thousands of times over. Stack Overflow, Ministry Of Testing and a million and one other places hold the answers. Its incredible to think we never had this amazing facility at our fingertips. Use it liberally, and without shame.

Learn the why. Google the how.

When you first start to learn automation, learn programming basics, rather than jumping straight into a tool. Why? Because then you have the context to understand a line of code which will genuinely help you to learn. But remember, even super experienced testers use Google several times a day when, for example, they have forgotten the exact syntax for a method declaration. Don’t let your imposter syndrome fool you into thinking they’re any different to you. They don’t have fairy dust, or a wand, or the worlds greatest memory. They have the context, the “why” figured out, and they use technology to help with the how. Google it!

Thanks to the Ministry of Testing’s bloggers club for the inspiration!

Creating A Test Automation Portfolio Episode 3: Taiko, Gauge and JavaScript

  • OVERVIEW
  • Languge: JavaScript
  • IDE: Visual Studio Code
  • Source Code Management Tool: Github via Github Desktop
  • Type of Tests: Taiko, Gauge UI and API level automation
  • Website Tested: Various including The-Internet, Gauge.org

Intro

This episode is a brief one, all about my continuing odyssey of creating a test automation portfolio. This time, I’m following the advice the incredible Steve Mellor gave me some time ago and diving into ThoughtWork’s open source library Taiko and framework Gauge (which I still inexplicably spell “Guage”. every. single. time).

We’ve recently started using this where I work too, so having a sandbox to practice in has been cool.

The Project

I wanted to demonstrate a standard way that testers may like to begin creating a framework at this level – namely taking a free example one from somewhere else. There is a reason to “Google” is a recognised verb in the Oxford English Dictionary people!

So, what does it do?

Conveniently, the community/guys at Gauge have realised folks don’t like to reinvent the wheel too, so have created a set of example GitHub repo’s to get you started:-

https://github.com/getgauge-examples/

I chose “js-taiko” as I wanted to use JavaScript, which I believe I may have used before but certainly not recently. Note – it is true what they say about learning the basics of coding before you dive into automation, as once you have that you really don’t panic when a new language is thrown into the mix.

The tests do lots of basics to demonstrate the simplicity of Taiko and Gauge working together, such as interacting with various websites through smart selectors, form authentication, use of table-driven test data and mocks. It is very simple to pick up, and I found debugging nice and clear too.

Key Features

My strategy was basic, namely:-

  • Install the cloned framework, and get it up and running.
  • Get the existing tests to run (this took longer than I thought, a lot had changed in the couple of years since the original repo had been created).
  • Add in a few new tests from scratch

Here is a video of the tests successfully passing when executed in VSCode.

A short video of my Gauge Taiko JS test cases executing via the NPM Test command in a VSCode terminal window

The Code

I’ve published my repo as a template, which means you can use it as a basis to begin your automation framework. Check it out here:-

https://github.com/askherconsulting/taiko-gauge-javascript-vscode-test-automation

As I learn more, I’ll add more.

Lessons Learned

I was definitely reminded of the importance of having a jump off point – creating a lot of this stuff from scratch would have been extremely time consuming. Also, using an old repo is sometimes more trouble than its worth (approx 50% of test cases in this did not pass first time round, but it was actually a good learning curve to try and solve the puzzle of why!). Onwards!

Not getting opportunities you should be? Try a Reputation Audit

For a major upcoming talk in October, I’ve been thinking about how successful testers seem to carve out their own futures. In my twelve years of experience in this industry, I’ve worked with many people over the years who on the face of it seem to be… jammy. They just never seem to struggle to find their next amazing role (or stay in their current one and get promoted, better terms etc).

The thing that has interested me, is that the testers who excel at doing this aren’t necessarily the ones with the best CV’s on paper. The brutal truth is there is not always a positive correlation between your skills and your opportunities.

So what is the common theme amongst these successful folk? Perhaps its right place right time, perhaps its just a good jobs market that keeps throwing great opportunities their way. Perhaps, a little. However, IMHO its largely the number of people they are visible to. They make a point of investing time and effort into growing their reputation – whether that be at work with their immediate team and wider colleagues or outside of work e.g. with former colleagues, select recruiters or the testing community at large.

You can be an amazing tester, but if no-one knows you they can’t tell you of opportunities when they arise. And this could majorly cost you over the course of your career.

If you want to become more visible, my advice would be to invest your time on your reputation in the same ratio as you would on your technical skills.

One way of identifying your weak spots, or opportunities to improve even further, is to complete a Reputation Audit. I designed this myself, and it represents a high level view of where you should look and the sorts of things you can do to turbo charge your reputation. It shouldn’t take more than 5 minutes, and you can start implementing your own recommendations straight away.

Example Reputation Audit

Here is a link to a blank repuatation audit to get you started:

https://docs.google.com/spreadsheets/d/1X9dmANXVOEfMc7v6gR-cc7GJ7WA5PvU7rZJTSn2SlFU/edit

Please reach out to me if you would like a blank reputation audit template for your own use and I will send you a spreadsheet – alternatively, if there is a way of adding an excel file into this page without it costing me a fortune then let me know how and I’ll do that instead :o)

***warning*** any actions here must be sincere, and you must be willing to contribute for the benefit of others, not just what you can get out of the situation. Personally, I’ve grown a lot in confidence over the past few months just by doing things such as submitting questions for an AMA, posting a few bits in a chat alongside an online meetup, or reaching out to some of the incredible people in the software testing community and asking for their thoughts or help.

As ever, feedback very welcome.

I Wish I Knew More About…

Everything!

As a tester, I sometimes feel bombarded with the sheer amount of stuff I’m “supposed” to have mastered. In one article I read recently, at least 15 different technologies, toolsets, areas of tech etc. were mentioned that testers “need to know”. Whilst to some that probably seemed like a great challenge, to me it just felt completely overwhelming.

Its important to keep reminding yourself that you can’t know it all, and ultimately what is more important is having a growth mindset.

Growth vs. Fixed Mindset

A few years back, I watched an amazing Ted talk by Carol Dweck called “the power of believing you can improve”. Whilst it was aimed at children in education, I believe it translates well into those upskilling in the world of software testing. If you believe you can learn something, but you’re just not there yet, you will be a lot more likely to practice it and master it than if you think you’ll never get there.

Image of Carol Dweck at TED – “the power of believing you can improve”

I still have to battle the instinct all the time which tells me “you’re not a proper coder” / “you don’t have a CS degree” / “you’ll never be as good as that guy” – because you’re actually only competing with yourself there. What is more important to recognise is that everyone is learning new stuff, all the time actually, and if you keep chipping away at it it does get easier.

Peter Simons did a great talk a few years back about learning automation, and this was his first slide:-

“There’s nothing to be afraid of” Slide 1 from Peter Simons talk on test automation

The message is clear – don’t be put off starting anything because you don’t know everything. Begin with small steps, accept it doesn’t have to be perfect, and learn one thing at a time. Refactor and iterate.

Thank you to the Bloggers Club at the Ministry of Testing for inspiring me to write this. I’d encourage anyone of thinking about blogging to take a look at bloggers club if you need a nudge.