Thoughts of a new(ish) Software tester

Leave a comment

Embrace Uncertainty

Being a software tester can be a bit of an emotional roller coaster at times.  This may sound a little over dramatic but I think fellow testers will know what I mean.

In this instance I am specifically talking about the area of finding bugs and how it makes me feel. I often find myself not knowing how to feel and therefore have mixed emotions when I discover a new bug.

The bugs are always there so why should I feel differently each time I find one?  A lot of it is dependent on the context.

  • The type of bug (e.g. functional/security/user experience)
  • When was it discovered? (at what point during the release cycle or at what point since it’s creation)
  • How reproducible is it?
  • How much of a customer impact would it have?
  • Is is a recurring bug? (is the same developer failing to fix it properly?)
  • In what environment is it found (e.g. test or live)

Some examples of how I feel when discovering some of these different types of bugs are below.

Sometimes I feel proud of myself for catching something which would have had a major customer impact but which is not immediately obvious.  It can then be fixed so customers will never have to experience it.  On other occasions I feel disappointed that I didn’t spot a bug earlier and I start beating myself up.  The further through the release cycle we are when I find a bug the more I start to question myself as to why I didn’t find it earlier.  I can get quite excited when I find an obscure bug which exhibits unusual behaviour.  I can get wound up when I find intermittent bugs as it can be very frustrating being unable to reproduce something I saw moments earlier.  I can even almost convince myself that I imagined seeing it.

I think over time and with experience the emotional side of discovering bugs will diminish, not to say I will lose enthusiasm for testing.  I can’t see there being a downside to the positive feelings one gets when revealing new bugs.  However, I expect the negative feelings associated with finding a bug to turn themselves more into constructive thinking and consequently taking action.  For example when I find bugs later in the release cycle I will work out how I can lessen the chance of this happening in future.  Perhaps it is a bug which I would have found if I’d seen it on a developer machine earlier in the life cycle.  Maybe I can improve my note taking skills so those unreproducible bugs become easier to replicate (I’m sure some of these bugs do still disappear for no apparent reason though!)

My take home message for this blog is that you can never be certain of eradicating all bugs in a system.  If that makes you uncomfortable then perhaps testing is not for you.  Referring back to the title of this blog, you must embrace uncertainty and use the associated feelings in a positive and constructive way if you wish to enjoy and flourish as a tester.


1 Comment

Are you a Comfortable Tester?

Having been a tester for over a year now I am beginning to feel comfortable with the role.  But is this a good or a bad thing?  It depends what is meant by comfortable.

If comfortable means doing the exact same things in the same way every day then that is not a good thing in my book.  Perhaps you are a poor soul who has not been given the opportunity to do anything other than test scripts from which you must not deviate.  In this case I sincerely hope you are not comfortable in your role.  If you are then you are unlikely to progress very far in the testing industry.

When I say I’m getting comfortable I am not talking about things becoming easier because they are repetitive.  Of course, there are always some things you will have to do in a certain way, such as Bug reports; need to contain all the relevant information, and Gherkin tests (should always be written in the Given, When, Then format).

My comfort comes from gaining a better understanding of the product, the environment, the people, the resources, and test techniques.  That is not to say there is not still a lot to learn in all of these areas.

One prime area where complacency can easily happen is regression testing.  Our product is continually changing so we can’t stick with the same tests every time, I have to adapt and update regression tests to match the product state.  Do this by removing tests no longer needed and adding new tests for newly coded areas.  Obviously this is not a black and white task.  It can be tempting to remove tests which always pass.  It is not always clear from the outside what parts of the product are interlinked so you can never make assumptions that some tests will always pass.  Sometimes it might be better to think of the product from a black box point of view as if you are a customer who has never used the product but is tasked with testing as many areas a possible.   It can be a dangerous trap to fall into to think you know the product inside out and therefore do not respect the possibility of unforeseen change.

I never want to feel that I know it all and that there is no need for me to keep learning.  I think your days are becoming numbered as a tester as soon as you start to feel this way.  I believe the test industry is one of the fastest changing industries in existence so you can never rest on your laurels.  I always want to be reading about the latest test techniques and tools and spending time with people from whom I can learn more.

So for want of a better phrase I believe to be a good tester you should always try to remain slightly uncomfortable.

Leave a comment

Take it with a pinch of salt

One lesson that I’m learning fast as a software tester is that you won’t improve if you take everything you see, hear and read at face value.
In the interests of saving time and/or effort this is a very easy trap to fall into.  Perhaps the time when one is most susceptible to this is when you are inexperienced and are at the mercy of all the new information you are being bombarded with.  Ironically,  this could potentially be more harmful for those with more experience and responsibility, who believe they know everything there is to know and therefore stop asking questions.

It sometimes feels like there is no other option than to believe the information you’re being given at face value.  At least if it’s not acccurate you can use it as a baseline which can be modified as new information comes to light.

One example of where I fell into this trap was when I had some testing to do on a new feature and I wasn’t sure if the testing had to be done on all of the environments we use.  I didn’t want to spend time duplicating my tests in different areas if this was not necessary.  As much as it would be ideal to test everything in every possible scenario and environment, this simply is not possible, so we try to fit the best coverage we can into our timescales.  So I asked someone if it mattered which environment I used to test the new feature on and they told me it didn’t.  The person I asked has a lot more experience than myself so I felt I had no reason to question what I was told.  I duly carried out my testing and reported the results, not realising I had not been testing exactly what I thought I had.  In hindsight, if I’d asked a couple more questions I probably would have realised what should have been tested.  So I learnt an important lesson that it’s much better to ask one question too many, at the risk of looking stupid, and get things right, than to avoid that question and end up making yourself look really stupid.

Another example where information can be misconstrued are bug descriptions.  It is very easy to think that the report you’re writing about the bug you saw 5 minutes ago is as descriptive written down as it is reproducible in your mind.  When you’ve forgotten about that bug and then read your report a month later is it still as clear?  Even more importantly, is it clear to someone else?

I’m not saying people shouldn’t be trusted but you need to know what they mean when what they’ve said or written looks to you like they mean something else.

I think the best way to combat this pitfall is to continue to ask questions until you are confident that there is no ambiguity left in your mind about what the facts are. This attitude and the frequency of questioning should not diminish with experience and if anything should probably increase.

Leave a comment

February 2012 – Why I made the right choice

I have now been a Software Tester for two months. It seems like only yesterday I started, as the time has gone so fast, but at the same time, I have probably learnt more in the last two months than I did during the last year at my previous job. This says a lot about the difference between my previous employer and my new employer and how they make me feel about going to work.
I think the word Agile probably sums up the difference. Although this is generally a Software Development methodology I think the values below (taken from the Agile Manifesto) can and should apply to multiple industries:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

I think the list above highlights quite accurately why the way things are done where I work now make much more sense than the monotonous planning, processes, documents and contracts my former bosses seemed disinclined to get us away from.
Where I now work there is a lot of emphasis on learning both through colleagues but also by self driven education. When there is a positive atmosphere where everyone wants to learn and use their knowledge to help others it instills in me a desire to improve my own knowledge outside of work. I think it helps that Software Development and Testing are such a vast and ever expanding area which the world is becoming increasingly reliant upon, as companies go online and start using the cloud, rather than the high street, to sell their wares. In hindsight I probably would have gone down the Computer Science rather than Sports Science route at University.
As a tester, one of the main lessons I’ve learnt so far is that there are some core aspects of working in a Test team which must be right to allow a smooth and efficient delivery of work. For me, two of the most important aspects are communication and time management.
Communication so that everyone has a good idea what other individuals in the team are working on and therefore tasks are not duplicated. Also, to be aware of what other teams are working on and how that may affect what your own team is doing. We achieve this through daily team stand ups followed by a scrum of scrums stand up. This means that every individual need not listen to every other individuals update which saves a lot of valuable time.
It really helps that we sit in very close proximity to the developers so that as soon as a bug or issue surfaces we can immediately grab one to demonstrate the problem and they can look into it straight away. Sometimes bugs are known about and a fix is already in the pipeline, or they can be put down to a limitation with the system or feature which hasn’t been built yet rather than a fault in the software. I’m sure as time goes on I will come to learn more of these possibilities and will become one less bug for the developers myself.
I’ve also learnt that effective time management is very important in testing as time can very easily be eaten up by going off on tangents. By this I mean you have to be focused on the task at hand, whether that is testing a bug is fixed, testing a new feature or exploring a new area of the software. In any of these situations you can easily spot a bug or unusual behaviour and decide to investigate a little further. Before you know it you have lost half an hour and wonder where it went. This can have a doubly negative effect in that you have lost focus on your original task and you are probably not 100% focused on the new quirk you have found as you know you have digressed and ought to get back to what you should be doing. Now, when I spot something new I will make a quick note of it as something to look into later when I can allocate time specifically to it, as tempting as it may be to pursue at the time of discovery.
After two months Testing I really feel part of the Development team and appreciate the way the team works. I’ve learnt a lot and am sure I won’t stop learning whilst I’m still a Software Tester. I’m quite sure I have not written anything revelationary as yet. Hopefully over time my posts will offer more insightful views and I’ll be able to talk more about experiences that other testers may value.

Leave a comment

January 2012 – New Year, New Career in Software Testing

Hello, my name is Andrew. At the beginning of the year, 2012, I entered the big wide world of software testing. Although I am obviously new to this arena I am quite confident that my use of the words big and wide are unlikely to be in debate. However, I welcome any debate or correction on anything I write here.
In my short time in this industry, I have become aware that software testing is regarded as different things to different people. From what I can gather the majority of software testers fall into two broad camps; for the purposes of argument I will call one group ‘Checkers’ and the other ‘Testers’.
The ‘Checkers’ see software testing as a mundane day job in which they follow a set of instructions from which they have no interest in deviating. They believe they are not paid to do any more than this and have no particular desire to.
The ‘Testers’ are in complete contrast to the ‘Checkers’. They see their job as a challenge and look forward to trying new ways of testing every day. They enjoy their job because they get a feeling of fulfillment from taking on new challenges and doing things differently and with variety. These two categories are obviously rather generalised and at two opposite ends of a spectrum. I think that the reality probably falls somewhere in between these two extreme ways of working.
My previous background is in Telecoms, I won’t mention which provider, as I don’t wish to confirm what are probably correct assumptions. All I can say is that the cultures of my previous workplace and that of my new employer are worlds apart. Although the work was not software testing I can still recognise that the mindset of most people was anagalous to that of a ‘Checker’. I would say that any ambitions people had were made very difficult to realise by the working culture that surrounded them.
I believe that it is largely down to the individual to take responsibility for which way of working they choose to follow. Although it is not the employers responsibility to make an employee think in a certain way, they can do much to support them by providing the tools, resources, training, people and culture which will all make a tester more conducive to progressing as a ‘Tester’ rather than becoming a ‘Checker’. As is probably clear I am very much in favour of staying as close as I can to the Tester end of this scale. I am happy to report that my new employer does fulfill the supporting role I feel I need to enable my testing career to progress and flourish. This very blog is one prime example of this. I have never written a blog before but having read others I feel a desire to record my thoughts, if not for others to read, then at least to keep as a record for myself of my views as my testing career progresses.