Testing the Waterhouse

When I first started out in the Software QA world, my job title was a Test Analyst, which I disagreed with, we weren't just testing software, in my eyes we were doing far more than that, and still are.I often hear people talk about software testing and QA in the same sentence as much the same thing. They are not the same thing!! By QA I mean, as I'm sure you're aware, Quality Assurance. Testing can form a part of that QA as an activity to help ensure quality, but they are not and should never be classified as the same thing. Testing to me, is the physical act of ensuring that software works correctly, and that tests pass. QA is more around ensuring quality in the product, not just through testing the code, but from discovery, requirements gathering, test case design and test case review. As a QA we shouldn't just accept requirements as they are written, we shouldn't just accept design documents, we need to provide a quality gate throughout the life of a proj...

So one of my objectives is to be able to offer more in regards to Performance Testing. Whilst I understand the basics, I figured I'd write them down and start a series of blog posts hopefully detailing my findings and explaining why performance testing is important, and the different types of performance testing. In order to understand why performance testing is important, it will be good to know some of the more popular types of performance testing are.... Load Testing This is testing a system to understand and analyse the behaviour of a system under a specific expected load. This is probably the most common form of performance testing, it is useful in identifying any bottlenecks in a piece of software.  Stress Testing This is testing a system to breaking point, so that you can understand the point at which the system fails and under what load. Endurance Testing Similar to load testing, but this will be load under a prolonged period of time, in order to gain confidenc...

I've had people ask me in the past that they are trying to get into QA, but don't really know how, so I thought I'd write a quick post on what I would do if I wanted to get into QA now... This post is going to slightly contradict my previous post, in that I recommend at least getting qualified, I would recommend ISEB Foundation qualification, whilst in that post I argued against the qualification route...  However, let me explain myself a little, the ISEB qualification, rightly or wrongly, is required by a lot of employers who wish to get into QA, and whilst it does teach you the basics, being a QA is a lot more than that. It's about having a passion for it, about having the correct skills and technical knowledge. So whilst I do recommend the ISEB qualification, this is only the start of things. One thing that employers love, and rightly so, is passion. A passion to be the best in your field, a passion to find bugs and break things definitely helps. But how can yo...

With so many browsers to choose from nowadays, it's important to choose the right one. For me, the wide array of add-ons that are available to aid my day to day job, definitely play a part in my choice. I choose Google Chrome, having an Android phone, means I can sync my favourites between my Mac, my phone and my work PC (100% personal reasons! There are some professional reasons below!) There are also a wide array of add-ons that Chrome supports that helps make my life easier, and I strongly recommend any QA have when testing a web UI. These are the ones that I use on a regular-ish basis: Fiddler - not really an addon for Chrome, but essential in monitoring HTTP requests and responses. It enables you to change requests/responses by setting breakpoints etc. Fiddler in itself could and one day will have a whole blog post about the benefits and the uses and how it can aid with testing.  Fiddler can be downloaded from here FireBug - This is essential. I can not understan...

In a previous post ( The Defect Dance ) I mention the first point when finding a bug, "Can it be reproduced?". If the answer is no, I mention to make a note of it in case it happens again... However, this is a bit of a simplification, there's a lot more to it than "Can a bug be reproduced?" Yes/No... Bugs for whatever reason, can be intermittent/transient. Some bugs might only appear under very specific scenarios, under heavy load etc.  We've all been there as a QA professional, where we've experienced some quirky behaviour, that on first instance appears to be a bug, but you try and reproduce it, and you can't, and we all know that a developer will only be interested in a bug that is reproducible! So what's the next step? For the sake of this blog post we'll use an error on the asos website, for when you try to add an item to the bag... So, don't immediately try and recreate the issue , I once read an interesting analo...

Many times when testing, especially in Agile, it's important to communicate with the team any issues be it environmental or code related.  A common misconception of Agile is that it's best to not document anything and get things done as efficiently as possible, often this means cutting back on the amount of documentation that is written.  Whilst I agree that too much documentation is a bad thing, every project needs some form of documentation, be it hand over documents, a wiki on what it is that's been developed and how it works or even a set of Given When Thens (More on this in a future post! - In the meantime look here ) of the new functionality, this all helps with future teams being able to look at and read and will hopefully help any future development around the areas. I am however, all too aware, that far too often people send round documents, that 95% of the time don't get read, and just get forgotten about. So it's definitely important to strike the ri...

When you find a defect in your test environment, it's always a nice feeling. You've managed to discover something that likely no one has discovered before. When you discover a defect, what do you do next? Do you just raise a defect, after all the team needs to hear about how awesome you are, do you speak to a developer.... Here's a handy little guide that you can use to ensure that you are as effective as possible as a QA. Ask yourself the following questions: Is the bug reproducible? If the answer is yes, then you've found a bug!  If no, then I find it useful to make a mental note of the issue in case it happens again... Is the bug in live? If the answer to this is yes, then search the bug database, it may already have been logged, if it hasn't then raise a support issue or raise a bug, depending on what the company procedure is :) If the answer is no, then still, check to see if the bug is a reoccurring bug and if it had been fixed previously and bro...

Bugs are a testers bread and butter, it's what we live on and thrive on raising. However, my pet hate are bugs that just aren't very descriptive. I've seen bugs in the past with the simple message "Search is not working"... This wastes time of a developer who will then have to debug and find out for themselves when/where search isn't working, why it isn't working and then fix the issue. It also reflects badly on QA, which in previous posts is something we have to fight against! This does tie in when should you raise a defect (more on this in a future post), as I like to go by the principle of if it will take longer to raise a bug than to fix it then don't raise it and just speak to a developer and explain the situation, giving them a walk through if needed, and then wait for them to fix it and test it again. Obviously this isn't always the route that is chosen, and when a fix for the issue will take a lot of investigation or time to fix, then a...

We all know that repetitive manual testing can be and is at times boring.... but unfortunately it's a necessity for some aspects of testing. One thing that I love, and sure enough this reduces the load of manual testing, is automated testing, be it from the Service level, through an API and especially WebUI testing. Whenever any testing comes along, there is a question that is regularly asked by QA, do we want to automate this? When deciding what tests we should automate I feel that it's important to answer some questions: Will this test form a part of the regression pack for the application? Will this test be run multiple times during the development process? Can the same level of testing be achieved by automating this test? I'll tackle the first question, as it's the most basic and the easiest to answer. If a test is to form a part of a regression pack, then yes it should be automated. The reason being that it will save time in the fut...

Having been involved in QA for over 5 years now (where does the time go?), I've felt it's time to start documenting my thoughts on life as a Test Engineer/QA Analyst/Test Analyst etc. I've been in a number of different companies, and through no fault of my own, I've felt I have had to earn developers respect as a QA no matter what company I have worked for. Let me start with an example, I had been in testing approximately 2 years, when I joined a hedge fund, where simple bugs can cost millions of pounds. I arrived into work one morning and a developer grabbed me, he said to me that he'd put some code live the night before and needed me to test it.... Yep, that's right, I needed to test something after it had gone live!? At first I couldn't believe what he was asking me to do, but being relatively new to testing, and probably not confident enough, I tested it and sure enough it worked fine. When i mentioned it to my senior, he was horrified (and rightly s...