6.1 Triage based on predicted usage.

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:

``minor''

features are either really fast or not slow and rarely used. Keep going.

``complex''

features are generally going to be edge cases. If you've got the time, or suspect it may be a problem, write a load test.

``critical''

features are going to be hit constantly. Ones that require a good amount of work on the back end too are even more critical.

``morgue''

features would be those things that are just going to be slow no matter what you do (see section ).

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.