Testing the Waterhouse

I was recently at a conference, and we did a Goldfish bowl discussion on will automated testing ever make manual testing redundant. Things got heated, and whilst I don't think anyone ever said that automated testing will indeed make manual testing redundant, there was one interesting comment about a tester who has made it to the top without ever having written an automated test or written/seen a line of code, which is a pretty impressive feat, but not something that I would say as an argument against learning how to code. However, I didn't think of this scenario until afterwards, but it reminded me of when I was at university in an American Football team, I won a number of awards and coming to the end of my time at university, there was a discussion within the team about making gym sessions compulsory in the future, I disagreed, and still do, but used the argument that I've got pretty good at it and very rarely attended the gym. However, looking back, I think how much b...

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used. A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog. The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now. A Product Backlog Item is made up of the following: Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that. Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follow...

Apologies for the lack of updates, it's been a busy week, had my 3 year wedding anniversary last week, so was busy sorting stuff out for that, and had a bit of a hectic weekend! :) Anyway, I've recently been reading a lot about mindmaps, and how they are useful when brainstorming and coming up with areas that may or may not need testing when a story/pbi comes in. I started to wonder what the fuss was about, so I recently created a MindMap for a recent blog post here  and found it extremely useful. So let me go over how they work, and then I'll explain how I personally find them helpful and hopefully you will too. They are an extremely simple concept, you have your theme in the middle and off of that branches anything that you think is related or want to investigate, and then you can have branches off of them too... And so on... I find that the mind will naturally flow from one area to the next, and you won't have to think too hard and you won't forget im...

Having recently read the following blog about how to improve communication from a developers perspective, I thought it would be interesting to have a QA perspective on it... Firstly, communication is key to being a good tester. When someone speaks about the skills of a tester, one thing that I think is one of the top things to look for, is that of a good communicator, someone can have the best technical knowledge and skills in the world, but if they can't communicate what they were doing or how they found a bug, then they would not rank highly in my book. So how can you improve communication between the QA and the developers, firstly, I don't think you should look at you all as being part of one team, delivering a quality software product, do not have an us vs them attitude, when bugs are raised late on, it's your fault as well as it is the developers fault, you are one team. There is no I in team.  To help in this, it can work in your favour to be careful when raisin...

Anyway I'm writing a post on creating my first set of unit tests by myself for a small console app that a colleague created, and I thought to lead up to it I'd write a brief post explaining the importance of unit tests, why they're important and how they can make our lives as QA easier. Wikipedia defines Unit Testing as " unit testing  is a method by which individual units of  source code , sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use". So essentially, in everyday terms, it's the smallest possible piece of testable code. Some people would argue that unit tests are a developers task, but I feel being the first form of QA on the code, that it's only right that as a QA you should play some role in coming up with then. Now you don't have to be able to write the unit tests, but at the very least you should sit down and come...

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager... In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools. Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block.  One of the more popular tools is that of Microsoft Test Manager, it...

So I've got in touch with my old QA friend, Richard Lee and we spoke about guest blogging on each others blogs... Richard is an IT Professional for a FinTech based company in London. His activities vary from Release Manager, Build Manager, Database Administrator. Working in a Microsoft workshop, his expertise lies in MSBuild/Workflow/Powershell/SSAS/SSIS/SSRS/SQL, basically whatever isn’t anyone elses’ problem is Richard's problem! When not solving other peoples problems he can be found blogging at redphoenix.me , and jogging to and from home, where he lives with his heavily pregnant wife. Hello, my name is Richard, and I am a former tester. Like most people and their careers, I fell into testing; I first got into testing about 6 years ago, after I had graduated. I went to a university where the attitude was that you should try to get on a graduate scheme with one of the big companies. If you weren’t interested in that, well, good luck with getting any support from ...