בדיקת פתרון התוכנה שלך עשוי להיות משימה מורכבת ומתישה.
עם זאת, בתחרות האינטנסיבית בה ניחן היום עולם הפיתוח, מרווח הטעות שלך מצומצם מאי פעם.
קוד יעיל והדוק יבטיח שהתוצאות שהלקוחות ומשתמשי הקצה ייהנו מהן יהיו ללא דופי.
זהו ללא ספק המאפיין החשוב ביותר כדי לשמור על השם המקצועי שלך.
כשזה מגיע לתהליכי בדיקת תוכנה ראויים, תיעוד נכון הוא המפתח.
ככל שנקפיד על תהליך עקבי ויעיל ונעשה שימוש נכון במסמכי בדיקת התוכנה שלנו, הסבירות שדברים יחמקו מאיתנו מצטמצמת משמעותית.
כאן, נתמקד בארבעת המסמכים שישמשו אותנו בשלבי בדיקת התוכנה השונים ויובילו אותך לתהליכי פיתוח אופטימליים.
STP – מסמך תכנון הבדיקות
לפני שאנו ניגשים לערוך את הבדיקה, יהיה עלינו בראש ובראשונה להבין מה בדיוק בכוונתנו לבדוק.
מסמך ה-STP (Software Test Plan) נועד לעשות בדיוק את זה. הוא בונה את המסגרת שבגבולותיה נערוך את הבדיקות ומאפשר לנו לייעל את התהליך.
מסמך STP מורכב בין השאר מההיבטים הבאים:
- מבוא – חלק זה יפרט את גרסת התוכנה, תאריך הבדיקה ומטרת הבדיקה.
- פירוט סביבת העבודה – האם מדובר ביישום למובייל או לדסקטופ? באיזה מכשיר מבוצעת הבדיקה?
תיאור הסביבה שלנו בצורה מדויקת מהווה חלק בלתי נפרד מאמינות הבדיקה. - קווים מנחים לאסטרטגיית הבדיקה – זהו המקום להגדיר מה בדיוק אנו בוחנים ובאיזה אופן.אילו רכיבים דורשים בדיקה? אילו פונקציות יש בשלב זה לבחון ובאיזו שיטה נעבוד.האם ניישם CI/CD או שרכיבים אלו מתאימים יותר לגישה מסורתית יותר כמו SCRUM.
כאן בדיוק אנו מגדירים ב-STP את הגבולות שלנו.
- הגדרת קריטריון הכניסה – באילו מקרים אירוע כזה או אחר ייחשב כבאג?
- הגדרת חומרת הבאגים – החלת קריטריונים שהופכים באג לקל, בינוני או חמור.
STD – תיאור בדיקת התוכנה
כעת, משהצבנו את המסגרת שבתוכה נעבוד, הגיע הזמן להתחיל לאפיין את מקרה הבדיקה שלנו.
STD (Software Test Description) הוא המסמך שמנחה אותנו כיצד לבצע את הבדיקה בפועל, כיצד נרשום באג ומהם כלל השלבים שיש לבחון בכל פונקציונליות של היישום כדי לוודא שהוא אכן תקין.
ב-STD נבנה לרוב צ’קליסט המפרט בנקודות את כל תסריט הבדיקה שלנו.
SPR – דו”ח שגיאות המערכת
לאחר שהרצנו את כלל מקרי הבדיקה, נותר לנו רק לרשום אותן בצורה מסודרת.
לשם כך בדיוק אנו עושים שימוש ב-SPR (Software Problem report.
ה-SPR מפרט למעשה את השלב במקרה הבדיקה בו חלה השגיאה, אופייה והפונקציונליות שניזוקה כתוצאה מכך.
זהו המסמך שיהווה את הבסיס לדו”ח הסופי שלנו.
STR – דו”ח סופי ללקוח
המסמכים שסקרנו עד כה משמשים למעשה ככלי עזר פנימיים ואין צורך להגישם ללקוח.
לאחר שביצענו את כלל הבדיקות, נרכז ונסכם הכול בצורה מסודרת וקריאה במסמך STR (Software Test report).
ברשימה מובנית ומחולקת לקטגוריות, מאפשר ה-STR להעביר אל צוות הפיתוח את כל הבעיות במסמך אחד ולעבור על פניהן כמעין צ’ק ליסט נוח לשימוש.
תהליך מסודר ומובנה זה מאפשר לך ליישם תהליכי פיתוח מהירים, לצמצם עלויות ולהציע פונקציונליות גבוהה יותר במסגרת הזמנים שלך.
מחפש שירות כתיבת מסך בדיקת תוכנה? פנה עכשיו וקבל הצעה אטרקטיבית!
