Software Development Cross Solution - Index of - Free

Q: How many people should be
involved in a spike test?
A: Ideally you’d get everyone that you
think will be involved in the actual bug fixing
involved in the spike test. This means that
you not only get a more accurate estimate,
because the actual people who will finish off
the bug fixing will be involved in the future
estimated fixing task, but those individuals
also have a week to get familiar with the
code.
This especially helps when you ask those
members of your team to assess their
confidence in the estimate that comes out
of your spike test. They’ll have seen the
code base and have a feel for how big all
the problems might have been, so their gut
feeling is worth that much more.
Q: How do I pick the right tests to
be part of the spike testing when I have
thousands of tests failing?!
A: Try to pick a random sampling, but
with an eye towards getting a selection of
bugs that vary in difficulty. So what you’re
looking for first is a random sample, but
then you want to make sure that you have
a cross-section of bugs that, at a glance, at
least appear to be challenging and not just
the easiest things to fix.
Q: I thought in test-driven
development, we fixed each test as we
came across it. Are we not using TDD
anymore?
A: This is still TDD, for sure. But this is
about existing code, not writing tests for
new code. You don’t want to stop and try to
fix each test just yet. We need a big picture
view of the code right now.
However, this does cause a problem if you’re
using CI, and your build fails when a test
fails. In that case, after you get a count of
failing tests it might make sense to cheat a
little and comment out the failing tests. Then
add them back in one at a time. This is risky,
and might get you on the TDD Most Wanted
list in no time flat, but practically speaking
you might want to consider it. The most
important thing is you get all of those tests
passing, and nothing’s left commented out.
Q: Why did we add in that confidence
factor again?
A: Factoring in confidence gives you
that qualitative input into your estimates
where your team gets a chance to say
how difficult they feel the rest of the bugs
may be to fix. You can take this pretty far,
by playing planning poker with your bugs,
but remember that the longer you spend
assessing confidence, the less time you
have to actually fix the bugs.
It’s always a compromise between getting
an absolute estimate for how long it will
take to fix the bugs (and this can really only
be obtained by actually fixing them all) and
getting a good enough feel for how fast you
can squash bugs and getting that estimate to
your customer.
Q: Why five days for a spike test?
A: Good question. Five days is a good
length because it focuses your team on
just the spike test for a week (rather than
attempting to multitask during that week),
and it gives everyone enough time to do
some serious bug fixing.
Q: Can I use a shorter length?
Download at WoweBook.Com
bugs
A: You can, but this will affect how many
bugs your team can work through, and that
affects your confidence in your final estimate.
In the worst case scenario, no bugs at all
are fixed in your spike test, and you’re left
confused and without a real end in sight.
Five days is enough time for some serious
bugs to be fixed and for you to be able
to come out of the spike test with some
confidence in your estimate for fixing the
remainder of the bugs. And in the best case
scenario, you come out of the spike test
week with no bugs at all!
Q: So should I do this on code we’ve
developed, too?
A: You really shouldn’t need to. First of all,
you shouldn’t have a massive stack of failing
tests. If a test is failing, the build should be
failing, and you should fix things immediately.
And with bugs, they should be prioritized in
with your other work, so it’s unlikely you’ll
suddenly get a giant stack of bugs you need
to sort through. And finally, you and your
team should know your code base pretty
well. Your coverage reports provide value,
and you know there can’t be too much code
involved in any given bug.
Q: How can I be absolutely sure that,
even when I’ve factored in my team’s
confidence, that 10 days is definitely
enough to fix all these bugs?
A: You can’t. Ten days is still just an
estimate, and so it’s how long you think it
will take, based on your spike test and your
team’s gut feelings. You’ve done everything
you can to be confident in your estimate, but
it is still just an estimate. When it comes to
bugs, you need to be aware that there is a
risk that your estimates will be wrong, and
that’s a message that you need to convey to
your customer too...
you are here 4 405