Skip to main content

Posts

Don’t answer a question, ask a question - Estimates and Testing

As a tester you may be asked this question… How long will the feature take to test? Recently I was asked this and I responded with something like this…. I can test it in 5 minutes, 5 hours, 5 days, 5 weeks or 5 years. Now I hate giving estimates. People tend to take estimates as gospel and hold you to them if you then have to say that the testing may take a little longer. As testers we can test a feature for 5 minutes but we could also test it for 5 years. Trying to get the balance right between having enough time to test the feature and satisfying someone who needs it to be delivered as quickly as possible can be difficult. However I think that we should not be asked how long something takes to test, I think as testers we should be asking a question instead.  Going back to answering the question “How Long will the feature take to test?”, lets take an example feature and describe what we could test for each of the estimates I gave above. Lets say the featur...

Should testers learn to code?

Should testers learn to code? This question has been discussed on twitter quite frequently, and to be honest is getting a little boring. If testers want to learn to code then they should. If they don't then that's fine as well. This post is my humble opinion on whether as testers we should learn to code. The reason for this blog post was because recently Trish Khoo‏ (@hogfish) asked the question: Should testers learn to code? She did a blog post on the results of the poll, which can be found here http://trishkhoo.com/2017/08/yes-all-testers-should-learn-how-to-code/ In my humble opinion testers should learn to code. For me it is a no brainer and something that isn't about keeping up with the industry trends or doing what is fashionable for testers, its about: Developing skills you may not know you possess Give you the chance to spend more time 'testing' (By this I mean exploratory testing) Making you a more valuable member of your team (Before anyone r...

TESTER PERCEPTION - PART 3

Its been a while since I have last blogged, its been hectic for one reason or another but I find myself with a bit more time so I can finish this series of blog posts. In this post I will complete the set of posts on testers perception. This post will describe ways in which testers can change how they are interpreted. Testers can change how they are interpreted by showing how they add value by changing their behaviours. Below are a few ways we can change how we are perceived as testers,  1) Don't shout louder, improve your argument Shouting louder than anyone else does not necessarily always work. We've all been there, you get quite heated in a discussion about a subject that you feel passionate about and someone else does the same and it all ends in disagreements and potentially damaged relationships. You need to think smarter. If you feel passionately about something on a project then do some research. Come up for valid reasons why you want something to be dif...

TESTER PERCEPTION - PART 2

Now if we are viewed as people on a project that do not 'build' anything, how can that effect our perception as testers? Lets start with a quick definition of perception "the way in which something is regarded, understood, or interpreted. " So the definition of perception contains the word interpretation. If we are interpreted, there is a risk that the interpretation could be wrong, which in turn can affect how we are viewed as testers. Whether it be how we are regarded in our teams or how we are viewed in the wider software community. In either case there is chance that this could be disastrous for us as a community as well as individually. The word interpretation instantly (for me) brings to mind the translation of a foreign language. My wife is German but speaks very good English and there are times where she is trying to interpret what I have said in English, to German. Now sometimes it is very hard to interpret because there is no equivalent word in Germ...

Tester Perception - PART 1

Now the inspiration for this series of blog posts was quiet uninspiring (and expensive). I was having some building work done on my house and this work involved screeding a floor. Basically this is when a sand/cement mix (more sand than cement) is laid on a floor to give a level finish so that it can have some flooring laid on top of it. Whilst I was chatting to the builders (after I had made them a bacon Sarnie and cuppa tea - I like to treat workman well) I thought to myself what do we produce as testers? These guys are 'building' something that will add value, for me the stakeholder. Now, as the stakeholder I could see a difference in what was there when they started and what was there when they finished. To me these builders had 'built' me what I needed. They were, in my opinion, the 'developers'. So it got me thinking about what we produce as testers. If the builders had a tester what would they do in the process of screeding this floor? I would im...

Conflicting Information

In this blog post I will be talking about testing and conflicting information. Now I am a new Mac user and whilst I was playing around with my new toy a while ago I wanted to see how much storage I had left available. So I went into 'About this Mac' and bought up the storage dialogue box.  Can you see spot any issues...........? Now, I did not notice the issues when I first looked at the dialog box as my eye was drawn to the text that stated how much space I had left. I thought "Great,  I have loads of space left" as I had over 140 GB of space left. I then had a closer look........ You will notice that the total amount of space I have left is 140.41 GB but the white space in the space bar (which represents free space) looks a little too short to represent 140.41 GB. Also it states that I have 249.78 GB of space in total but the disk icon text states that I have 251 GB of flash storage.  All of this tells me that there is some conflic...

It's Testing - How hard can it be?

It was said in jest whilst I was walking to my car after work. Me and a developer were having some tester/developer chat at the end of a hard day and he said jokingly : "Its testing - how hard can it be". That got me thinking........ how hard is testing? What challenges do we have testers have to face that can turn a great day into a 'should of stayed in bed' day. Here are some reasons why testing is not always easy and how you can make it a little easier and enjoyable. Just a 'Button Presser' Perception Unfortunately some people have the perception that testers are just people that press buttons and make a few mouse clicks. Yes I'm sure there are testers out there that do this but any tester worth their salt would object to this stereotype. For a 'context' driven tester (by context driven, I mean a tester who sees them selves as part of the context driven testing community) these button presses and key strokes have come after some cognit...