Skip to main content

Posts

Showing posts from 2016

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

Selenium Framework - Lessons Learnt

Before I start going through the lessons I have learnt whilst in the midst of writing a Selenium Framework I would like to say that I am by no means a 'Hard Core Developer'. By this I mean coding is not my day job and I am not up together with all of the latest coding practices and lingo. Yes I have done some coding in the past but it has usually been with the help of more experienced developers. There is some debate about automated testing vs manual testing. Automated testing (which I believe should be called automated checking) can compliment a more exploratory testing approach and can provide useful information to the test team about the quality of the software under test. I think there is a market for both types of testing and combined they can teach teams a lot about the software they are producing. Overview The Selenium framework that I have started writing I have done in any spare time I have managed to find myself with. As mentioned previously I have done some cod