Manual Testing is dead – long live Manual Testing!

This posting is a little later than planned (by about a week), as I had intended writing it after attending the National Software Testing Conference in London, where I was fortunate to speak as well as attend some great talks. I came away with 4 blog ideas, and this is the first one of them.

The demise of manual testing is being discussed in blogs, magazines, conferences, meetup’s etc. If you look at job ad’s, you’d think that manual testing has already died a death and been buried! They all mention ‘Automation tester’ – like its the ONLY thing that testers need to do. So, it was refreshing to attend sessions where people took a different view of things.

I’ve mentioned before about the need for testers to be able to do manual exploratory testing, and it was great to hear Ingo Philipp from Tricentis discuss this in a conference setting. As an industry we need to push testers back towards performing manual exploratory testing, to be complemented by automated regression testing, otherwise we are going to start missing defects due to deficiencies in the overall coverage.

Think about it. An automated test is only as good as the person who wrote it, and only as up to date as when it was last maintained. An automated test cannot make allowances for something that has changed. It cannot stop part-way through and think ‘I wonder what happens if I click this button rather than following the process flow’. It cannot look at the number of steps and highlight that the application sucks from a usability perspective. It cannot point out that the colour scheme is unreadable, or that the company logo is the wrong colour/shape/size etc. It can only run the steps it has been coded to do and validate against what is has been told to check for. So a test may pass, as the application displays what was expected, but what if additional text is present that shouldn’t be there? The test would pass, and unless anyone manually tested that screen, it would go undetected.

I’m not saying that automated tests are unimportant, far from it, but they have their place within a tester’s toolset and are not the only tool available to a tester. Of course you need to have automated tests in place to be able to follow a Continuous integration process, but automated tests cannot cover every possible scenario.

There is another aspect to this as well. Most applications that we develop are going to be used by human beings, so why do we insist on believing that it is best tested by code, without any human test covereage as well? Automated tests should cover the repetitive tests, the load and performance tests, but a person, a tester, needs to look at the application and think about the different paths that the end user could take.

The fun is in the thinking. The benefits are derived from the thinking. A tester’s brain is needed to assess the tests needed, and I despair when I read of really good manual testers with many years experience who feel that they have to leave the field of testing as they do not have automation experience. I sympathise as I came from a manual background. Coding holds no interest for me – if it did, I would have become a developer. So, my career has been based on testing software and working out how best to do so.

We need to stop this freefall ride into automation oblivion, and look at hiring and supporting multi-skilled testers. If a tester cannot write automated code, does it really matter? Better to have a tester who can look at a requirement and work out what needs testing, than a tester who can code but has no clue how to test something!
Developers can write code, so why not pair a develope with a tester to write the automated tests that a tester defines. If a tester wants to write code, and has the time to do so, then that’s great – but we should not be penalising people for knowing how to assess a requriement and define the tests needed (i.e. the core elements of the job), just because they do not have an additional skill in coding automation tests.

I do feel that there are a number of us trying to push back the tide a little to show people the benefits of doing both manual and automated testing, but the more that speakers such as Ingo and myself are getting out there and promoting the benefits of exploratory testing, the better. We need to stop this damaging trend, and ensure that we retain the best skilled testers before they feel undervalued and move on.

Now, who’s with me on this?

Beating them at their own game!

This is a post about Google Chrome, the F12 Developer tool feature and how I felt very smug after using it to get around restrictions!!

I installed an Ad-blocker into Chrome, which is the main browser I used, and I noticed that certain sites were showing messages asking me to remove the Ad-blocker (like the images below), or sign-up for content – neither of which I want to do to be honest. I have ensured that the sites cannot be identified from the screenshots below, as it is not my intention to draw attention to any specific sites, as there are many out there that have these restrictions in place.

      

There was one particular article I wanted to read and I could see no reason why I couldnt do so, seeing it as it wasn’t something that was exclusive to this particular site. I could have searched elsewhere, but was feeling in a less than co-operative mood, so decided to have a play.

Pressing the F12 button and opening the Developer Tools gave me the chance to inspect the element on the page that was blocking the text, by clicking on the button (highlighted in yellow)….

….and then clicking on the blurred area on the page that I wanted to inspect:

This then showed the element in more detail and I could then investigate further.

I found that I had two different choices, depending upon the type of restrictions imposed:

  1. To read the plain text within the Developer Tools pane rather than on the screen, but that meant having to expand every element in order to reach each paragraph:
  2. To try removing the blocker itself in order to read the text on screen as intended by just deleting that line of text.

On one site I had to use option 1 to open each element to read it as deleting the element actually deleted the text within. On another site I used option 2, and simply deleted the element off the page and the text was then visible with no restrictions.

I was surprised how easy it was and I guess that over time, the website builders will try to make this more difficult to do, but not many people really know about the F12 function, so I feel it my duty to help spread the word a little.

It really is that simple. If you are not sure, just have a play. If you delete things that you didnt want to, just reload the page and try again. It really is satisfying to beat people at their own game sometimes!

 

 

My reflection on 2016

This will be my last post for 2016 so I thought it an idea to reflect back on what has happened this year.

2016 has been a great year work wise (and personally too, but this is more of a ‘work’ type blog, so I’ll skip that). I’ve continued co-running our RBI global QA Chapter with Bhagya (https://bhagyagdm.wordpress.com/), bringing 75 testers together on a quarterly basis to create a testing community, where we help each other, ask questions, give support, perform demo’s etc, and we are looking at how we can reboot the Chapters for other disciplines.

I’ve also been jointly running the Distributed Teams workshops with Bhagya which we both learned about at the March 2016 Test Bash from Lisa Crispin and Abby Bangser – we have done 3 internally, and all were very successful.

In April at the UK Test Management Forum, I presented a talk on the Challenges for Test Managers, as there are less of us. What does the future hold? It was an interesting discussion and led onto another talk in December – see below!

From TestBash, I brought back to my team the concept of Lean Coffee meetings, and we adopted those for our team meetings and also for the QA Chapters – hugely successful as it gives every tester a voice, whether they are shy and unused to speaking openly or not.

Then I found that I spent the summer preparing for a busy Q4:

In October I presented by first Webinar, thanks to Unicom, on Being a Better Tester. It went down so well, that I am now presenting it as a talk at Testing Showcase North in Manchester in February 2017!

In November I had an amazing visit to India, where I was privileged to speak in front of a large number of testers about Being a Better Tester – essentially delivering my webinar live. Also I ran a smaller version of the Distributed Teams workshop for the team we work with and they found it hugely informative. (More details on my India visit blog page).

And in December, I spoke at the British Computer Society, Testing Interest Group on ‘Challenges for Test Managers’ after being invited to do so, following on from my April session. It was a privilege to be asked and to be able to run an interactive session with a larger number of attendees, which I felt was very rewarding. I have just typed up a small article for the BCS Tester magazine to report back on the talk and the ideas that came from the audience, as I find that a lot of conferences don’t do enough of this – we should do more interactive thought gathering sessions and share that around.

It feels that this year has been about adding value to others. Giving something back and helping others to do their jobs better – this is the reason I go to work, and why I do conferences, articles and this blog. If I am not making a difference, then what is my purpose? It’s something that is very important to me.

So, now I am starting to look forward to 2017, and there’s a lot lined up already:

  • I have a magazine article coming out in January (Test Magazine) on ‘Changing our approach to Training – how tester training needs to evolve’.
  • In February I have the Manchester talk.
  • A week later Bhagya and I are leading a session on Communication at the inaugural UKSTAR event, which I am hugely excited about.
  • In May I am hopefully speaking at the National Software Testing Conference.
  • I have also volunteered to be a mentor to a new speaker, which will happen later in the year.
  • And I am still involved in helping with the UKTMF, which will be getting a revamp in 2017.

It’s great to have all this planned before getting to the end of 2016, but it takes effort. Nothing just falls into your lap – I have had to put myself forward to do these things, and it is definitely worth it.

If you have read any of my postings this year, I would like to say thank you. I do enjoy receiving comments – I know that someone has either found it useful or challenged enough by what I say to respond. Without readers, it wouldn’t be worth doing!

I wish you a very Happy Christmas and a prosperous and successful New Year. Here’s to 2017!

A visit to India

I am writing this after 4 days in India, visiting the offices of our offshore delivery partners, Nagarro. It’s my first visit to India and it has been amazing so far. We are just outside Delhi, in a 5* hotel, with cars to drive us to and from the office, so we havent had to get ourselves around, although our attempt to use Uber last evening failed as the driver couldnt find us, but never mind. And of course the food is fantastic, so colourful and rich in taste.

Being out here and meeting the team has been a great experience for me and for them. The team are so friendly, helpful and genuinely pleased to see us. Having people visit shows that we care about them, they are offshore but not forgotten. Face to face contact is so important, as its hard to build up relationships over the phone or Skype in the way that a chat in the office and a drink after work can do.

I’ve been able to run through the testing process with them and discuss some of the issues they face. Yesterday I was invited to perform a talk to well over 100 testers on a topic that I presented as a webinar last month on being a better tester, which was an honour for me, so thanks to the people at Nagarro for asking me to do this. We had some good questions from the testers here and they were really engaged in the subject. It’s given me a number of new followers too  🙂

Today I ran a workshop on working with distributed teams – with some of the guys putting themselves in the position of being the Onshore team – I think they found it quite eye-opening.

In terms of new experiences, I can fault it. In terms of building relationships, it has been outstanding, and in terms of productivity, I cannot believe how much I have crammed in this week. There is one day left with only one planned meeting, but I have a feeling that there will be a few ad-hoc ones with the team as they make the most of having two of us out here with them – and who can blame them.

I’m very thankful to have had this great experience, and can definitely say how much I like India already. Sightseeing Saturday is yet to come – I cant wait!

My first Webinar!

A week ago I delivered my first Webinar, courtesy of Unicom Seminars (www.unicom.co.uk). They had approached me to see if I was interested, and after blogging, writing a few magazine articles and speaking at conferences, this was something I had not done before.

The theme was around learning and it worked well for me as I have been on a bit of a mission to help my team to do some tester pairing and Thought Leadership to stretch themselves, and I felt I could deliver something of value to others.

As I was writing the slides (and notes), I noticed just how much we focus as an industry on the purely technical skills that we want testers to have. It struck me that we are ignoring the analytical skills and soft skills that we want as well, which are the three areas I feel a good tester needs to work on. There’s no point in hiring a good technical tester who lacks analytical skills as they wont be able to plan the tests to actually automate. There’s also little point in hiring someone with little or no soft skills. Good communication skills are vital.

I managed to get the point across in a 30 minute slot, with 40 ‘live’ attendees listening in, and I was very pleased to have around 10 questions to answer as well.

Doing something like this has helped me to give something back to the wider testing community in a different way, and I am grateful for that opportunity. My next magazine article will be in Jan 2017 Tester magazine on this very topic so you will be able to read more there. Unicom have also asked me to do a conference session in Manchester in February on this topic, as they felt it would come across well.

I would encourage anyone reading this to have a think about stepping out and giving something back. The Ministry of testing offer the chance to do 99 second talks on a test related subject which can be put on a website, and this is a great first step towards doing a conference talk, webinar or writing a blog or article. It’s worth it, believe me.

Routes into testing

I’m going to make a guess that you (as a reader of this blog entry) never dreamt of becoming a Software Tester when you were at school or college. You may have had dreams of being a doctor, lawyer, train driver, astronaut or a whole host of other things, but Software Tester was not something you would necessarily have even heard of.

For decades, anyone wanting to get into the field of IT would aspire to a Development (or Programmer) role, as these were the main roles that we heard about. Even today, whilst Computer Science graduates have heard of testing, by virtue of the fact that A levels (in the UK) and degree courses now do something akin to a nod towards the fact that software testing is actually something important, and there are people who choose not to write code but to test it for a living. As an example, Oxford university offer a course on Software Testing as part of a Software Engineering degree, which is something that didnt happen in the 1990’s or 2000’s!

There are many graduate schemes which bring people into IT, but even today primarily this is Development, Security and Operations type roles. There are Testing Services companies that will train testers as graduates, but I wonder what the ratio is of graduate testers compared to other roles in IT?

I fell into a testing role for my second job, moving from one bank to another, from a non IT role into a role that I had never heard of. There were no training courses and I learned on the job. It took me a while to understand what the role actually was, and even now there are many people with differing opinions as to what Testing actually is – but that’s not for this post!

Over the past few weeks there have been some interesting Twitter posts about whether Testing is a role that anyone can get into or not. My view is that we are all testers anyway, without realising it. We test the temperature of bath water before bathing our small children. We test the fastest route from A to B and try different ways. We test boundaries of behaviour and acceptability. We test how much we can eat in a ‘eat all you can’ buffet before we feel full. We test just how much longer we can wear our old trainers before they fall to bits! We test all the time.

It seems to me that just about anyone could in theory become a tester, no matter their career background, but not everyone would be good at it. To be a good tester requires having the right attitude as well as technical ability and the right mindset. Technical skills can be learned, how to approach testing can also be learned, but attitude and the right mindset cannot be learned.

It’s interesting therefore to look at how current Testers (at all levels) actually got into software testing as a career. A common story is where projects have required assistance from business units with User Acceptance Testing, and those who helped out became involved that way, staying in Testing and bringing their business knowledge. I’d love to hear your stories as I’m sure there must be some very unusual routes into Testing out there so please share your story and how you found the transition.

Maintenance

Blogging is something that I do sporadically – there are people who seem to have an awful lot of time during the working day to post updates, but I am too busy to do that, and in the evenings I want to unwind and let my brain relax a bit. I find that during the weekend where I am winding down a little is when some of my better ideas pop into my mind.

Like this morning. I went out into the garden to put the Guinea Pig into the outdoor run, where I noticed just how quickly the grass had grown since it was cut only 8 days ago. Looking around, things are growing at a fast pace – shrubs, grass, weeds and the vegetables in the greenhouse. In fact the grass verges were a metre high before the council cut them last week!

I sat with a cup of tea and started thinking about the maintenance jobs I need to do later on today – onions and lettuces to plant out, weeds to pull, some shrubs to trim a little. You may wonder where I am going with this, and what it could possibly have to do with testing, but here’s the thing – it’s all about maintenance. Oddly as I was thinking about gardening, the idea for this blog came to me.

As testers, we need to perform maintenance around our testing artifacts in the same way that gardeners need to do in their gardens.

We have many test artifacts – in my organisation there are testing notes for each application, so that if a tester is new to that team, they will have reference notes about the application, what it does, where environments are, the test data needed, where the automation pack is etc, and of course we will have our test automation suites as well.

Having this information to hand is a good thing – but only if it is maintained and kept up to date. Applications are ever changing and we should ensure that we perform maintenance as part of our core testing approach, rather than leaving it.

The grass outside our houses and on the green up the road was left to grow to a metre tall, and as a consequence children couldn’t kick footballs around until it was cut by the council. It is the same with testing – things become unusable. If we do not maintain our automated tests, they either do not run at all, or a number of them fail, giving a false indication to the development team as to the state of the build. It then become necessary to waste time investigating why some failed, and determining if they are genuine failures or not. And if links are not updated, or test data suites are ignored, they become useless and the time originally invested becomes worthless.

Planning to include maintenance as part of our testing day jobs is a must – but it is a challenge. We haven’t got there yet with all teams, due to pressures for delivery, so this is something that I also need to work on with my team. It isn’t easy, as we have to persuade others that the time spent doing the maintenance is valuable and gives us some pay-back.

I’d be interested in hearing from anyone who has managed to pull this off, as I would be willing to bet it may only be a reality for a minority of testers.

My first challenge today is getting the garden in order – who knows, I might have some more bright ideas whilst pulling out some weeds later (it is very therapeutic!!).