
הטקסט המלא של הדקות הראשונות בהרצאה «מסמך אסטרטגיית בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
מסמך אסטרטגיית בדיקות בכל פרויקט מהנדס או מהנדסת הבדיקות האחראים על הפרויקט צריכים להכין מסמך אסטרטגיית בדיקה.
במסמך יתואר איך פרויקט ייבדק בקווים כלליים. טיפת המסמך היא להציג לכל בעל העניין בארגון את התחום SCOF של צוות הבדיקות, איזה חלקים במערכת הולכים להיבדק ובאיזו צורה.
מומלץ מאוד להכין טמפלייט, איזשהו מסמך אב שיהווה בלו פרינט, איזשהו טמפלייט להכנת מסמכי אסטרטגיית בדיקות לפרויקטים שונים.
אז איך מסמך אסטרטגיית הבדיקות אמור להיות בנוי? אז יש לנו פה דוגמה למסמך בדיקות, מסמך אסטרטגיית בדיקות, ויש לנו פה מחולק לחלקים.
אנחנו צריכים לזכור שמעבר למבנה הסטרקצ'ר שעליו נעבור, אנחנו צריכים לזכור שבעצם המסמך הזה, המטרה שלו זה להראות איך משתלב תהליך הבדיקה או או אבטחת האיכות בכל שלב ושלב מתהליכי הפיתוח.
כלומר, מהשלב של ה-unit test ועד השלב של האינטגרציה וה-system test. צריך לזכור את המוצגים האלה שמנתחים את ה-sample test strategy, או את המסמך אב לביצוע אסטרטגיית בדיקות.
אז יש לנו את החלק הראשון שהוא מבוא, ובחלק המבוא אנחנו נרצה לתת איזשהו מבט על האיכויות או התוצרים של צוות הבדיקות או של תהליך הבדיקות.
מה האיכות בעצם שהולכת להיות ושולבת בתוך התהליך הפיתוחי, בתוך תהליך הפיתוח? איך אנחנו הולכים לוודא שבכל שלב ושלב של תהליך הפיתוח יהיה גם חלק של איכות, חלק של בקרה?
יש לנו את החלק של הרפרנס, של הסימוכים, מקורות, שפה אנחנו נשלב קישורים לכל מיני כלים, כל מיני מסמכי בדיקות, כל מיני מסמכי דרישות, מסמכי עציות של המערכת, כדי להראות על סמך מה בנינו את הבדיקות שלנו, תוצרי הבדיקות יש לנו פה את החלק המרכזי אחד החלקים המרכזיים
במסמך שהוא qa deliverable זאת אומרת תוצרי תהליך הבדיקות תוצרים הם בעצם test plans זאת אומרת תוכניות בדיקה מסמכים שבעצם מפרטים את הבדיקות הספציפיות על כל חלק וחלק במערכת שאותם אנחנו בודקים חלק שמפותח לדוגמה אנחנו בודקים מערכת כמו פייסבוק ואנחנו נרצה לבדוק את החלק של כתיבת או חלק של ביצוע לייק, או חלק של ביצוע שייר,
או חלק של שיתוף מסמכים וכדומה, צ'אט ועוד ועוד. כל אחד ואחד מהם אמור לקבל טסט פליין שבעצם יכסה אותו, ידאג ל-covered של איכות ובקרה של המערכת.
עוד תוצרים שיש לנו ואנחנו צריכים לזכור אותם באותו מסמך אסטרטגי בדיקות זה התקלות. צוות הבדיקות דואג לפתוח תקלה כאשר ה-requirement, כאשר הדרישה לא עולה בקנה אחד עם מה שפותח.
יש איזשהו פער בין מה שהמערכת מבצעת בפועל לבין מה שהיא הייתה אמורה לבצע על פי התכנון. וכאן באות התקלות שלנו והן יתועדו, וזה אנחנו רוצים גם לפרט בתוך מספר האנסטרטגיה לבדיקות, או לציין את הקווים הכלליים שבהם אנחנו נבצע את התקלות או נתעד תקלות.
את הנושא של עוד תוצרים יכול להיות enhancements, זאת אומרת הרחבות או בקשות נוספות לפיתוח או לייעול המערכת גם אם זה לא תקלה, אז אנחנו נרצה כצוות הבדיקות להוסיף גם את זה כחלק מתוצרי התהליך, ויש לנו גם עצות או רעיונות של Usability, של שימושיות למערכת, זאת אומרת צוות הבדיקות לא רק מסתפק בפתיחת תקלות, אלא גם בא עם רעיונות
ועם תמיכה בצד של המשתמש מול צוותי הפיתוח וצוותי המוצר. ויש לנו את הנושא של איך אנחנו משחררים את המסמך הזה, כי המסמך הזה הוא מתעדכן, הוא מסמך נושם, כלומר הוא מסמך שאנחנו מתעדים בו תוך כדי עבודה מול המערכת.
עוד מרכיב במסמך אסטרטגיית הבדיקות הוא טסט מנדמנט, ניהול הבדיקות. אנחנו פה נזכור איזה כלים אנחנו עושים בהם שימוש, לדוגמה ג'נקינס זה כלי שאחראי על בניית