Work Smarter Not Harder

Do you ever feel like you're under pressure as a tester?  Are you comfortable with the amount and quality of testing that features undergo?  Do you feel like corners are being cut?



This may not be an issue with your people but things may improve if you changed some of your processes.

There are several ceremonies (for want of a better word), which, when executed properly, should result in more reliable software being released to customers.  Carrying out these tasks may take longer in the short term, for example, a story may take 5 days to be finished rather than 3 or 4.
However, in the long term, this should result in customers giving a lot less (negative) feedback about those features.

Some of the resistance to this way of working comes from our innate desire to have everything now, or even yesterday or last month.  So it can be hard to change the short term mindset from 'We can give this to our customers today' (and sweep the risks under the carpet), to 'Lets spend an extra week on this, and make sure it's of higher quality and minimal risk'.  The first mentality may keep your customer happy for a few weeks, until the edge cases start to creep in and come back to bite you as customer complaints. The second option may frustrate some customers in the short term but you will reap the long term rewards of happy customers and a priceless reputation for producing quality software.



Described in these terms it looks like a no-brainer to choose the second approach.  However, when you're in the heat of battle, so to speak, with product managers and customers begging for features now, it can be hard not to succumb to the pressure.


To put into context what I've talked about, the practices we incorporate into our development cycle are very briefly described below.  A lot of people will say 'We already do that' but complacency is the enemy of progress, so it does no harm to constantly evaluate whether you are really sticking to these positive behaviours.


Sprint Kickoff - So everyone, including developer, testers and product managers, can start thinking about upcoming work

Story Planning - To get realistic estimations so customer expectations can be set.  Formulate test ideas to share with the Developers

Team Huddle (Developers and testers get together) - So the whole team can sing from the same hymn sheet on requirements and acceptance criteria before any coding starts.  Specification By Example tests in the Given, When, Then format should be written in readiness for automation.

Automation - Using Specification By Example
You really need to have your developers on board for automation to become a success.  Done properly this should significantly reduce the manual testing required once this reaches the tester. That way you can have confidence the majority of tests have been covered and can focus your attention on edge cases and Exploratory Testing

Demo to Test - Before committing their code the Developer should demo the feature on their machine if possible and allow the tester to test on it.  That way any bugs can be dealt with and fixed before the software reaches the test environment.  When bugs are caught early this can save a lot of time in multiple deploys.

Exploratory Testing (ET)  - This should not be the exception, but the rule for the tester.  If all the tasks above have been successfully completed the testers main form of testing should only need to be the most interesting - ET


It is our job as testers to champion and promote the practices above.  If executed well, it should make all of our lives easier, especially the customers.