Testing the Waterhouse

This isn't necessary a QA centric post, but I felt that it's something that has affected me and I feel like I should say. We all have career influences in life, people who we meet throughout our career who have a profound affect on the actual career path that we take.  I am soon going to say goodbye (in that she left the company) to one of these people, she was someone who would always push me to do my best, and is partly the reason why you are reading this blog. She pushed me to get into blogging (along with others, and you can read her blog here ), but she's had a major impact on my career and as such my family. She's someone who really pushed upper management to recognise my talents, and helped them come up with a 6 month career development plan that I hope will get me to where I want to be. I owe her so much gratitude, and I don't think she realises just how much everything she has done for me actually means. (And to think she's not even a tester...

In light of the recent (well I say recent, I mean just over a month) news about Edward Snowden whistleblowing on the NSA and the Prism programme which detailed how the NSA were afforded direct access to data held by companies such as Facebook, Google and Apple, I thought it would be interesting to discuss how data in general can be used (legally) in helping define a test approach. Obviously the Snowden whistleblowing is about a lot more than just data like I'm going to be discussing here, it's about being private online, in my eyes Snowden has done a very brave and very good thing for his country and for the internet community. What happens next with regards to the American public and their willingness to challenge the government will determine if it was worth it or not. (You can read a timeline of events on Snowden here ). However, in relation to testing, a big pool of data with regards to your application/website will come from analytics, be it WebTrends or Google Analyti...

I was recently at a conference that discussed the use of Crowdsourcing as a form of effective testing for your company. Firstly let me go over what Crowdsourcing is. Wikipedia describes Crowdsourcing as: " the practice of obtaining needed services, ideas, or content by soliciting contributions from a large group of people, and especially from an online community, rather than from traditional employees or suppliers" So in testing terms, it's getting an online community of "testers" to test your software. So why would you use crowdsourcing to test your software? What are the positives? The big positive for me is that you're letting the people who would potentially use your application the chance to use it and report any bugs. These testers might use the application differently than you intended though? This to me however is a good thing, if they are using it in a certain way, you can bet that the general public or whoever might use your app would us...

In light of another flop at a major championship for an English national team (Under 21s European Championship), and reading the following article on sports psychology and what sports professionals can do to be at the top of their game, it got me thinking what can a tester do to stay at the top of their game? What type of mindset is important for a tester? I find that all too often, people in testing just glide through without trying to further themselves and improve themselves. In the article above it highlights 6 ways that a sports professional can maximise their potential through the right mental attitude, I will take these and adapt them so that they can apply to a tester: Focus on success Focus on releasing successful software, (if that is the goal of the project), in fact we can make that broader by saying that we should focus on a successful project, and to be a part of that success and try and do everything you can to achieve said success.  Try not to get drawn in...

So I was recently reading this blog post , and it raised some interesting thought processes. I'd never really thought of testing being dead as it states in that article, instead I tend to think of it as evolving, evolving from having a myriad of test cases that need to be run as part of regression, or even as part of acceptance testing, to instead a more flexible approach. I recently worked on a project, which had a massive constraint on time, effectively the business wanted it released to the customer as soon as possible, and it was a high priority project too. This meant that I could go about testing it in a different way to how I would have previously. Instead of writing an abundance of acceptance tests for any features, I'd write GWTs or even perform exploratory testing (documented of course - a pet hate is exploratory testing that isn't really documented, see my blog post here ). The biggest drawback to this "release it as quick as possible" approach wa...

I'm sure you've all heard of the automated testing pyramid, I'll describe it briefly here, but you can read all about it here . It's essentially a strategy that shows good practice ratio of Acceptance Tests (generally UI) to Integration Tests to Unit Tests, and here it is here in a simple form. It states that it is a good ratio to have your testing covered with 10% of acceptance tests, 20 % integration tests and 70% unit tests. Why is that you may ask? The primary focus of this is on Return on Investment, by finding bugs/breakages at Unit test level you are finding cheap bugs, as Unit Tests are quick and easy to maintain, whereas acceptance tests, whilst having value, are harder to maintain and take longer to run. Obviously, it's not a strict ratio, but I think it's a good practice to try and live by. However, I digress, the main point of this post is to put another spin on the automation triangle, and is possibly more QA centric than the automation ...

I was listening to the above song today, and thought it applies a lot to QA and Developers! QA and Developers need to be on the same page, they need to be able to discuss issues together without a few of every concern being blown into an argument. This works both ways, Developers need to help QA understand their changes, so that they can ensure that it is tested in the correct way. Some of my best friends in the workplace are developers, and I think it shows in how I test.