Testing the Waterhouse

Apologies for the lack of blog posts recently, just been very busy and finding it difficult to sit down and actually write something that I feel that people will want to read... I've been busy mainly at work, but also with home life too, so it hasn't all been work work work... However, I digress, I have recently taken the initiative to start trying to build a sense of community within the testing team here where I work. I'm trying to do this in a number of ways, one way is the introduction of a Testing Lunch. What is a Testing Lunch? A Testing Lunch (I really couldn't think of a better/more catch word... any ideas?) is a lunchtime session where testers voluntarily (and I emphasise that word) come for an hour lunch where we talk about anything to do with testing. This will hopefully lead to the testers genuinely wanting to talk about testing and get discussions going with testers who possibly work on areas that you've not worked on or maybe done some cool t...

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 :)

Currently where I work there is a lot of discussions around how we can get the QA members to work closer with the developers, almost as 1. A friend demonstrated what they think, and I agree with the following: It demonstrates where QA and Developers were 5 years ago, where we are now (where we work, I understand that it will vary dependent on the organisation and the methodology) and where we will "hopefully" be within 2 years. I don't think it's unrealistic, however, people need to have buy in and want to improve themselves. How can we achieve that though is a big question? I think one of the major hurdles is getting QA and Develoeprs on the same level playing field, get them talking the same talk, help QAs get technical... which leads me to the next image, something that I found on the internet: We as QAs need to get technical, we need to understand code, we need to understand system architecture, we need to be able to discuss technical solutio...

In a lot of companies and a lot of articles that I read online, people say that QA is under estimated, that good QA doesn't get noticed enough, and they're talking about it like it's a bad thing? However, I strongly believe that good QA doesn't need to be credited, the fact that people aren't talking about QA is a good thing, it's not just that no news is good news, but far more than that. Let me give you the example of referees in football, if a referee has a good game then he's not going to be talked about, a good referee is a referee who goes unnoticed, doesn't make any bad decisions, and lets the game flow well. People aren't saying that the referee missed a blatant penalty or sent someone off. To liken this to QA, if everything goes well on a project and and the product is released without any bugs and the quality of the software at the end was of a high standard then not very often will someone say the QA was great, I think it comes ...

I was recently asked about a vision for QA over the next 12 months, where would I like QA to be and how am I planning on achieving that... I thought I'd write where I  want QA to be and document the progress over the next year or so, and hopefully achieve most, if not all, of what I want. Firstly, a big problem where I am currently is performance testing, we hand it over at the end of a project to a third party who then run performance tests on it and come back with results, there are a number of issues that are wrong with this, mainly being we are leaving something that is incredibly important right to the end of a project, so any issues are extremely difficult to fix. So the first thing I want to do is embed Performance Testing right into the sprint, and actually try and do it in an Agile way, I read a blog post here   and really want to try and achieve that, we have the tooling to do it in house, so why wouldn't we do so? Sure it will require some help from experts...

I saw this recently on an internet site I visit and it got me thinking about just how true it is... In order to achieve our goals, we more often than not have to step outside of our comfort zone in order to achieve them. What do you do to challenge yourself within QA? I take on things that I don't know much about, and learn about them as I find the best way for me to learn is by doing. A good recent example of this is working with Espresso, a new API from Google for automating tests on android devices. I didn't know anything about this before I started looking at it, and whilst I'm not a pro at it, I have experience of it, I know how to use it, and I know how to write tests using it, which is what I aimed to achieve when I picked it up at first. I'm lucky to be in a position where I can find things that challenge me on a regular basis, however I have to say, that if it ever came that I wasn't being challenged, then I would look for somewhere that was chal...

The above quote as you can see is from Nanny McPhee, and it's as follows: "When you need me but do not want me, then I must stay. When you want me, but no longer need me, then I have to go" I think this applied very much to my role as a QA Lead, I seem to spend time with teams who need me, more than teams who don't. This isn't a bad thing, I know teams that don't need me will do fine without me, and by helping other teams I help improve them and improve their processes. I recently read a blog by James Bach here  and I think this relates to the above, in that I jump (as James says, A Test Jumper) into help teams as and when I can and as and when it's needed, if teams don't necessarily need my help then I will spend less time with them. Every team is different and has different needs and different level of needs. I've also said the above to an Agile Coach we had who blogs here , I often said to her that she's only around whilst w...

Here's an interesting statistic for you (granted from the USA): Huffington Post have labelled being a QA Engineer as the second happiest job in America When I stumbled upon this article, I had to read the list twice, really? Being a QA Engineer is the second happiest job!? Someone had better tell that to some people I work with... I joke ;) What is it that makes this job so happy then? To me, it's the challenge of learning new things on a constant basis, the past few weeks have been spent trying to get my head around Espresso an automation API from Google for Android apps, I haven't spent as much time as I would have liked with it, but it's definitely challenging, and very rewarding. If I get to spend a whole day on it, then that does make me happy, so there's that I suppose. Then there's the opportunities to constantly try and think of better ways of doing things, improving how we test so we can spend more time well, testing. It's rewardin...

I saw a forum post this morning asking the exact same question as above, and it got me thinking about how much my career has changed in the past 5 years, how much QA has changed and how much Software Development has changed. Firstly, it may be a little unfair to compare what I was doing 5 years ago as I had only just started out in testing, so obviously my understanding and appreciation for what I was doing probably wasn't at the level it is today. However, it's still a useful exercise so I can at least appreciate what i have achieved in the 5 years. I started out at a consultancy, Testhouse, where I would be sent out on site to offer my QA expertise in what ever way was needed. The benefit of this was that I got to see a lot of different companies and how they worked. Comparing then to now, there has definitely been a shift left in the QA world, and by that I mean there has been more integration between the actual development and the QA processes, so much so that they are ...

I came across the below this morning, and I thought it would make a lighthearted blog post.... Does this sound like any QA you've ever met? To me it sounds like almost every QA I've worked with over the past fer years! Often however, they have every right to be worried, and it's this worry that drives us to test things to the best of our ability, so it's definitely not something that we should knock out of testers. I think it's important to have the right amount of worry, and to worry about the right things.

Where I work we use TFS and MTM, and there a number of pain points around it, namely it's slow, and can be difficult to work with if you're not used to the UI, they are 2 things that unfortunately for the time being I can't help with, however, there was one grievance in that passing a test in MTM doesn't update the Test Case in TFS. I can understand why this is, as an Acceptance Test in TFS and a Test in MTM are 2 different things, in that an Acceptance Test in TFS can be run on multiple configurations inside MTM, so why would a passed test in MTM update the Test in TFS? This meant that the testers would have to export the tests in Excel and performa  mass update to pass the TFS test cases, which was a bit of a pain and unnecessary. I did some research, and found other people had the same problem, so thought how it would be great if we could use the TFS API to update all the test cases against the PBI to "Passed" just by inputting the PBI number. The h...

I'm thinking of creating a QA Community blog in my current workspace, you may ask why? What would be the benefits of this? I can think of a number of immediate benefits: - People within the Community will be more aware of what others are doing by their posts on there - People can more easily learn from one another, I feel that by writing up about something, even in a blog post you learn more about it yourself, and the people reading the blog post will also learn from it - It will encourage people who possibly hadn't thought about having their own blog to get involved and contribute There are also benefits for the wider community in that: - People will read it, and hopefully contribute to it outside of asos and offer insights into what might work better etc. - People will read it and want to be a part of it, and thus make the company a more attractive place to work The biggest hurdle I think will be actually getting people to contribute to it, once it is u...

I have been thinking about how I can help encourage self improvement within my team, as I understand it, everyone wants to improve, it's just that often there are a number of things that hold people back. I believe one of these things that hold people back are around identifying skills that they are perhaps weak in or that they could/should improve on. So I thought about how I can help tackle that problem. One solution that I want to try with people is to identify the key skills for a QA, what key skills should every QA have, or at least what key skills make up a good QA? If I can identify these then I can start helping people identify if they are lacking in an area. Sure there is a competency matrix that we have, but it has things like "An excellent understanding of XXX", it's often very difficult to quantify what an excellent understanding actually is. So I sat down and came up with the following key skills: OOP Test Documentation Manual Testing Automated...

For those that aren't aware, BDD stands for Behaviour Driven Development. It is a style of writing (often) acceptance tests, in a Given, When Then format. I've spoke about them in previous blog posts. People often say what are the benefits of them? Why not just write normal tests? Firstly, I feel that BDD isn't just useful as an automation framework, but more of a method of documenting the system that is under test. The Feature files become the documentation, and the great thing is, if the system changes, then the feature files need to be kept up to date to ensure they still pass! Documentation that is always kept up to date sounds too good to be true right!? Not with BDD!!! It provides a living specification of the software under test. Secondly, BDD is a method of getting teams to discuss Acceptance Criteria, and ensuring that teams fully understand the business requirements up front, and it's a great enabler for Acceptance Test Driven Development. Related to t...

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...

It's about a year since I started writing blogs, so thought it would be nice to look back and say how blogging has improved me. Firstly, there have been numerous times when I've thought I wrote a blog post about that, let me dig it out, and use it as my own reference or even for someone else, so it has definitely made things like that easier. It has also made me more knowledgeable about topics that I have written about, if I'm going to write a blog post about something I want to be sure that: I know what I am talking about It's all correct It's articulated in a way that people will understand That's lead to me researching things more, and actually delving outside of my comfort zone a little bit. Then there's reading other peoples blogs to ensure that I'm not just copying what others have written, so becoming more knowledgeable that way, reading other blogs also helps give me ideas about what to write about and ensures that I don't ru...

I recently got asked by a fellow QA, what is the difference between testing a web service and testing a website is? So here is the answer in as simple a way as I can put it... Firstly, what is a web service? It's effectively a function that can be accessed by by other programs over the web. For instance, the asos website has a "basket" web service that enables users to add to their basket on the product page. I understand that from coming from somewhere that only tests a website to somewhere that requires QA to test against web services it can be very daunting, but with the right tools and the right mindset it can be simpler to test a web service than a website. Why is that? you may ask... Let me begin. One of the problems with testing User Interfaces or websites is that there are so many things that could potentially go wrong, you're interacting with the end product. Look at it like switching on Christmas tree lights in the old days, when if one light was b...

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