תוכנית בדיקה - בדיקות תוכנה

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

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

תוכנית הבדיקה היא תבנית לביצוע פעילויות בדיקות תוכנה כתהליך מוגדר המנוטר ומבוקר באופן מלא על ידי מנהל הבדיקות. תוכנית הבדיקה מוכנה על ידי מוביל הבדיקה (60%), מנהל הבדיקה (20%) ועל ידי מהנדס הבדיקה (20%).

סוגי תוכנית בדיקה

ישנם שלושה סוגים של תוכנית הבדיקה

תוכנית מבחן אב
תוכנית בדיקות שלב
תוכניות בדיקה ספציפיות לסוג בדיקה

תוכנית מבחן אב

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

תוכנית בדיקות שלב

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

תוכניות בדיקה ספציפיות

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

java int כמחרוזת

איך לכתוב תוכנית מבחן

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

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

רכיבים או תכונות של תוכנית בדיקה

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

מטרות: זה מורכב ממידע על מודולים, תכונות, נתוני בדיקה וכו', המצביעים על מטרת היישום פירושו התנהגות היישום, המטרה וכו'.

תְחוּם: הוא מכיל מידע שצריך להיבדק עם אפליקציה בהתאמה. ניתן לחלק את ההיקף לשני חלקים:

בהיקף
מחוץ לתחום

בהיקף: אלו המודולים שצריך להיבדק בקפדנות (בפירוט).

מחוץ לטווח: אלו הם המודולים, שאין צורך לבדוק אותם בקפדנות.

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

עַכשָׁיו איך אנחנו מחליטים אילו תכונות לא ייבדקו?

יש לנו את ההיבטים הבאים שבהם נוכל להחליט איזו תכונה לא תיבדק:

כפי שאנו רואים לעיל עֶזרָה התכונות לא ייבדקו, מכיוון שהן נכתבות ומפותחות על ידי הכותב הטכני ונבדקות על ידי כותב מקצועי אחר.
הבה נניח שיש לנו יישום אחד שיש לו P, Q, R ו-S תכונות שיש לפתח בהתבסס על הדרישות. אבל כאן, תכונת S כבר תוכננה והשתמשה בחברה אחרת. אז צוות הפיתוח ירכוש את S מאותה חברה וישתלב עם תכונות נוספות כגון P, Q ו-R.

כעת, לא נבצע בדיקות פונקציונליות על תכונת S מכיוון שכבר נעשה בה שימוש בזמן אמת. אבל אנחנו נעשה את בדיקות האינטגרציה ובדיקות המערכת בין תכונות P, Q, R ו-S מכיוון שהתכונות החדשות עשויות שלא לעבוד כראוי עם תכונת S כפי שאנו יכולים לראות בתמונה למטה:

נניח בשחרור הראשון של המוצר, האלמנטים שפותחו, כגון P, Q, R, S, T, U, V, W…..X, Y, Z . כעת הלקוח יספק את הדרישות עבור התכונות החדשות אשר משפרות את המוצר במהדורה השנייה והתכונות החדשות הן A1, B2, C3, D4 ו-E5.

לאחר מכן, נכתוב את ההיקף במהלך תוכנית הבדיקה כ

תְחוּם

תכונות לבדיקה

A1, B2, C3, D4, E5 (תכונות חדשות)

P, Q, R, S, T

תכונות שאסור לבדוק

W X Y Z

לכן, תחילה נבדוק את התכונות החדשות ולאחר מכן נמשיך עם התכונות הישנות כי זה עשוי להיות מושפע לאחר הוספת התכונות החדשות, מה שאומר שזה ישפיע גם על אזורי ההשפעה, אז נעשה סבב אחד של בדיקות נסיגה עבור P, Q , R…, תכונות T.

מתודולוגיית בדיקה:

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

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

בדיקות עשן ← בדיקות פונקציונליות ← בדיקת אינטגרציה ← בדיקת מערכת ← בדיקת אד-הוק ← בדיקת תאימות → בדיקות רגרסיה ← בדיקות גלובליזציה ← בדיקות נגישות ← בדיקות שמישות ← בדיקות אמינות ← בדיקות שחזור ← בדיקות התקנה או הסרה

ונניח שעלינו לבדוק את https://www.jeevansathi.com/ יישום, אז נבצע את סוגי הבדיקות הבאים:

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

גִישָׁה

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

אנו יכולים להבין את זרימת האפליקציה בעזרת ההיבטים הבאים:

על ידי כתיבת התרחישים ברמה גבוהה על ידי כתיבת גרף הזרימה

על ידי כתיבת התרחישים ברמה גבוהה

לדוגמה , נניח שאנחנו בודקים את Gmail יישום:

התחבר ל-Gmail- שולח אימייל ובדוק אם הוא נמצא בדף הפריטים שנשלחו
היכנס ל…….
……
….....

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

על ידי כתיבת גרף הזרימה

גרף הזרימה נכתב מכיוון שכתיבת התרחישים ברמה גבוהה לוקחת תהליך של קצת זמן, כפי שאנו יכולים לראות בתמונה למטה:

אנו יוצרים גרפי זרימה כדי להפיק את היתרונות הבאים כגון:

הכיסוי קל
מיזוג קל

ניתן לסווג את הגישה לשני חלקים שהם כדלקמן:

גישה מלמעלה למטה
גישה מלמטה למעלה

הנחה

הוא מכיל מידע על בעיה או בעיה שאולי התרחשו במהלך תהליך הבדיקה וכאשר אנו כותבים את תוכניות הבדיקה, ההנחות המובטחות ייעשו כמו משאבים וטכנולוגיות וכו'.

לְהִסְתָכֵּן

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

לדוגמה, ההשפעה של יישום, תאריך השחרור נדחה.

תוכנית צמצום או תוכנית מגירה

זוהי תוכנית גיבוי שמוכנה להתגבר על הסיכונים או הבעיות.

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

בכל מוצר, ה הנחה שנעשה הוא שכל 3 מהנדסי הבדיקה יהיו שם עד להשלמת המוצר ולכל אחד מהם מוקצים מודולים שונים כגון P, Q ו-R. בתרחיש המסוים הזה, לְהִסְתָכֵּן יכול להיות שאם מהנדס הבדיקה עזב את הפרויקט באמצעו.

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

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

פרספקטיבה של הלקוח
גישת משאבים
חוות דעת טכנית

תפקיד ואחריות

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

ראה דוגמה אחת שבה נבין את התפקידים והאחריות של מנהל הבדיקה, מוביל הבדיקה ומהנדסי הבדיקה.

תפקיד: מנהל בדיקות

שם: ריאן

אַחֲרָיוּת:

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

תפקיד: מוביל מבחן

שם: הארווי

אַחֲרָיוּת:

הכן (כתוב וסקור) את תוכנית הבדיקה
ערכו פגישת סטנד אפ יומית
בדוק ואשר את מקרה הבדיקה
הכן את ה-RTM והדוחות
הקצאת מודולים
ניהול לוח זמנים

תפקיד: מהנדס בדיקות 1, מהנדס בדיקות 2 ומהנדס בדיקות 3

שם: לואיס, ג'סיקה, דונה

הקצה מודולים: M1, M2 ו-M3

אַחֲרָיוּת:

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

לוח זמנים

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

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

לדוגמה

כתיבת מקרי מבחן
תהליך ביצוע

מעקב אחר פגמים

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

להלן היבטים שונים של מעקב הליקויים:

חוסם או שואוסטופר

לדוגמה

קריטי

גדול

קַטִין

גבוה-P1

בינוני-P2

נמוך-P3

לכן, בהתבסס על העדיפות של באגים כמו גבוה, בינוני ונמוך, נסווג אותו כ-P1, P2, P3 ו-P4.

כפתור מרכזי css

סביבות בדיקה

אלו הסביבות שבהן נבדוק את האפליקציה, וכאן יש לנו שני סוגים של סביבות, שהם של תוֹכנָה ו חוּמרָה תְצוּרָה.

ה תצורת תוכנה פירושו הפרטים על שונים מערכות הפעלה כמו Windows, Linux, UNIX ו-Mac ושונות דפדפנים כמו Google Chrome, Firefox, Opera, Internet Explorer , וכולי.

וה תצורת חומרה פירושו המידע על גדלים שונים של RAM, ROM והמעבדים .

לדוגמה

ה תוֹכנָה כולל את הדברים הבאים:

שרת

מערכת הפעלה	לינוקס
שרת אינטרנט	Apache Tomcat
שרת יישומים	וובספירה
שרת מסד - נתונים	Oracle או MS-SQL Server

הערה: השרתים שלעיל הם השרתים המשמשים את צוות הבדיקה לבדיקת האפליקציה.

לָקוּחַ

מערכת הפעלה	Windows XP, Vista 7
דפדפנים	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 ו-Internet Explorer 8

הערה: הפרטים לעיל מספקים את מערכות ההפעלה והדפדפנים השונות שבהם צוות הבדיקות יבדוק את האפליקציה.

ה חוּמרָה כולל את הדברים הבאים:

שרת : Sun StarCat 1500

שרת מסוים זה יכול לשמש את צוות הבדיקות כדי לבדוק את היישום שלהם.

לָקוּחַ:

יש לו את התצורה הבאה, שהיא כדלקמן:

מעבד	Intal2GHz
RAM	2GB
….	….

הערה: זה יספק את תצורת המערכות של מהנדסי הבדיקה שהם צוות הבדיקה.

צוות הפיתוח יספק את התצורה של אופן התקנת התוכנה. אם צוות הפיתוח עדיין לא יספק את התהליך, נכתוב אותו כ-Task-Based Development (TBD) בתוכנית הבדיקה.

קריטריוני כניסה ויציאה

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

קריטריוני כניסה

קריטריוני הכניסה מכילים את התנאים הבאים:

יש לסיים את בדיקת הקופסה הלבנה.
להבין ולנתח את הדרישה ולהכין את מסמכי הבדיקה או מתי מסמכי הבדיקה מוכנים.
נתוני הבדיקה צריכים להיות מוכנים.
יש להכין את ה-Build או את האפליקציה
יש להקצות מודולים או תכונות למהנדסי הבדיקה השונים.
המשאב הדרוש חייב להיות מוכן.

קריטריוני יציאה

קריטריוני היציאה מכילים את התנאים הבאים:

כאשר כל מקרי הבדיקה מבוצעים.
רוב מקרי הבדיקה חייבים להיות עבר .
תלוי בחומרת הבאגים מה שאומר שאסור שיהיה חוסם או באג גדול, בעוד שקיימים כמה באגים קלים.

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

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

בדיקת אוטומציה

במסגרת זו, נחליט על הדברים הבאים:

איזו תכונה חייבת להיות אוטומטית ולא להיות אוטומטית?
באיזה כלי אוטומציית בדיקות אנו הולכים להשתמש באיזו מסגרת אוטומציה?

אנו הופכים את מקרה הבדיקה לאוטומטי רק לאחר השחרור הראשון.

כאן נשאלת השאלה על סמך מה אָנוּ רָצוֹן להחליט אילו תכונות יש לבדוק?

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

עַכשָׁיו, איך אנחנו מחליטים אילו תכונות לא ייבדקו?

לְהַנִיחַ העזרה התכונה של אפליקציית Gmail אינה נבדקת שוב ושוב מכיוון שהתכונות הללו אינן בשימוש קבוע, ולכן איננו צריכים לבדוק אותה לעתים קרובות.

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

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

הערכת מאמץ

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

ניתן לספק בדיקה

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

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

גרפים ומדדים

גרָף

בזה, נדון בסוגים של גרפים אנו נשלח, ונספק גם דוגמה של כל גרף.

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

גרף 1: בזה, נראה כמה פגמים זוהו וכמה פגמים תוקנו בכל מודול.

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

גרף 3: בגרף המסוים הזה, אנו מייצגים את לבנות גרף חכם , מה שאומר שבכל בנייה כמה פגמים זוהו ותוקנו עבור כל מודול. בהתבסס על המודול, קבענו את הבאגים. נוסיף ר כדי להראות את מספר הפגמים ב-P ו-Q, ואנחנו גם מוסיפים ס כדי להראות את הפגמים ב-P, Q ו-R.

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

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

מדדים

כמו לעיל, אנו יוצרים את גרף הפצת באגים, שנמצא באיור 1, ובעזרת הנתונים שהוזכרו לעיל, נתכנן גם את המדדים.

לדוגמה

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

הערת שחרור: זהו מסמך שהוכן במהלך שחרור המוצר וחתום על ידי מנהל הבדיקה.

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

ה הערת שחרור מורכב מהדברים הבאים:

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

לדוגמה

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

תבנית

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

תבנית מקרה מבחן
תבנית סקירת מקרה מבחן
תבנית RTM
תבנית דוח באגים
דוח ביצוע בדיקה

הבה נראה דוגמה אחת של מסמך תוכנית בדיקה

עמוד-1

עמוד3-עמוד18

עמוד-20

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

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

הערה:

מי כותב את תוכנית המבחן?

מבחן מוביל →60%
מנהל בדיקות →20%
מהנדס בדיקה →20%

לכן, כפי שאנו יכולים לראות מלמעלה כי ב-60% מהמוצר, תוכנית הבדיקה נכתבת על ידי ה-Test Lead.

מי סוקר את תוכנית הבדיקה?

מבחן מוביל
מנהל בדיקות
מהנדס בדיקות
צרכן
צוות פיתוח

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

מי מאשר את תוכנית הבדיקה?

צרכן
מנהל בדיקות

מי כותב את מקרה המבחן?

מבחן מוביל
מהנדס בדיקה

מי סוקר את מקרה המבחן?

מהנדס בדיקה
מבחן מוביל
צרכן
צוות פיתוח

מי מאשר את מקרי הבדיקה?

מנהל בדיקות
מבחן מוביל
צרכן

הנחיות תוכנית בדיקה

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

חשיבות תוכנית הבדיקה

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