Testing the Waterhouse

No real point to this post other than I have had the song stuck in my head and figured I could change it slightly and quite easily make QA is Awesome! Oh and I haven't even seen the movie all the way through! But for some reason that song is incredibly catchy! Not much point to this post in fact, just thought I'd put it out there :)

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...

Apologies for the lack of updates recently, I've been very busy (kids, work promotion), but I've also got a few blog posts lined up for the next month or so, which i think you'll enjoy, here's one of them for you! I was thinking the other day over what makes a tester happy, and I thought I'd write down my findings, and share them with you, this isn't necessarily what makes me happy, but more around what I think can make any tester a happy tester :) 1 - Grow with your testing - Always look to progress as far as you can, never stop challenging yourself. 2 - Relationships - Relate with your other team members, become personable with them and talk to them about day to day stuff and not just work. 4 - Extra Mile - Go that extra mile to make things work, people will respect you for it, and people will do the same for you if you ever need it. 5 - A difference - Making a difference makes you feel valued and makes you feel part of a team that is delivering goo...

Many people are unfortunate enough to be in a job that they don't like, I won't use the word hate, as that's a strong word, but I'm sure it applies to some people. I'm lucky, in that when it boils down to it, I do enjoy doing what I do, I enjoy coming to work (and not just to get out the house!) I recently spent time off from work for 3 and a bit weeks, I must say I missed work, I missed the routine, but not only that I missed the people, the actual work I do, the challenges and just keeping my brain active. Sure enough we have bad days where we don't want to come back to work, and maybe the fact that I enjoy QA so much is about the environment I am in, and the people I work with, but I'm lucky to have worked in a number of places and enjoyed almost every one for different reasons. Drilling down into specifics, "Testing and QA", I thought what is it I love about it? Hence this blog post.... When I first started out in testing about 6 years ...

I was listening to the above song today, and thought it applies a lot to QA and Developers! QA and Developers need to be on the same page, they need to be able to discuss issues together without a few of every concern being blown into an argument. This works both ways, Developers need to help QA understand their changes, so that they can ensure that it is tested in the correct way. Some of my best friends in the workplace are developers, and I think it shows in how I test.

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 ...

In my post Testing of Automated tests , I mention about a BDD framework which involves using BDD to drive your acceptance tests. BDD stands for Behaviour Driven Development.  One effective method of writing BDD tests are by using a format known as Gherkin language. These consist of Given, When, Thens. The main advantage of the gherkin language is that it's readable by the business, and in an ideal world forms part of the Conditions of Acceptance around a PBI. Also, using a Visual Studio plugin of SpecFlow , you can integrate your Gherkinised COAs into your solution with feature files, and then drive the automated tests, however, for this post I will focus solely on how to effectively gherkinise your acceptance tests. A Feature file consists of a feature outline, which details what the feature file is testing followed by Scenarios and examples (parameters).  The BDD scenarios are made up of a Given, When, Then... These are effectively an initial state (Given), an action (W...

I've been told in the past that I need to raise my profile within the QA community, not just in work but outside of work as well. I need to be more vocal and speak out more in work, and get people to know me, which I have started to do and am quite enjoying it. In light of this I want to offer advice to other people about how they can raise their profile within the QA community outside of their workplace, as well as in their workplace, as raising one will hopefully raise the other. Firstly, I never thought I would get into this blogging malarkey  but I can definitely say it has helped make me a better QA. Someone once said to me that blogging is useful as it might help someone learn something, and if not, then it can help you and is a good point of reference if you ever need to look back on anything. I also find it quite therapeutic by writing out about how I feel about certain aspects of my job. This will help raise your profile inside and outside of work, share your...

I've recently been asked to help devise a mentoring plan for a new QA associate. I sat down and thought about it, and thought it would make a half decent blog post, so here goes! In order to come up with a plan, I needed to identify key areas of QA that as a new QA I would appreciate. I came up with the below areas that I feel would benefit most new QA members: - Automation Selenium IDE moving onto Selenium WebDriver perhaps SoapUI Pro Obviously these will be domain specific, so if you're using QTP for automation, then obviously try mentoring in that etc... In fact this can be applied to much of the below. - SQL - C#/Programming Language - Writing Manual Test Cases - Exploratory Testing - Writing Bug Reports - Testing Tools Fiddler Browser AddOns Test Case Management/Defect Management (Be it Microsoft Test Manager, Quality Center etc) -Performance Testing -Cross Site Scripting/Security Testing -Breaking down a PBI  COAs GWTs - Release testing - Involved i...

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 recently read a blog post about the state of QA in general, and it really opened my eyes to realise that it isn't just in my current company where testing is in a state of anarchy almost, but at least for my own sanity it appears to be in a number of places. The blog in question is here , and it references an article available here . Like the blog, I do not agree with everything in the article, but I will elaborate and discuss the key topics in this blog post. I was going to write a similar blog post, around the state of QA contractors, however, I feel that it can now be coupled together into this blog post. To be honest, first things first, it was a bit of a relief to realise that this is an industry wide problem, and not just isolated to where I am at currently. It is something that I care passionately about, as all too often, I see people hired by companies as QA professionals, but in reality, I have no idea how they can claim to be one. In the blog post, it's ment...

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...

Manual testing is a core function in any software development lifecycle, but with automated tests, will there ever come a time when there is no manual testing done on a product? Automated testing is extremely powerful when used in the right way (see Testing Automated Tests blog post ), and when used in the right tests (see How to decide what and when to automate ). So, obviously, the next big question would be, if I can automate tests, do I really need to spend time and money running manual tests? As manual testing is often one of the biggest overheads at a company in terms of releasing a product to live. An automated test, no matter how robust and how good you might think it is, will never replace that of a truly awesome manual test. By a truly awesome manual test, I am not necessarily talking about the steps in the test case, but about the testers knowledge of the system, as that will never be replaced by an automated test.  Another thing that I dont think automated tests ...

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...

Firstly, let me remind you of the following scene in There's Something About Mary: Hitchhiker : You heard of this thing, the 8-Minute Abs?    Ted : Yeah, sure, 8-Minute Abs. Yeah, the exercise video.   Hitchhiker : Yeah, this is going to blow that right out of the water. Listen to this: 7... Minute... Abs.    Ted : Right. Yes. OK, all right. I see where you're going.    Hitchhiker : Think about it. You walk into a video store, you see 8-Minute Abs sittin' there, there's 7-Minute Abs right beside it. Which one are you gonna pick, man?    Ted : I would go for the 7.  The quicker something can get done the better right? Within reason of course.... On any project that involves some form of testing, you as a QA will be required to write some form of a test plan document.  Everywhere I've been has done this slightly differently,  but the premise has been the same to let people know what it is that is going to be tes...

I recently read a presentation on exploratory testing by  +Elisabeth Hendrickson  on exploratory testing, and it came with an interesting solution to Exploratory Testing, one that offers enough guidance, but isn't a test case. The slides are available here . I'll take the pieces that I strongly agree with, and discuss them here. Firstly, defining what exploratory testing is. This is very important, I believe that a number of people view exploratory testing as just randomly using the application under test and trying to break it in any manner possible when in actual fact it should be much more than that, in order to actually be useful. It should be: Targeted Structured Well defined In order to execute some exploratory testing, I think there needs to be some knowledge of the system under test, how it should behave, and the dependencies of the systems. The tester learns about the system as they begin testing, this information can be fed into the next test, and so on. T...