In most webapps ``features'' will be equivalent to ``pages''.
Just like we were triaging code to decide what code to test we need
to triage our features / pages based on which ones we predict will
get the most usage and which of those require the most work or time
on the back end.
If we stick with the same triage terms of minor, complex, critical,
and morgue in this context they would work out like this:
In the beginning ``predicted usage'' is all you'll have to go
on. But, once your site is live be sure to have hit counters that
track the usage of specific features. One page may result in one call
to feature A and four to feature B. Over time that may be a bigger
issue than you initially thought. Or maybe people just don't use the
site the way you thought they would. Don't guess when it's so easy
enough to track real usage.
- features are either really fast or not slow and
rarely used. Keep going.
- features are generally going to be edge cases.
If you've got the time, or suspect it may be a problem, write a load
- features are going to be hit constantly. Ones
that require a good amount of work on the back end too are even more
- features would be those things that are just going
to be slow no matter what you do (see section ).