- December 29, 2011
Agile, scrum, ...
#agile, #business, #cannot, ...
Waterfall vs Agile? Unnecessary. Waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment. Agile methodology is a sound choice for development. Agile management processes are still being devised – it was all very well accusing business of not being Agile, but they hadn’t been provided with any kind of Agile framework on which to base any changes on. In the early Agile days at least. Hence the inevitable pairing of the two methodologies on many projects; and still very common.
One of the off-putting factors for smaller companies implementing Agile is perceived cost and complexity. How much does is cost to implement a new process or guidelines? Well, nothing on the face of it – though there time for everyone to get up to speed, and maybe a few additional tools. Agile is a mixture of common sense and principles that have been in software engineering for decades.
One of the pieces of advice I have carried with me is from an Agile coach/menter with a lot of automated testing expertise.
If a project is near the beginning, use Fitnesse (primary objective is User Acceptance Tests) – if the project further along the line, use Selenium (primary objective is to test code).
Am I am getting tired of the same old attitude to testers, as I experienced when I first started in the industry. Long-term testers usually have many strings to their bow, but although it appears that the value of testing is recognised, there is much ignorance as to the extent of a testers responsiblity. A development team is only as good as the management behind it. Too little mamangement happens these day, so modern testing usually incorporates release management, reverse engineering requirement, defect management, test environment management – notice how I havent even used the word “testing” yet?
There is an old adage that many developers forget, the 40/20/40 software engineering rule (40% Analysis, 20% Development, 40% Testing). Unfortunately it is all too common for it to be 20/70/10. This has had the damaging effect of putting development above all else – but wait a minute, this isnt a college project, this is real life with an end client. In the course of testing, the first thing we latch onto are requirements, as they not only outline functionality at high-level, they indicate client expectations. If these do not exist, then they have to be created – if there are no agreed requirements, it will make the sign-off awkward, as everyone connected with a project will have varying ideas on what “complete” means.
The same madness that allows developers to be responsible for testing and signing off code, is the same madness that treats testing as a luxury extra. The common misconception is testing are waiting for development to give them something. For the formal release process, sure that true on release days, but testing doesnt have to stop, and doesnt – it is a daily activity – in my entire career on web projects as tester and test manager, I can honestly say that I never struggled to find useful work to do, related to testing.
The message is – stop treating testing as a task, it is a ROLE. And an important one if you want your precious code to see the light of day.