אנשי QA אוהבים לסווג תקלות תוכנה לפי מידת החומרה של התקלה: יש תקלות ממש איומות שאי אפשר להשיק את המערכת עד שלא יתוקנו ולעומתן תקלות פחות נוראות שמשפיעות על פחות משתמשים או על Use Case ספציפי ואותן לא יקרה כלום אם נתקן במועד מאוחר יותר.

אבל כאנשי תוכנה יהיה לנו מועיל יותר לסווג תקלות לפי כמה קל להתאושש מהן: גם תקלה שמשביתה מערכת שלמה היא לא כזו נוראית אם התיקון הוא שינוי שורה וחצי בקוד. תקלה אחרת עשויה להשפיע על מעט מאוד משתמשים ואולי גם הם כמעט לא ירגישו בה אבל אם כדי לתקן אותה צריך לעשות שינוי גדול בבסיס הנתונים כולל לבצע Migration של נתונים ישנים אז עם התקלה השניה יהיה הרבה יותר קשה להתמודד.

אפשר להתחיל מהסולם הבא:

1. אני יכול לתקן את זה אבל זה ימחק לכל המשתמשים את כל המידע שלהם.

2. אני יכול לתקן את זה אבל משתמשים יצטרכו לבצע פעולה ידנית כדי להתקדם.

3. אני יכול לתקן את זה ולכתוב סקריפט אוטומטי שימיר לכולם את המידע לגירסא החדשה.

4. אני יכול לתקן את זה אבל זה ידרוש שינוי עצום במבנה המערכת ובניה מחדש של חלקים גדולים בקוד.

5. אני יכול לתקן את זה אבל זה ידרוש Down time של שרת הייצור לכמה שעות.

6. אני יכול לתקן את זה בלי לאבד מידע, תוך שינוי ממוקד רק של הקוד הבעייתי.

7. אני יכול לתקן את זה ויש לי בדיקות אוטומטיות לוודא שהתיקון לא שובר התנהגות ישנה.

ומפה לגזור מתודולוגיית עבודה וגישה לכתיבת קוד שתגרום לכך שכמה שיותר תקלות יהיו בחצי הקל של הסולם.