5 נושאים שבודק תוכנה חייב ללמוד וליישם

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

יסודות חזקים ומתודולוגיה נכונה

כל בודק תוכנה חייב להכיר היטב את עולם המונחים של תהליכי פיתוח תוכנה בכלל ובבדיקות תוכנה בפרט. זאת על מנת לתקשר נכון על כלל הצוותים העובדים במחזור חיי פיתוח תוכנה, להכיר את עולם המוסגים מבלי להישאר מאחור ולפתוח פער ידע בשיחה, לבנות את תכנון הבדיקה בצורה נכונה ליישם, להבין את הטרמינולוגיה, רמות בדיקה, סביבות עבודה, ממשקים, הסבות, גישות של בדיקה, טכניקות לבדיקה, כלי בדיקות, כלים לתכנון בדיקות, כלי אוטומציה, תכנון מפרטי בדיקה, פסיכולוגיה של בדיקות מול צוותי הפיתוח והאינטגרציה, ניהול בדיקות, יצירת STP, STD, STR וכדומה… בודק תוכנה שעובד בתחום או שמתכנון להיכנס לתחום, מאוד מומלץ לא לדלג על השלב הזה ואם נדרש להדביק פערים לקחת קורס קצר. יסודות בבדיקות התוכנה >>

ניהול תקלות, איתור, שיקוף ופתרון

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

מתודולוגיות לפיתוח ובדיקות

יש מספר רק של שיטות עבודה לפיתוח בכלל ובדיקות תוכנה בפרט, המוכרות ביותר הינן שיטת מפל המים (וואטר פול) ואג'יל או סקראם. לכל אחת מהשיטות יש את הייתרונות והחסרונות שלה.

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

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

מסמכי הבדיקות

אחד מארגזי הכלים החשובים ביותר של בודקי התוכנה, הינן מסמכי הבדיקות. השכיחים ביותר הינן STP, STD,SRT

מסמך ה STP- Software Test Plan הינו מסמך תכנון הבדיקות כחלק מהפרויקט, בין היתר יתאר את אבני הדרך המרכזיים בפרויקט, המשאבים, לוחות הזמנים, תקציב, דרישות סף, תהליכים פונקציונאליים מרכזים אותם יש להרחיב במסמך ה STD

מסמך ה STD – Software Test Description – הינו מסמך מפורט של תכנון הבדיקות, המתאר שלב אחרי שלב את אופן ביצוע הבדיקות על פי יחידות עבודה שעל פי האיפיון או מסמך ה STD.

מסמך ה STR Software Test Report – מסמך תוצאות הבדיקות', והוא יישלח על ידי ראש צוות ה QA להנהלת הפרויקט, להרחבה

יציאה מהקופסא, ושאילת שאילות

בודק מן השורה יבצע את תרחישי הבדיקה שלו כפי שמצופה ממנו באיפיון או במפרטי הבדיקה, בודק מעולה ייצא מהקופסא, ישאל שאלות ויתעמת על התהליך הפונקציונאלי במידה והוא לא נכון בעיניו.

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

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

מעוניין ללמוד יותר על עולם הבדיקות? כנס עכשיו >>