Testing the Waterhouse

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...

Over Christmas I had the pleasure of taking my son to see Santa Claus, however unfortunately it gets rather busy if you don't prebook online, we decided in the morning on a Saturday, that we'd take him to see Santa that afternoon, so decided to look online to book to avoid the queues. So I logged on, and went to book online, however unfortunately it would only allow you to book for the next day and you couldn't book for the same day, as it wasn't selectable in the drop-down.  Luckily for me, I selected tomorrow and went to confirm in case we decided to go tomorrow, I happened to have a look at the URL that it generated, sure enough the date was in the URL, so I changed the date in the URL to today and it managed to take me to a confirmation page with a confirmation number confirming my appointment for today! :) Finley will be pleased, and so would mummy and daddy at not having to wait in the queue. So we got to Santas Grotto, and sure enough the queue was massive,...

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

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