אורך חיים של תהליך בדיקות
בפוסט זה אני רוצה להעלות נושא קרוב לליבי; "מעגל חיים של באג" או יותר נכון "מעגל החיים של תהליך בדיקות".
למרבה הפלא ישנן חברות שעדיין אינן מטמיעות בתהליך הפיתוח הליך בדיקות אלא מבצעות אותו בהרצה מהירה וכוללנית לפני כל עליה או שחרור גרסא (יותר דומה לSanity או חיפוץ של Acceptance Testing). יחד עם זאת, מרבית החברות בארץ מבינות שהליך פיתוח מסודר משולב הליך בדיקות עם איפיון מוגדר מראש חוסך לחברה כסף רב וזמן עבודה.
בתוך כל זה ישנם פרוייקטים מבוססים מודל Agile הנפוצה יותר בשוק לדעתי בגלל התחרות אך גם בפרויקט זה יטעה מי שיחשוב שאין פה סדר בעבודה.
בכל פרוייקט ישנן נקודות תהליכיות בולטות:
לרב תהליך הבדיקות דורש את הזמן הרב ביותר אם נוסיף לתוכו את שלבי מעגלי תיקון הבאגים והאינטרקציה מול הפיתוח. אך כמעט ולא תראו פרוייקט שהזמן שהוקצב לבדיקות עולה על חצי מזמן הפיתוח. לכן, עלינו כבודקים לסגל לעצמנו אסטרגיית בדיקות כמו למשל למצוא את המטריצה הטובה ביותר לכסות את המקרים בעלי הסיכון הגבוה בתחילת תהליך הבדיקות.
טעות נוספת הקיימת בפרוייקטים הינה שצוות הQA אינו שותף לתהליך כבר מהליך הדרישות והאיפיון. שילוב צוות הבדיקות כבר בשלב מוקדם זה יכול למנוע אף כשלים בתכנון או בהצגת דרישות שאינן עומדות בקריריונים מסויימים של משתמש או של המבנה כולו.
בפרייקטים גדולים יותר העובדים בגישת/מודל Waterfall התהליך יהיה בנוי מסודר יותר ומורכב יותר וכן, מדורג יותר:
אורך החיים של באג בתוך המערכת הזו תהיה ספציפים לאות באג במערכת:
הכנה לבדיקות:
כתיבת STD מביאה לייעול, סדר וביצועים גבוהים של צוות הבדיקות אך אם אנחנו בפרוייקטמודל Agile חשוב לא פחות לנהל רשימה מסודרת של אסטרגית בדיקות (Check list) אי ניהול והתחלת עבודה בצורה חופשית ללא ניסיון לרב לגרור בזבוז זמן יקר ואופן בדיקה לא יעיל.
במסמך הבדיקות או בתהליך התכנון נכלול את הדברים הבאים:
נכון, היה קצת קצר ותמציתי אבל אם יש לכם שאלות אל תחששו לשאול,
דור
למרבה הפלא ישנן חברות שעדיין אינן מטמיעות בתהליך הפיתוח הליך בדיקות אלא מבצעות אותו בהרצה מהירה וכוללנית לפני כל עליה או שחרור גרסא (יותר דומה לSanity או חיפוץ של Acceptance Testing). יחד עם זאת, מרבית החברות בארץ מבינות שהליך פיתוח מסודר משולב הליך בדיקות עם איפיון מוגדר מראש חוסך לחברה כסף רב וזמן עבודה.
בתוך כל זה ישנם פרוייקטים מבוססים מודל Agile הנפוצה יותר בשוק לדעתי בגלל התחרות אך גם בפרויקט זה יטעה מי שיחשוב שאין פה סדר בעבודה.
בכל פרוייקט ישנן נקודות תהליכיות בולטות:
- (מחקר כשלב מקדים).
- הגדרת דרישות מערכת.
- איפיון המערכת.
- הטמעה ופיתוח.
- בדיקות.
- חזרה לפיתוח תיקונים.
- בדיקות.
- השקה/הטמעה.
- תחזוקה שוטפת.
לרב תהליך הבדיקות דורש את הזמן הרב ביותר אם נוסיף לתוכו את שלבי מעגלי תיקון הבאגים והאינטרקציה מול הפיתוח. אך כמעט ולא תראו פרוייקט שהזמן שהוקצב לבדיקות עולה על חצי מזמן הפיתוח. לכן, עלינו כבודקים לסגל לעצמנו אסטרגיית בדיקות כמו למשל למצוא את המטריצה הטובה ביותר לכסות את המקרים בעלי הסיכון הגבוה בתחילת תהליך הבדיקות.
טעות נוספת הקיימת בפרוייקטים הינה שצוות הQA אינו שותף לתהליך כבר מהליך הדרישות והאיפיון. שילוב צוות הבדיקות כבר בשלב מוקדם זה יכול למנוע אף כשלים בתכנון או בהצגת דרישות שאינן עומדות בקריריונים מסויימים של משתמש או של המבנה כולו.
בפרייקטים גדולים יותר העובדים בגישת/מודל Waterfall התהליך יהיה בנוי מסודר יותר ומורכב יותר וכן, מדורג יותר:
- הצגת דרישות מערכת.
- תכנון בדיקות והכנת תוכנית בדיקה.
- מעבר על מסמכי האיפיון כחלק מבדיקת האיכות.
- הכנת STD תסריטי בדיקות.
- הרצת תסריטי בדיקה.
- הפקת דוח בדיקות ובאגים.
- עבודה מחודשת על תיקונים.
- אישור והשקה.
אורך החיים של באג בתוך המערכת הזו תהיה ספציפים לאות באג במערכת:
- פתיחת הבאג לאחר חשיפתו
- תיקון הבאג על ידי הפיתוח והחזרתו לבדיקות.
- בדיקת התיקון ממוקד וסגירת הבא או פתיחתו מחדש.
- הרצת בדיקות אזוריות לאותו תיקון.
הכנה לבדיקות:
כתיבת STD מביאה לייעול, סדר וביצועים גבוהים של צוות הבדיקות אך אם אנחנו בפרוייקטמודל Agile חשוב לא פחות לנהל רשימה מסודרת של אסטרגית בדיקות (Check list) אי ניהול והתחלת עבודה בצורה חופשית ללא ניסיון לרב לגרור בזבוז זמן יקר ואופן בדיקה לא יעיל.
במסמך הבדיקות או בתהליך התכנון נכלול את הדברים הבאים:
- חלוקת המערכת לפיצ'רים ומודולים - הבנת מבנה המערכת.
- בניית אסטרגיית בדיקה.
- הערכת זמני עבודה.
- כלי בדיקה והכנת תשתית עבודה.
- הכנת מסמך בדיקות.
נכון, היה קצת קצר ותמציתי אבל אם יש לכם שאלות אל תחששו לשאול,
דור
תגובות