StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Jeremy provided a very solid answer, but let me try to augment it by putting the topic in the context of your migration from waterfall to agile. We have been successfully been using agile for two years now, though not without significant growing pains.</p> <p>A key success factor in Scrum agile is to maximize the amount of work NOT done. ANY sort of manual testing (unit, functional, load, scalability, negative) is engineering capacity underutilized. It's actually much worse than that since with every incremental new feature, the amount of manual testing required to maintain a certain level of quality increases non-linearly (geometrically?) with the number of features due to expansion of the test matrix caused by feature interaction. This is why at my company we call manual testing 'technical debt'.</p> <p>In Scrum, testing cycles will accelerate since every user story should meet an agreed upon Definition of Done before being accepted by the Product Owner. In any given sprint, many user stories should be done by every Scrum team. If each story requires manual testing, which it should per the DoD and lack of automation, much time is wasted.</p> <p>A reasonable testing strategy will look at, among other things, where code is changing, so as not to tackle low risk, static areas. With Scrum, code refactoring is encouraged because each story is a very thin slice of functionality, and customer feedback is immediately incorporated in the backlog in the form of new/modified user stories. Thus, good Scrum programs will have their 'code freeze' much closer to their 'release date' than waterfall programs. This makes it difficult to test once and be done with it. You end up paying the technical debt interest many times over.</p> <p>Jeremy's last thought pertains to how you could sell your ideas or effecting change. I find this to be very important so allow me to add a few thoughts of my own. If your management is serious about Agile, they will take Scrum teams feedback seriously. During retrospective, you could ask your teammates how they feel about modifying code that has no unit test coverage. That should elicit some feedback. </p> <p>Another way, is to look for evidence of obstacles in your program artifacts. An obstacle being defined as anything that slows teams down. Do you have a bug tracking system where 'regression' defects are identified? Does your team track how often a given test case is run? Is there any component of your software that might have decent unit test coverage? If so, do teams working on it run into fewer issues than other teams? Management cares about dollars/pounds/euros. Figure out how much time is wasted by how many people due to lack of automated unit testing and convert into money. Managers can tell you what the fully loaded cost of one of your engineers is. And remind them that this waste is perpetual, until the technical debt is faced that is.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload