
הטקסט המלא של הדקות הראשונות בהרצאה «פרק 5 - ניהול בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, הגענו לפרק 5, ניהול הבדיקות. חומר ההסמכה הרשמי של ה-STQB. אלו המושגים שנעבור עליהם במהלך הפרק, זה פרק חשוב במיוחד, והרבה מהנושאים שאנחנו נעבור עליהם יופיעו בבחינה.
נתחיל בסעיף 5.1, 5.11 בדיקות עצמאיות. משימות צוות הבדיקות או משימות אבטחת איכות עשויות להיעשות על ידי אנשים בתפקידים ותפקידי בדיקות ייעודיים, בדיקות אנשי QA אבל גם על ידי אנשים בתפקידים אחרים לדוגמא לקוחות או לדוגמא מפתחים עצמם שפיתחו את הקוד יכולים לעשות גם חלק ממשימות העתיקות חלק מהתהליך של
אבטחת איכות של התוכנה לעיתים רמה מסוימת של עצמאות תעשה את הבודק יעיל יותר במציאת פגמים בשל הבדל בהטיה הקוגניטיבית בין מחבר והבודק בחלק הזה מנסים להגיד לנו ככה אם הבודק הוא גם זה הבן אדם שפיתח את התוכנה יש פה איזושהי הטיה קוגניטיבית זאת אומרת
כשאנחנו צריכים לבדוק משהו שאנחנו עשינו הפעולה היא קשה יותר. יש איזה ניגוד עניינים בסיסי מובנה בתהליך. אולם עצמאות אינה תחליף להיכרות עם המערכת והמפתחים יש להם יתרון בכך שהם כתבו את הכל ולכן הם מכירים את המערכת טוב יותר מכולם.
המפתחים יכולים להיות יעילים במציאת פגמים בקוד שלהם עצמם. שוב, מבחינת החומר והתיאוריה של ה-STQB זה שמפתחים כן ייקחו חלק בתהליך הבדיקות ופירמידת הבדיקות שלמדנו.
אם אנחנו חוזרים למושג פירמידת הבדיקות, אז אנחנו זוכרים שהחלק הרחב, זאת אומרת כמות הכי גדולה של טסטים, נמצאים בשלב הראשוני, ה-Unitest. וה-Unitest הוא מקום מצוין כדי לערב את אנשי הפיתוח, המפתחים, אפילו אותו מפתח שכתב את הקוד על מנת לוודא שהוא מריץ בדיקות על כל קומפוננטה וכל רכיב ורכיב שהוא כתב.
אחר כך יגיעו בדיקות, מה שנקרא Service Tests API, שאנחנו יכולים לשלב עוד אנשים ואפילו להנגיש את זה לצוות הבדיקות, שיריצו בדיקות מול ה-API, זאת אומרת בדיקה של שליחת שאילתא, שליחת בקשה, request, לאותו סרוויס שפותח ולבדוק את התוצאות.
החלק האחרון בעצם השפיץ של פירמידת הבדיקות הם בדיקות הגוי, בדיקות האנד-יוזר הקלאסיות שאותן יבצעו בדרך כלל אנשי הבדיקות. בהמשך אנחנו נוגעים במושג שנקרא עצמאות הבדיקות.
עצמאות הבדיקות תוגדר לפי הרמות הבאות. אין בודקים עצמאים. זאת אומרת, הרבה פעמים בסטארט-אפים, בחברות הזנק, בחברות קטנות, את תהליך הבדיקות מבצעים המפתחים עצמם שבודקים את הקוד של עצמם, מנהלי הפיתוח או מנהלי המוצר, כן?
זה נקרא שאין בודקים עצמאיים באותו ארגון. השלב הבא הוא מפתחים עצמאיים או בודקים עצמאיים בתוך צוות הבדיקות או צוות הפרויקט, ייתכן ויהיו אלה מפתחים שבודקים את התוצרים של המיתאם. זאת אומרת, פה כבר מוגדר תפקיד ספציפי שהיעדים שלו הם בדיקות מעבר ליעדי הפיתוח.
בחלק הראשון אין יעדי בדיקות מובהקים רגילים אלא רק כדי פיתוח שאמורים לכלול גם בדיקה עצמית. פה כבר יש אנשים שאמורים לבדוק, אבל לא בהכרח הם אנשי QA פורמליים, אלא יכול להיות שהם מפתחים שבודקים פיתוחים של אנשים אחרים בצוות הפיתוח.
הקטגוריה השלישית זה צוות בדיקות או קבוצת בדיקות עצמאיים בתוך הארגון, קבוצה מוצהרת שנקראת צוות בדיקות, שמדווחת להנהלת הפרויקט או להנהלה הבכירה את התוצאות שלה.
זה כבר רמת עצמאות הרבה יותר גבוהה, כן? ככל שאנחנו הולכים בתהליך עצמו, אז אנחנו מבחינתנו מגבירים את העצמאות. העצמאות היא גוברת ככל שאנחנו מתקדמים. צוות הבדיקות עצמאי בתוך הארגון הוא מקהילת משתמשים, או עם התמחות בסוג מסוים של בדיקות, כדוגמה שימושיות, ביצועים, תאימות, לתקינה או ניידות תוכנה. זאת אומרת, כאן לא רק שיש צוות בדיקות עצמאי,
אלא יש צוות בדיקות שעובד עם מתודולוגיה, עם התמחות, סוגים שונים של בדיקות, אם זה שימושיות, Usability, ביצועים, פרפורמנס, תאימות, קומפטביליטי, מוביליטי של הבדיקות.
בקטגוריה החמישית, שהיא רמת העצמאות הגבוהה ביותר, בודקים עצמאים חיצוניים לארגון, כאלה שעובדים באתר הארגון או באתר חיצוני, ממש בדיקות שבלי קשר לצוות הפיתוח ולצוות התכנון של המוצר, מה שנקרא OutSource.
ברבית סוגי הפרויקטים עדיף בדרך כלל ליישם מספר רמות בדיקות, זה מתודולוגית, כאן ה-STQB קובע שיש לשלב או ליצור מספר רמות בדיקות, זאת אומרת, שלב ה-Unit Test, שלב האינטגרציה, בדיקות אינטגרציה, שלב ה-System Test, שלב בדיקות המסירה,
בדיקות סיפורי לקוח וכדומה כאשר חלק מרמות בדיקה אלה מבוצעות על ידי בודקים עצמאיים. מפתחים צריכים להשתתף בבדיקות בייחוד ברמות הנמוכות כדי שתהיה להם שליטה על האיכות של התוצר שלהם. זאת אומרת ה-STQB קובע שככל שהמפתחים משתתפים יותר בבדיקות זה התהליך הנכון כדי שיהיה וריפיקציה ונשמור על כל הנושא הזה של פירמידת הבדיקות שהחלק