|
|
|
מהו QA, מתי צריך QA ומהם הבאגים העלולים להתעורר כאשר אין QA ?
|
|
המאמר Software QA and Testing Resource Center של ריק האור, יועץ תוכנה ואבטחת איכות המספק שירות לחברות הגדולות בעולם, ויוצרו של אתר אינטרנט בתחום אבטחת תוכנה, תורגם ועובד על ידי אורית גליקמן, ראש צוות QA בחברת Netwise
|
|
|
תקציר המאמר:
המאמר עוסק בהסברים על עבודת ה- QA, אילו בדיקות הם עורכים, מתי עלולות להיווצר בעיות ומהם הפתרונות האפשריים. המאמר קובע כי לא כל פרויקט תוכנה מצריך התערבות של צוות QA ויש לבחון זאת לפי גודל הפרויקט ורמת הסיכון.
|
|
|
|
מהן הסיבות לכישלונם של פרויקטים בתחום התוכנה, מהי בקרת/אבטחת איכות, האם כל פרויקט פיתוח מצריך צוות QA ובדיקות תוכנה ומה עלול לקרות למערכות כתוצאה מתקלות?
|
|
|
|
מהי בקרת איכות תוכנה?
|
|
|
|
בקרת איכות (QA) היא בקרה על איכותו של קוד שכותבים מפתחי תוכנה. מדובר הן בבקרה ויזואליות והן בבקרה פונקציונאליות. תהליך ה- QA מלווה את כל תהליך פיתוח התוכנה, החל מניטור ושיפור התהליך, ועד לעבודה לפי מוסכמות וטיפול בבעיות.
|
|
|
|
מהי בדיקת תוכנה?
|
|
|
|
בדיקת תוכנה כוללת הפעלה של מערכת או יישום תחת תנאים מבוקרים והערכת התוצאות של בדיקות אלה. הבדיקות צריכות להיעשות גם תחת תנאים תקינים וגם תחת תנאים חריגים. הבודק יצטרך, בכוונה תחילה, לעשות דברים שגויים ולוודא כי הפעולות קורות כאשר הן צריכות לקרות, או לחילופין, אינן קורות כאשר הן לא צריכות לקרות.
הקצאת האחריות ל-QA משתנה מארגון לארגון בהסתמך על גודל הארגון והמבנה העסקי שלו. לפעמים האחריות היא של קבוצה או אדם, בפעמים אחרות אנשי QA עובדים בצמוד לאנשי הפיתוח, תחת מנהלי פרויקטים.
|
|
|
|
דוגמא לכישלונות במערכת
|
|
|
|
באג בתוכנת ניהול של אתרי תוכנה, המיועדת לחברות עם מחלקותIT (מחלקת מידע) גדולות, גרם לבעיות ביצועים משמעותיות ברוב אתרי הלקוחות ולהקפאת פעילות התוכנה באתרי הלקוח עד לתיקון התקלה.
לפי דוח שפורסם באפריל 2004, באג תוכנה היה אחד הגורמים הראשיים אשר תרמו להפסקת חשמל בצפון מזרח ארצות הברית ב-2003 - הפסקת החשמל החמורה ביותר של צפון אמריקה. הפסקת החשמל השפיעה על כ- 50 מיליון לקוחות וגרמה להפסקת פעילותן של 100 תחנות כוח. ההפסד הכלכלי הוערך בכ- 6 מיליארד דולר. התקלה נגרמה כתוצאה מחוסר יכולת של התוכנה לטפל בצירוף חריג של פעולות רגילות.
|
|
|
|
לא כל פרויקט תוכנה מצריך QA
|
|
|
|
למרות שכל פרויקט ירוויח מבדיקה מקיפה, יש פרויקטים שלא דורשים קבוצת QA עצמאית. איך נדע מתי פרויקט חייב צוותQA ומתי ניתן לוותר עליו? התשובה תלויה בגודל הפרויקט, סוג הפרויקט, סיכונים הקשורים אליו, מתודולוגיות הפיתוח, מיומנות וניסיון המפתחים וגורמים נוספים. כך למשל, פרויקט קטן, בעל סיכון נמוך, המבוצע על-ידי קבוצת מתכנתים מנוסה שמבצעת Unit Test מסודר, לא מצריך צוות QA על מנת להבטיח את הצלחת הפרויקט.
|
|
|
|
ארגונים קטנים או חדשים, שאינם יכולים להרשות לעצמם צוות QA, צריכים לשקול שימוש בקבלני משנה או outsourcing. ויתור על בדיקת התוכנה אסור שתיעשה משיקולי חיסכון, מכיוון שזהו סיכון גבוה מדי.
|
|
|
|
עבור פרויקטים מסובכים או בעלי סיכון גבוה, צוות QA הוא הכרחי בדרך כלל. כבכול דבר אחר, השימוש באנשי מקצוע, בעלי התמחות ומיומנות, מגדילה את יכולתו של הארגון לבצע את המשימות בהצלחה. יש לזכור שצורת החשיבה של מתכנת ושל מהנדס QA הן שונות. למשל, חשיבה טיפוסית של מתכנת היא 'איך לגרום לפעולה לעבוד?' לעומת מהנדס QA טיפוסי שישאל 'מה יכול להשתבש, וכיצד יש לוודא על מנת שהציפיות ימולאו?'.
|
|
|
|
למה יש באגים בתוכנה?
|
|
|
|
באגים בתוכנה עלולים לקרות על רקע של חוסר תקשורת או תקשורת לקויה לגבי הדרישות של היישום. לדוגמא:
|
|
|
|
|
תוכנות מורכבות הגוררות חוסר הבנה: תוכנות מורכבות עלולות להיות קשות להבנה לכל מתכנת, במיוחד למתכנתים חסרי ניסיון. יישומים רב-שכבתיים, יישומי שרת-לקוח, תקשורת נתונים, מסדי נתונים ענקים וגודל היישומים, תורמים למורכבות התוכנות.
|
|
|
טעויות אנוש: מתכנתים, כמו כולם, יכולים לעשות טעויות.
|
|
|
שינוי דרישות של משתמש הקצה (מתועד ולא מתועד): משתמש הקצה עלול שלא להבין את האפקטים של השינויים שהוא דורש. לעיתים, גם כאשר הוא מבין את הסיכונים, הוא עשוי לבקש את ביצוע השינויים למרות זאת.
|
|
|
לוחות זמנים קצרים היוצרים לחץ: תזמון פרויקטים הוא קשה עד בלתי אפשרי. כאשר הזמן דוחק לקראת סוף הפרויקט והלחץ עולה, עולה הסבירות לעשיית טעויות.
|
|
|
אגו שלא מאפשר לסרב או לבקש עזרה: קורה שאנשים מעדיפים להגיד אין בעיה' במקום להעריך את היקף העבודה הדרושה.
|
|
|
תיעוד גרוע של הקוד: קשה לתחזק ולשנות קוד שנכתב בצורה לא מובנת ו/או לא תועד. תחזוקה או שינוי של קוד כזה גורמים לבאגים רבים. בהרבה ארגונים מתכנתים מתוגמלים על סמך זמני פיתוח קצרים. אין תגמולים על קוד אינטואיטיבי, ברור ומתועד.
|
|
|
כלי פיתוח: באגים של עורכים, ספריות, קומפיילרים וכו', בין אם הם מתועדים או לא מתועדים, גוררים אחריהם באגים נוספים.
|
|
|
|
|
איזה סוגי בדיקות נדרשות לתקינות התוכנה?
|
|
|
|
|
Black Box ו- White Box: בדיקות שאינן מבוססות על הכרת המערכת ובדיקות המבוססות על הכרת המערכת.
|
|
|
Unit Test: בדיקות המתכנתים על הקוד אותו כתבו.
|
|
|
בדיקת אינטגרציה: בה מוודאים שכל רכיבי המערכת עובדות נכון כאשר הן מצורפות ביחד ליישום כולל אחד.
|
|
|
בדיקות רגרסיה: בהן נבדקים תכונות קודמות של המערכת.
|
|
|
בדיקות ביצועים ועומס: מערכת איטית מידי היא מערכת שלא עובדת מבחינת הלקוח.
|
|
|
בדיקות יציבות: נועדו לבדוק את יציבות המערכת, כמו גם את יכולת השיקום של מערכת שנפגעה (בגלל בעיות תוכנה או בעיות אחרות).
|
|
|
בדיקות אבטחה: אבטחת המידע חשובה ביותר לכל ארגון. ארגון לא יסכים להשתמש בתוכנה לא מאובטחת.
|
|
|
Beta, Alpha, Accaptance: בדיקות התוכנה באתר הלקוח תחת תנאים אמיתיים.
|
|
|
|
|
חמש הבעיות העיקריות בפיתוח תוכנה
|
|
|
|
|
דרישות לא מספקות: דרישות לא ברורות, לא מלאות או כלליות מדי, גורמות לבעיות.
|
|
|
לוחות זמנים לא ריאליים: לוחות זמנים קצרים גורמים לטעויות אנוש ולוויתורים.
|
|
|
בדיקות לא מספקות: אף אחד לא יודע אם התוכנה עובדת כנדרש או לא, עד שהלקוח מתלונן או עד שהמערכות נופלות.
|
|
|
הוספת פונקציונאליות: בקשות להוסיף תכונות חדשות לאחר שהפיתוח התחיל פוגעות באופן חמור בביצוע הפרויקט.
|
|
|
חוסר תקשורת: פעמים רבות קורה שהמפתחים לא מבינים את צרכי הלקוח.
|
|
|
|
|
חמשת הפתרונות המשותפים למנוע בעיות תוכנה
|
|
|
|
|
דרישות ברורות ומוצקות: שלמות, פירוט, עקביות, ריאליות, דרישות QA המוסכמות על כל הצדדים.
|
|
|
לוחות זמנים מציאותיים: נותנים זמן נאות עבור התכנון, הכתיבה, הבדיקה, תיקוני באגים, בדיקות חוזרות, שינויים ותיעוד.
|
|
|
בדיקות מוקדמות: Unit Test ופיתוח בדיקות מובנות בתוכנה. בדיקות ובדיקות חוזרות על-ידי ה-QA.
|
|
|
היצמדות לדרישות ההתחלתיות ככל האפשר: לא לעשות שינויים בדרישות לאחר שהפיתוח התחיל. יש להסביר ללקוח את משמעות השינויים ועלותם (זמן וכסף).
|
|
|
תקשורת: יש לוודא הלוך וחזור עם הלקוח והמפתחים כי הפיתוח מתקדם לכיוון הנדרש. יש להשתמש בכלי ניהול קוד וכלי ניהול באגים.
|
|
|
|
