A lot of developers would prefer to be out-of-range of testers – if you want to get into testing, then be prepared to justify your existence by any means necessary. Developers are awash with different types, from geniuses with Aspergers, to self-taught amateur with insecure chip on their shoulders. It’s not your job to judge, it’s to adapt – testing is always about adapting, and in some ways mirrors the demands of a developer career. But without us in QA, the SDLC can descend into a private club, excluding those perceived as “in the way”. It’s a fine line between squashing developer creativity, or allowing developers to run amok. Of course a decent Scrummaster should prevent this, but we are in the real world here.
As my manager at Disney observed, I like chaos because of satisfaction of bringing order. I am a test manager, but because of the industries I have worked within (digital media, creative, publishing, broadcast), I am more used to role of QA Manager. Expectations in those industries is generally different, as the term “QA” is more frequently referenced than testing. Though not to do with Agile specifically, the Test Manager role has changed. It can be little more than a more all singing and dancing tester. Or it can be a QA Manager – I am convinced that roles are advertised largely on budget constrictions:
- We can’t afford a full-on Tester, so we use anyone available with a vague interest in testing (developer puppets).
- We can’t afford a full-on Test Manager, so we spec for a test manager but job title as Tester.
- We can’t afford a full-on QA manager, so we spec for a QA manager but job title as Test Manager.
After much research into Agile before I realised I was simply trying to redefine agile – like numerous people before me. When I thought about my experience and my opinions, what is generally missed is importance of role assignment, i.e. the team. Secondly the methods of evaluating processes for a project – relying too much on methodologies as user guides rather than just guides. The myriad of sub-methodologies came about because someone decided the guide needed more for their project. Their methodology was publicised and the whole circle happens again. Everyone has an example of the Agile project that goes well – I guarantee you if you scratch the surface you will find problems. Even in the most perfect setups there are problems – big news, there always are!
- Test automation won’t make poor project management better
- Good project management won’t make a bad development team any better
- Leaving development to run to their own methodology won’t make poor specifications any better
The project team is all – spend time of resources, time evaluating process, and at least the project will be at good starting point. Good developers are hard to find – the best ones understand the value of the tester, the external view to their closed off world of localhost and development environment. Good testers are also hard to find – even harder given the proliferation of chancers that have used the Agile-related demotion of the tester to get into the industry. Good tester can plan, script, test AND communicate. It’s very important that the tester is bonded with the development team, but know when to step back. I always recommend the “friendly professional” approach – social interaction is important, as is collaboration. But know when to step back and be QA. Dangerous assumption #1 – All developers are Agile! If only.
Scrum is by far the most popular of Agile methodologies, because it is the easiest to use as a user guide. Now this can still have degrees of success, but what is key about Agile and Scrum are roles. Product Owner is there to ensure end product meets requirements, and is meant to be in charge of user stories and task management. Scrummaster is an team leader – but more – a barrier between development and business, which is by no means a negative. Development is a focussed task, and minimal interference in developer time is a good thing.
Which brings me to the more vaguer element of Agile role definitions, “the team” which largely contains development and testing, but also intended as a catchall for related project resources). Very little is mentioned about test management – in fact I rarely see other test managers in course of my contracting – I have usually been brought because of issues around testing and formality. In the last decade testing itself, was effectively demoted to task rather than role. The floodgates opened to whole new breeds of testers – a large proportion of which just shouldn’t have been in that role. Testing like development, is a discipline – tied up in the SDLC, but also a point of verification between development and end-client. We in QA have failed to keep up – as business also has. I rarely meet other Test Managers – my recent venture back into corporations, I have met more. What a QA Manager would do, as would a good tester is highlights issues in development process.
Waterfall’s weaknesses was the length of time between developers completing code and build/integration. Developers are working on builds – Agile method ensures that developers are all working from more or less the same build. This minimises the major cause of delays – integration, impact of one features/function on another, that wasn’t predicted.
Waterfall release cycles may comprise of a few weeks development time, and a week or so testing cycle. Agile development, when applied, is a very efficient machine
Iterative and incremental – smaller features, build, integrated and unit test at frequent intervals. This leads to more consistent working software, problems are highlighted earlier.
This brings me to point that Agile, for some reason, is seen as more risky from business perspective. This is largely because more errors are uncovered more frequently – but that is what the SDLC is all about. Agile means issues are highlighted earlier, and business needs to change its ideas of risk, still rooted in Waterfall milestone releases.
This where QA can help, concerned as it is with the overall processes of delivering end product. This has led to phenomenon of Waterscrum, where a project works in a Scrum/Sprint fashion, but reports/delivers to Waterfall-style check points (milestones). How to deal with this …
The key points for the business and reports on progress and transparency, but that transparency does not need to be granular – do the business really want to understand the development and testing processes? Wouldn’t they be more interested in viewing progress, receiving reports, discussing possible impediments – engagement. And above all the business have to trust the team – the Product Owner, the Scrummaster, and to my mind the QA Manager should be giving business that confidence, by processes. If you dig too deep into the SDLC you will discover that failure is a common occurrence. Failure is only a problem when things aren’t learnt, and improvements aren’t made. This is normal – and was previously shielded in Waterfall process. “Do stuff – Make Mistakes – LEARN – Iterate”. Agile a constant review and improve process – for code, but also user stories/scenarios, and project processes. Never be afraid to change if something isn’t working. Business needs to remove blame culture – it prevents honesty, and can cause endemic problems.
This last year I have seen a lot more engagement from business world on subject of Agile. It will be a scrappy learning curve – transparency is very important to business. QA can help act as a barrier to development team, by engaging the business with the QA process. What is also useful is that business develop their own Agile framework, which defines the way projects are initiated and how reporting/updates are made. This frees up projects to adopts different Agile approaches, but unifies the communication lines to the business. Is Agile the future of business IT projects? It’s already here! We just need to bridge the gap, and remove the “smoke and mirrors” between what business think they are seeing, and what is actually happening.
Related posts:
