For the better part of the past year I have been involved in delivering software in a method that is true agile. Our scrum master has implemented the process to the letter. My career background experience was 100% waterfall, then began a mix of agile and waterfall, and today I am experiencing a full-on fortnightly sprint, with retrospectives, story time meetings, sprint planning, daily stand-ups and product owners. The change was quite jarring at first. Ultimately, the adjustment was made and I am now a firm believer in the qualities the method can bring to a software development cycle.
My role as a automation specialist for the QA team has become far more integral to product delivery than any other project I have ever worked. The rapid pace demands a solid regression suite which can run nightly or even multiple times daily. It is incredibly valuable for a agile team that is delivering to the customer at a high rate.
Agile is not for every project – I have had some informative discussions with project managers who are wise to the inherent risks an agile delivery model can present. If your organisation is constrained by regulatory requirements then a more structured and traditional waterfall method is more likely to adhere to the standards required. If funding is tight and far out planning required then also 100% agile may not be ideal. If you find yourself on an agile project and your work in QA then I have some helpful lessons learnt that I hope you may find useful.
- Keep it Simple
- The test objective can change from one sprint to the next. If your tests, manual or automated, require extensive set-up or a high-level of developer support then it is very likely future changes to the functional behaviour will result in a lot of re-work. Always aim to keep the test itself low maintenance. I do this by writing short and very precise test cases. They tend to focus on one functional area rather than cover multiple functions in one go. Naturally, your tests will cross-over to other areas of functionality. Keep your focus on the a singular area and cover the overlapped areas in other tests. However, I suggest identifying one or two comprehensive tests which do feature cross-over aspects for regression. If there are issues in a particular area then you have some targeted tests for diving in which those regression tests led you towards.
- Dynamic Data Sets
- For rapidly changing functionality there are not many tasks more gut-punching than having to re-work a bunch of formatted test data by hand. It is critical to devise a test solution that does not tie itself to a static set of data. Ideally, test data should be organised and displayed from a shared source such as a spreadsheet, webpage, or wiki. If you have the requisite skills then try to code a layer of logic that can turn traceable data into the formatted data set required, like xml or json. This can be utilised for front-end services or back-end databases. Generate it on demand, insert or load or POST/PUT and run your tests – if requirements change then the re-work is abstracted away to be more of a simple spreadsheet editing job. This can save you large amounts of grief.
- Automate the Easy Stuff Early
- This is a bit old hat these days, but the low hanging fruit should always be automated away. The agile team will often have Subject Matter Experts for QA resources who are well geared to understanding the business need, so there is little reason to burden them with low-engagement tasks were value is low. Behaviour Driven Development practices can take some of this headache away from them inherently via it’s models as it tends to allow for automation straight out of the gate. Other approaches require a bit more selectivity as to what, where and how to automate. I aim to take any burden away from the test analyst which requires minimal mind-power and enable them to focus on the gritty details where devils often hide. If you focus on finding the simple bits and square them away early on and save the juicier bits where more time is required. Some fall into the trap of focusing on the hard stuff first which extends the automation development process and end up costing valuable time working the simple tasks by hand. Aim to prevent time wastage.
If you are working in an agile team, whether experienced or a newbie, then I hope this sheds a little light areas or reinforces what you already knew.