Testing the Waterhouse

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

I've often mentioned how important automated tests are throughout my blog.  However, automated tests can also give false positives... This is where paired programming and testing of the automated tests come in to play. The example I am going to use employs the Page Object model with BDD, more of which can be read about here  and here , until I get round to creating a new blog post on it... Scenario Outline: Search for generic term Given I am on the homepage And I have entered <searchterm> into the search box When I click search Then search results for <searchterm> are displayed Let me explain anyway, if we have an assertion in the step definition for the Then step (written in C# using NUnit) that does the following: [Then(@"search results for (.*) are displayed")]         public void SearchResultsForAreDisplayed(string searchTerm)         {             Assert.I...

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

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

When I first started out writing manual tests, I was really keen to do every step in minute detail and write out the expected result for every little step. In an ideal world where time is no constraint, resource is no constraint and updating the scripts is no constraint.. oh and the person writing the scripts didn't get bored.. then this would probably be the best way! However, in the business world, we have all these constraints!! The business want features yesterday, they want these features delivered with the minimal resource within the acceptable time frame and they want new features further down the line that make the old features redundant.  With the above in mind, it's important to address, what makes up a good manual test? As these tests may or may not be around forever.... I think in order to answer the question above another question needs to be addressed, which is: Is it going to form part of a manual regression test pack? Or is it throwaway? ...