[LRUG] Looking for recommendations for a tester on a Rails project

[James Riley]

You raise some great points Graham, particularly that developers are bad at testing their own code. I've found this is particularly a problem when the application is one where the developers don't make regular use of it themselves. This can be either because what the business offers is not a service they'd personally use or because it's part of a backend application used by other departments of the company, such as the CMS for managing products.  

When working with testers/QA in the past, I've found it to be of great help and rather than make me lazy, have me working harder to pass on stable code to testers, knowing that I'm wanting to get code live and not delay the process. You want to 'put the ball in their court' with as few issues as possible, which also frees up their time to dig into the deeper, darker corners of the app and unearth issues that'd otherwise be overlooked.  

Interestingly, the testers I do know, do not enjoy the role and are looking to becoming full-time programmers so I'm unable to recommend any but would suggest it may be worth considering hiring a developer who's duties would include finding and fixing bugs. You'd get the benefits of having a second pair of eyes, a technically literate tester and the added bonus of the individual being able to fix the issues they find. You'd then simply hire another developer to test this new employees code, who could provide the same benefits, but then you'd need to hire ano… may need to rethink this approach, hah  

James Riley
@mrjamesriley | SupaDupa.me


On Wednesday, 31 October 2012 at 10:48, Graham Ashton wrote:

> On 31 Oct 2012, at 07:51, Najaf Ali <ali at happybearsoftware.com (mailto:ali at happybearsoftware.com)> wrote:
>  
> > Just another data point, but I've had a somewhat different experience to Ronny working with dedicated QA. At the one company where this was done we had one dedicated tester per every five or six developers. They had two basic functions for a given user story:
> >  
> > 1. Make sure that developers had implemented the acceptance criteria.
> > 2. Break the shit out of everything.
> >  
>  
>  
> My experience is similar to Najaf's. I was working in a heavily regulated industry, building desktop applications on top of distributed databases.
>  
> At one point I remember we had 1 tester for every 2 developers, and I think that ratio remained fairly constant as the development team grew.
>  
> We also TDD'd everything that we could. Back then writing automated tests for GTK apps wasn't an option, so we had to check that the GUI was still hooked up and working manually (from a TDD perspective, I find it interesting that the thin view layer that sat on top of our controllers rarely broke).
>  
> We covered acceptance criteria by getting a "customer" to review everything we'd done before we handed it over to the test team. The test team were over worked as it was, so it was important to make sure they were only testing things that solved the users' problems and were likely to make it into production.
>  
> The testers' main role was (as Najaf said) to break everything. I found it amazing how bad at that developers really were. The knowledge of how something has been put together severely limits your imagination when trying to come up with failure modes.
>  
> That's not to say that developers couldn't quickly home in on lots of things that were likely to fail; we could. We just weren't good enough at thinking outside the confines of how we'd implemented it, and that was what was needed to find the whacky stuff that users would stumble into.
>  
> The big difficulty we had hiring testers was finding people who were interested in it. People who aren't motivated to break your app don't do a good job.
>  
> You'd think I should be able to recommend somebody. The only good tester I'm still in contact with taught himself to code on the side, then founded a company with a SaaS app that he built in his spare time.
>  
> --
> Graham Ashton
> Founder, The Agile Planner
> http://www.theagileplanner.com | @agileplanner | @grahamashton
>  
>  
>  
>  
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20121031/3293e1a8/attachment-0003.html>