Testing the Waterhouse

I recently took part in a PI assessment, for those that don't know what a PI assessment is, it's a behavioural assessment, the PI stands for Predictive Index. It asked 2 questions, and asked you to tick words that describe how you feel in reference to the questions.  The questions were (something like) : - Describe how you view yourself - Describe how you behave in your work environment You then had to tick as many words that you felt applied to the question.  I'm going to take the results of the assessment and hopefully try and explain how this applies to testing and how it makes me a good tester, also how it highlights things that I feel that I need to work on. The first part is to analyse your natural behaviours: ·         You are a team orientated person, co-operative and agreeable you seek harmony where you can. - I think this helps especially in working in an agile environment, where we work in such a...

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...

We've all been there, working on a project when suddenly....

I was recently updating my LinkedIn ( Add me here if you like ) and I was looking through the skills, something that I find as a bit of a pointless feature, well, the endorsing of skills is a bit pointless, as I have people who I've never worked with endorsing me for skills that they really don't know I have, it's nice that they feel they can endorse me but it happens so often, that it kind of makes endorsements pointless? Anyway, I digress... There was a skill in there for the Software Testing Lifecycle, and I thought about it, and what it meant. It's saying that you can have a skill in just the software testing lifecycle, but in my opinion, we should be moving away from this, we shouldn't be focusing on just the testing phases, we as QA should be involved from the offset, and hence, we shouldn't just be having a Software Testing Lifecycle as a skill, we should be aiming for having the Software Development Lifecycle, as we are all (Devs and QAs) involved in t...

I often try and think of ways that I can offer value to my company by going above and beyond that of a standard QA. Whilst this will vary from company to company, I've decided to list ways that I try and go above and beyond in my company and my role to help out and offer as much value as possible. These are in no particular order, but here goes: 1 - Share your domain knowledge, whilst this should be a given, all too often this isn't the case. If someone asks for help on a particular subject, help them, don't just say I'll do it and let you know when it's done. If you show them then they will hopefully learn and be able to help others, and become less reliant on you and your time. 2 - Offer your help whenever you can, if you do have an expertise in a particular system, or something you have worked on in the past, when issues arise, don't shy away from offering advice, or offering solutions to problems. This will get your name out there and people will tak...

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds. We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit. [AfterTestRun]         public static void AfterTestRun()         {             var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());             if (!nativeDriverQuit.Wait(TimeSpan.Fr...

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