Category Whitepapers and Guides
[vc_row][vc_column width=”1/1″][vc_column_text]Back in the day there was plenty of opportunity for a blame culture to exist in software development projects. Traditional methodologies encouraged rigid process, something along the lines of: develop, build and then finally, test. Inevitably, when following this process, milestones (in the lengthy project plan) were rarely met, meaning ‘slippage’ occurred at various stages, and activities, planned for the later phases of the project, were squeezed for time. This usually meant ‘testing’, so one of two outcomes would occur. Either the testers would have insufficient time to do a comprehensive job, or the go-live date would be delayed.
Typically this created an “us and them” culture between developers and testers, with each blaming problems on the other. In most cases, if bugs were found in production, the first question asked: ‘Was the testing effort sufficient?’. Crazy, we know, and crazier still is that these ‘traditional’ methods are still favoured by a large number of organisations!
The agile development ecosystem sees developers, testers and the wider business work alongside one another as a single team, with common goals. Furthermore, the democratic approach of agile working sees the team come together to determine the acceptance criteria between them. This means everyone settles on achievable goals and timescales before the work begins. In short, developers know what to develop and testers are aware of what’s awaiting them. The benefit here is typically a vast reduction in defects.
To enshrine this acceptance criteria, the whole thing is written using common domain language and driven by user behaviours, so easily understood by all. Each development ‘task’ is only signed off as ‘done’ when the tester issues a pass.
And when test automation enters the agile process, a great many more tests can be executed. A fully automated regression test pack checks that nothing is broken in the new build, resulting in a much lower risk of new releases hitting the market with bugs present.
All of the above may sound like something of a utopia to those still using traditional development methods; as realistically achievable as walking to the moon. By following the below guide, however, the concept of ‘Team Heaven’ could indeed become a reality.
As noted at the beginning, it’s safe to say that finding bugs in production was never a tester’s fault, even though traditional working setups allowed such beliefs to seep through. This was even the case when efforts were restricted, so any issues or concerns hadn’t been given the optimal time or consideration.
Now, in an agile environment, labeling bugs in production as being the fault of testers simply isn’t possible. First and foremost, agile working should result in much fewer bugs being found on production. In the case of such concerns or complaints, though, collaborative working means the whole team shares responsibility. This does mean, of course, that in the case of projects being a resounding success, the entire team can also share the plaudits.
Team Heaven indeed. If you’re transitioning to an agile methodology or have achieved team heaven, we’d love to hear your story![/vc_column_text][/vc_column][/vc_row]