יש אין ספור מתודולוגיות ושיטות עבודה לתכנון וביצוע בדיקות, זיקקנו כאן את 5 הכללים שכל בודק תוכנה חייב ליישם כשהוא ניגש לבצע QA למערכות ולממשקים שלו:
כל בדיקה עומדת בפני עצמה!
חשוב שבודק התוכנה מתכנן את תסריט הבדיקה הוא מייצר לו התחלה ברורה, בדיקה וסיום לבדיקה כלומר Flow שלם של יחידת בדיקה על מנת שהתוצאה הצפויה והתרחיש בפועל ייתן ערך לתהליך.
סיווג יעיל של הבדיקה לתהליך
בפרויקט יש מספר מחזורי בדיקה, החל מ UT – בדיקות המסירה – בדיקות הקבלה או בדיקות רגרסיה. לכל יחידה כזו אנחנו יכולים לפתח סט שונה של תסריטים, כלי לבדיקה ושיטות עבודה. לדוג' אם אנחנו נמצאים בשלב של בדיקות UT, זה אומר שלרוב אין עדיין UI אין מסכים וויזואלים לבדיקה, ולכן שיטת הבדיקה תהיה כדרך פונקציות עם קריאת פרמטרים והחזרת תוצאה מהרוטינה, בהנחה ומדובר בדיקות מסירה – ייתכן ונרצה להתמקד בממשקים, אינטגרציה, והסבות עוד לפני יישום פונקציונאלי או END TO END של תהליך בעייני משתמש. בבדיקות רגרסיה ייתכן ונכון יהיה בכלל לשלב כלים אוטומטיים כגון QTP, הרי והבדיקות רגרסיה די קבועים ומרחבים עם הזמן.
ניהול תקלות ותקשורת מול הלקוחות ויחידת הפיתוח
ניהול תקלות נכון ויעיל הוא מקור הצלחת הפרויקט, ניהול ומעקב, תיעדוף נכון של התקלה, תקשורת ובקרה על צוותי הפיתוח, ותקשורת נכונה אל הלקוחות על מצב הפרויקט – מביא את בודק התוכנה להצלחה או כישלון פרויקטלי.
סביבות עבודה
זה נשמע טרוויאלי? סביבת QA אין בכלל סוגיה. אבל העולם האינטגרטיבי הוא הרבה יותר מורכב מסתם סביבה נמוכה. ייתכן ויש מספר צוותים האחראים על תהליך פיתוח, החל ממערכת X עד שכבת האינטגרציה ומעבר למערכת Y, אם שלושת רכיבי הפיתוח הנ"ל לא יהיו מותאים לאותה סביבת עבודה, אותו מס"ד נתונים או לפחות הסכמה על האוכלוסיה – איכות התקלות והאמינות יהיה ברמה מאוד נמוכה. אם אין אפשרות כזו – נדרש לפרק את הבדיקות ליחידות עצמאיות של בדיקה – ושלב האינטגרציה יהיה על רשומות מוסכמות של בדיקה.
בדיקות פונקציונאליות
אנחנו ב TESQA מאמינים ששלב זה הוא הקריטי ביותר בתהליך הבדיקות, ככל שנתמקד ונעמיק בשלב בדיקות הפונקציונאליות, הלוגיקה, חווית המשתמש כך הפרויקט יצלח!
מתעניין בבדיקות תוכנה? כנס עכשיו >>
TesQA 