Testing the Waterhouse

I was recently reading a good friend of mines blog  Helen Meek  where she discusses 3 zones that are related to how you work, i'll briefly explain them here, but you can read the blog to find out more: Comfort Zone: This is where you're effectively coasting along, not challenging yourself in your day to day job. Learning Zone: This is where you challenge yourself and are learning new things constantly. Panic Zone: Where there's just panic, you may be challenging yourself, but probably not having the time to learn new things. I think, that too many people in Engineering are stuck in the Comfort Zone. They are bored easily, but don't want to do anything to change that as it involves challenging themselves and what they know. I want to help get people out of the comfort zone, but doing so isn't necessarily easy. To me, like most people I would bet, I'm most happy when I'm in the Learning Zone, I get bored and restless in the Comfort Zone, and the P...

You're gonna need a bigger boat? How can that relate to Engineering? Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter! Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"... We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker. If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.

I thought it might be a bit fun to do a series of blog posts where we take a famous movie quote, and apply it somehow to QA/Testing or even the software engineering life-cycle. This is one famous movie quote, and I think it applies greatly to Engineering in general (or anywhere in fact)! I don't think a week has gone by in my career where I couldn't have uttered the following: What we have here is a failure to communicate (Cool Hand Luke) I saw this quote (although I haven't seen the film), and I don't even think it needs any explanation.... But I'll explain anyways! I would say that 80% of problems that are in a workplace are down to a failure in communication, if a bug is found, a failure to communicate the effects of the bug properly can lead to a false severity, or a false priority. That's not the only time when a failure to communicate can be damaging, especially for QA, but a failure to communicate when understanding requirements or when explain...

I've recently looked into creating a QA forum, at a request of a number of team members, where members of the QA community inside where I work can post questions or blog posts and share them with others. The benefits of using something like this over email is that it keeps everything in one place, it stores the questions for ever, so if we have new starters and they have a question they can look at these sites first before sending out an email. I've suggested OSQA as the question exchange software and we are just going to use a standard wiki for the blog post /information storage. I got asked how can we ensure that its kept up to date? As it will only really be useful if it is kept up to date. The simple answer is, that if it's not kept up to date then obviously people aren't using it so it's not that much of an issue if that is the case. If people are using it consistently then it should in theory stay up to date and be an excellent source of information fo...

We've all worked as part of a team as a tester before, whether that be in an Agile team where you work directly with developers or in a QA team in a more waterfall environment, but have we ever looked at how we can improve our relationships within the team? I'm not necessarily talking about nights out, although that undoubtedly helps, I'm talking about team relationships and enhancing them as you see fit. It's been a long time since I worked in a Waterfall environment, however, I think the same principles apply to waterfall as they do for agile when it comes to team relationships. When working in a team, the following are key principles that I think you should follow: Team first - Put the team first before any personal gain, if you are up for a promotion for instance, then don't just think about yourself, don't put your personal objectives above that of the team, this will be noticeable. Communicate freely with the team - Often I've been in teams whe...

We've all been there, we've fixed a bug, it went live, but then a future release broke the code that fixed the bug, and the bug was reintroduced, also known as a bug that has regressed. What if there was a way we could guarantee that bug could never be re-introduced into live again, that would be great right? Well, there is! If you already have an automated testing pack, be it in QTP, Selenium, CodedUI etc. then all you have to do is create an automated test that tests the bug, this test could even be a unit test (depending on the bug) and ensure that it is run before every release (even more often in an ideal world, as early feedback is good feedback). This way, if the automated test fails, then you know you have to fix it, as the bug has been reintroduced :) If you don't have an automated testing pack, well, if you can, create one! :) But I appreciate this isn't always possible, so in this case, create a manual test case and add it to a regression pack, to ens...

A recent project I was on meant testing a lot of legacy code,  in fact I think it was all legacy code! So I thought I'd write some bits about what the challenges are or what you should look for. Firstly, let me start by defining what I mean by legacy code. I have seen definitions of legacy code which state any code without unit tests can be defined as legacy, whilst this is true, I also like to think of legacy code as something that isn't being refactoring, isn't being improved upon, it is what it is, to quote Ronseal "it does exactly what it says on the tin". The problem with the Ronseal analogy, is that what happens if you can't find the tin? Or you can't make sense of the tin? This brings me onto the first challenge... In that if it is legacy code, and there's no supporting documentation around how it works or what certain features are for, then it makes our lives as testers (and developers) difficult. We have to ask questions over what certain ...

We have recently created an automated test suite to replace some of the manual tests that we used to run for regression. I'm finding the below more of an occurrence now!

I have in the past questioned the value in getting certifications/going on courses for the sake of getting a certificate in testing. Whilst I do still question the worth of such an issue, I have recently read some articles which has shown me there is more value in these courses/certificates than I previously gave them credit for. The main positive that I can think of, upon completing a course like an ISEB Foundation, is that it ensures that testers are on the same page when it comes to communicating. A bug is a bug, or if I'm speaking to someone about Integration testing, they know exactly what I am talking about and won't get confused. I think in ensuring that everybody is on the same page when it comes to discussing testing issues/testing activities, it helps in gaining respect and confidence from other teams and other team members, as we are all singing from the same hymn sheet.  It isn't just about communication in the term of words however, it is impor...