12308 מאמרים - מנוע לחיפוש מאמרים - פרסום מאמרים חינם

נושא המאמר: כללי ברזל מעשיים לביצוע בדיקות תוכנה - בדיקות תוכנה - מתודולוגיה - Testing - QA
מאת: איציק מאיר- TesTEAM   שמור מאמר למועדפים

כללי ברזל מעשיים לביצוע בדיקות תוכנה - בדיקות תוכנה - מתודולוגיה - Testing - QA

במאמר זה הדגיש מספר כללים בסיסיים שרכשתי בניסיוני על מגוון רחב של פרויקטי בדיקות תוכנה וחומרה. במאמר זה מאגד מספר כללים מוכחים ליישום בתהליך QA שוטף, קרא את כל הנקודות ונסה ליישמם במהלך פעילות השוטפת, קיום כללים אלו יובילו אותך לביצוע הבדיקות באופן יעיל ואיכותי. בהצלחה. - כיסוי הבדיקות כדי להבטיח מקסימום כיסוי, יש לחלק את המודול הנבדק [ UUT ] לתתי מודולים וכל תת מודול יחולק לפונקציות הבסיסיות ביותר. רצוי מאד לכתוב מפרט בדיקות [ Test Case] עבור כל תת מודול בנפרד. עבור כל דרישה כתוב את סוגי הבדיקות שברצונך לבצע, כך ניתן לוודא שהדרישה ניתנת לבדיקה [ testable ] ובעת הצורך ניתן לדרוש מאנשי הפיתוח להכניס תוספות לקוד לטובת הבדיקות. חשוב לבצע כיסוי מכסימאלי של הבדיקות. כיסוי של 100% אינו אפשרי ובכל זאת עשה מאמץ להגיע למקסימום הניתן לביצוע במגבלות הזמן והחומר. חשוב לתעדף את הבדיקות ע"פ מנגנון ניהול סיכונים [ Risk Analysis ]. - מעורבות ושיתוף מידע מעורבות אנשי הבדיקות בשלב מוקדם, משלב אפיון והגדרת דרישות המערכת, תקנה עבורך ידע והבנה מעמיקה של מכלולי המערכת, במידה ואין מעורבות שכזו על אנשי הבדיקות לבקש מהמנהל הרלוונטי לשתף אותם בתהליך. שמירה על הליך זה תביא לתכנון בדיקות איכותי ויעיל. שפר את הדו-שיח עם אנשי הפיתוח. קבל יותר מידע על המערכת, עליך לתעד את המידע ולהיעזר בו לתכנון הבדיקות. הבנה של התמונה הכוללת תמנע אי הבנה ותחסוך זמן יקר בהמשך. חשוב מאד לחשוף את כל מסמכי הבדיקות שלך לאנשי הפיתוח, לא לחכות לחשיפת מפרטי הבדיקות בשלב שחרור הגרסה. חשוב לשתף את אנשי התוכנה בנושאים הנבדקים כך תוכל לחשוף יותר שגיאות ולקבל פידבקים ובכך תחסוך זמן יקר. - יוצאים לדרך תמיד חשוב חיובי. התחל לבדוק את המערכת בידיעה שאתה עומד לגלות בעיות ושגיאות מרובות, לעולם אסור לחשוב שאין סיכוי לגלות טעויות ובאגים [ BUG ] במערכת הנבדקת חשוב! הנחת יסוד שתמיד קיימות שגיאות שעדיין לא נחשפו, תוביל את אותך לגילוי שגיאות נוספות בכל סבב בדיקות. - תכנון תסריטי הבדיקות ( STD ) להלן מספר דגשים לבדיקה, שעליך לקחת בחשבון בהגיעך לבדיקות עבור כל אובייקט: Functional testing ,Security Testing, Gui Testing חשוב מאד לבדוק כל שדה קלט (Input ) ע"פ Negative, ו- Validation בכדי להרחיב את כיסוי הבדיקות על האובייקט הנבדק. בזמן כתיבת תסריטי הבדיקות ( STD ), תכנן את הבדיקה ע"פ תנאים נורמאליים בהתאם לדרישות. וכן בהמשך תכנן את הבדיקה ע"פ תנאים וערכים לא חוקיים ( Valid & Invalid) תהליך זה מכסה בדיקה של קבלת נתונים צפויים ובנוסף בדיקה של המערכת בטיפול הערכים לא צפויים. בדיקות ביצועים מהווים חלק קריטי עבור מרבית המערכות בבדיקות ידניות בד"כ מתעלמים מחלק זה עקב מחסור בבסיס נתונים גדול. ובכל זאת במידה ואין אפשרות לייצר בסיס נתונים גדול באופן ידני, ניתן לכתוב סקריפטים בסיסיים לבניית בסיס נתונים לבדיקת ביצועים, בקש עזרה מאנשי הפיתוח שיכתבו עבורך את הסקריפטים. הגדר מראש סט של מפרטי בדיקות עבור בדיקות ה-Sanity ועבור בדיקות ה- Regression בכך תוכל להעריך את משך הזמן הדרוש לכל סבב בתהליך הבדיקות. חשוב מאד תכנן ובדוק מעבר לדרישות המוגדרות, בדוק "מסביב", בתחומים בהם המערכת לא אמורה לתמוך. יצירתיות היא שם המשחק. - תהליך הרצת הבדיקות אנשי הפיתוח לא אמורים לבדוק את עצמם. בד"כ אנשי הפיתוח מבצעים בדיקת יחידה [Unit] בסיסית לפני שחרור המודול או המערכת לבודקים. עם זאת, לא נכון להאיץ במפתחים לשחרר את הגרסה לבדיקות לפני שהם מרגישים מוכנים, תן להם את הזמן, הם יודעים להעריך מתי הגרסה בשלה לשחרור וכן את זמן הבדיקות הנדרש לסבב הבדיקות. חשוב מאד! שמור את אנשי הפיתוח "הרחק" מסביבת הבדיקות. כלל זה נועד למנוע שינויי קונפיגורציות במערכת הנבדקת ע"י אנשי הפיתוח, פעולה זו תציף מייד שינויים שנכנסו לגרסה המשוחררת [[Release Version אשר לא תועדו במסמך שחרור הגרסה. חשוב מאד לקיים כלל זה, בעיקר בסביבות מרובות קונפיגורציות. מניסיוני, לא פעם קרה שגרסה שוחררה ללקוח עם קונפיגורציה שונה מסביבת הפיתוח והבדיקות. לכן ככלל: כיול המערכת תבוצע בכפוף למסמכי שחרור הגרסה [ Release Note ] במהלך הרצת הבדיקות ערוך רישום של פעולות שאתה מבצע מעבר להרצת מסמכי הבדיקות, כך תוכל לשחזר את רצף הפעולות אשר גרמו למציאת הטעויות [Bugs] עליך לרשום את כל הפרטים בדו"ח התקלות. בתהליך בדיקות ה-רגרסיה [ Regression ] , בדוק באופן אקראי באגים "סגורים" מגרסאות ישנות יותר, במטרה להציף בעיות תצורה. במקרים רבים בסביבת הבדיקות מבצעים שינויים ואו תוספות לקוד לטובת יכולת בדיקה משופרת יש לערוך תיעוד של כל השינויים שמתבצעים על המערכת לטובת הבדיקות, במטרה להסירם לפני מסירת המערכת ללקוח. - דוח התוצאות ואנליזה למד לנתח את תוצאות הבדיקות ביסודיות (STR) אל תתעלם מתוצאות הבדיקה, תוצאות סופיות של הבדיקות יהיו "עבר" [Pass] או "נכשל" [Fail], אבל, איתור שורש התקלות עבור תוצאות "הנכשל" [Fail] יוביל אותך לפיתרון הבעיה, חשוב מאד! מצופה מכל איש בדיקות לספק מידע ממוקד למקור הכישלון מעבר לרישום תוצאת הבדיקה. ורישום הודעת השגיאה. פירוט והבנת ה BUG יובילו לפיתרון מהיר יותר לבעיה. בדוק את עקומת גילוי הבאגים ביחס לגרסאות קודמות, כך תקבל אינדיקציה על בשלות הגרסה ביחס לגרסאות קודמות אודות הכותב: איציק מאיר מנכ"ל חברת TesTEAM חברת Testeam עוסקת ביישום פרויקטי בדיקות, בייעוץ בנושאי אבטחת איכות תוכנה, בבדיקות ממוכנות וידניות של מערכות מחשוב לסוגיהן והדרכות בתחום הבדיקות. לחברת Testeam ניסיון עשיר בהגדרה ופיתוח מערכי בדיקות עבור מערכות מידע, מערכות תקשורת, מערכות אינטרנט, מערכות משובצות מחשב, מערכות מולטי-דיסציפלינאריות ומערכות Mission Critical. חברת Testeam פועלת במודל ייחודי הכולל ליווי אישי של כל עובדי החברה ע"י מנהלי בדיקות מהבכירים במשק אשר נמנים על צוות הנהלת החברה. מודל ייחודי זה מביא לאחריות ומחויבות הנהלה לאיכות עבודה, מודל זה מבטיח את ביצוע הפרויקטים ברמה ובאיכות גבוהים במיוחד מחד, תוך קידומם המקצועי של עובדינו מאידך. איציק הוא מומחה בדיקות ומוביל מחלקות QA. בעל ניסיון עשיר של כ- 15 שנים, במגוון סביבות עבודה שונות ומגוונות. כמו גם ניסיון רב בהקמת מחלקות קבוצות ופרויקטים בתחום הבדיקות.