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

1 כללי

1.1 מטרת המסמך

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

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

המסמך יבוקר ויאושר על-ידי ר"צ בדיקות ומנהל הפרויקט.

1.2 תיאור כללי של המערכת

מסמכים ישימים

{בסעיף זה ירוכזו כל המסמכים אשר שימשו כבסיס לתכנון הבדיקות, ולמסמך זה – ה-STP }

שם המסמך	גרסה
אפיון של פרויקט	1.0

1.3 מונחים ומושגים

STP – מסמך תכנון תכנית הבדיקות – מסמך ראשוני ועיקרי, אשר עליו מבוסס תהליך הבדיקות.

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

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

בדיקות פונקציונליות (Functional) – לאימות פעילות המערכת. בדיקות אלו מבוססות על מסמך הדרישות ומסך האפיון ומטרתן לבדוק כי המערכת עושה את מה שהיא צריכה ולא עושה את מה שאינה צריכה לעשות (valid and invalid testing) בדיקות מול מאגר הנתונים לפני ואחרי כל בדיקה (בדיקות שאילתות).

בדיקות תהליכיות/אינטגרציות (PROCESS) – בדיקות שמתייחסות לרצף פעילויות פונקציונליות שתפקידן לבדוק פעולות שמתחילה החל מהמסך הראשון עד האחרון END TO END מקצה לקצה. ז"א לבדוק את הפעולה מוגדרת שתבדוק את תקינותה על פני כל מסכי המערכת והמאגרים שמושפעים מהתהליך.

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

2 אסטרטגיה לבדיקות

2.1 אסטרטגיה כללית

#	משימה	תאריך התחלה	תאריך סיום	אחריות ביצוע	אחריות כוללת
1	קביעת פגישת תכנון בדיקות. העברת אפיון על (במערכת חדשה או שינוי רוחבי). העברת מסמך דרישות (אם קיים). העברת כלל האפיונים המפורטים, לו"ז והסבר כללי על המערכת.				מנהל פרויקט
2	כתיבת STP (לאחר קבלת כל האפיונים מהצוותים הרלוונטיים)			צוות בדיקות	ר"ץ בדיקות
3	אישור STP			ר"ץ בדיקות	מנהל פרויקט
3	קביעת פגישה עם כל אחד מאחראי תחום מהצוותים (במידת הצורך)	שוטף		בודק	מנהל פרויקט
4	בנית עץ בדיקות/דרישות			בודק	ר"ץ בדיקות
5	בניית טבלת החלטה (מטריצה)	שוטף		בודק	ר"ץ בדיקות
6	הכנת TEST DATA	שוטף		צוות בדיקות\מנהל פרויקט	מנהל פרויקט
7	הרצת התסריטים ופתיחת תקלות			בודק	ר"ץ בדיקות
8	בדיקות הסבת נתונים			בודק	ר"ץ בדיקות
10	הפקת דו"ח סיכום סבב			בודק	ר"ץ בדיקות
11	סיכום הסבב				מנהל הפרויקט
12	כתיבת STR			בודק	ר"ץ בדיקות

2.2 שיטת העבודה

שיטת עקיבות לדרישות/ אפיון

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

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

תבניות מסמכים לתכנון ותיעוד הבדיקות + תהליך הבדיקות

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

תנאי סף לביצוע הבדיקות

רק בהתקיים תנאים אלו:

תכנית הבדיקות (STP) מאושרת ע"י מנהל הפרויקט
תרחישי בדיקות (STD) מאושרים ע"י המאפיין
בוצעו בדיקות יחידה ואינטגרציה בין כל הרכיבים על ידי המפתחים תוך התייחסות להבהקי הבדיקות במסמך האפיון
אין תקלות קריטיות ידועות במערכת/ גרסה (ייבדק באמצעות בדיקות שפיות ע"י צוות הפיתוח)
קיום סביבת בדיקות הכוללת את המערכת והממשקים הנדרשים לבדיקות אינטגרציה, כולל נתוני בדיקות (Test Data)
קיום קודי משתמשים וסיסמאות מתאימים לצוות הבדיקות, בהתאם לסוגי ההרשאות השונים הנדרשים לבדיקה
תנאים נוספים במידה ויוגדרו כאן (לדוגמה קיום חומרה מיוחדת)
קיימת זמינות של בודק/צוות בדיקה ללוחות הזמנים הנדרשים

שיטה/ כלי לניהול תקלות

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

תהליך עבודה מול צוות הפיתוח

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

שיטת הדיווח (דיווח תקלות, דיווח תקופתי, דו"ח סיכום סבב, דו"ח סיכום בדיקות)

דיווחי הבדיקות יתבצעו בסיום סבב של בדיקות בדו"ח סיכום סבב בדיקות.

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

בסיום כל הסבבים של בדיקות המערכת יוכן דו"ח סיכום בדיקות מערכת.

תנאי סף לבדיקות קבלה

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

סביבת העבודה של הבדיקות

תוקצה סביבת עבודה ייעודית לבדיקות מערכת אשר תכלול את ה-Test Data הנדרש ואת קודי המשתמשים עם ההרשאות המתאימות לבדיקות.

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

ניהול תצורה וגרסאות

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

2.3 לו"ז מתוכנן

שלב	מתאריך	עד תאריך
כתיבת STP
תכנון וכתיבת תסריטים (STD)
ביצוע סבב בדיקות I
ביצוע סבב בדיקות II

2.4 תיחום הבדיקות

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

2.4.1 נושאים הכלולים במסמך זה

כתיבתSTD – מפורט ברמת כל מערכת ורכיב ויכילו את הבדיקות האלו.

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

GUI – מתן דגש על תקינות שדות ופקדים.

פונקציונאליות – בדיקת תקינות של פעולה בודדת מערכת.

תהליכיות – בדיקת תקינות שרשרת פעולות פונקציונאליות רציפות.

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

הסבת נתונים – הסבות קבצים / טבלאות

שאילתות ודוחות – שליפה תקינה ונכונה של נתונים ממאגרים ע"פ המיון הרצוי

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

בדיקות אינטגרציה – בדיקות תהליכיות חוצות מערכות

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

2.4.2 נושאים שאינם כלולים במסמך זה

בדיקות בתחנות עבודה מסוגים שונים

עומסים וביצועים (באחריות מחלקת תשתיות )

3 תחזוקה כללית

3.1 שינויים לתכולת המערכת

מס	נושא	סוג שינוי	סעיף באפיון	נושא בדיקה

3.2 קריטריונים לקבלת המערכת לבדיקות

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

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

להלן הקריטריונים:

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

3.3 קריטריונים לאישור המערכת לשלב הבא

הקריטריונים הבאים מגדירים את ה"קו האדום" להעברת המערכת לשלב עבודה הבא.

ה"קו האדום" מוגדר לפי:

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

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

קריטריונים	קריטי	גבוהה	בינוני	נמוכה
תקלות פתוחות	0	0	<10%	<15%

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

קריטריונים	%
% בדיקות שבוצעו מתוך הבדיקות שתוכננו	100%
% בדיקות שעברו מתוך הבדיקות שבוצעו	90%

תקלות המתגלות במהלך הבדיקות מתועדות ומסומנות ב"רמת חומרה". רמות החומרה האפשריות תהיינה:
תקלה קריטית– תקלה שעוצרת תהליך.
תקלה גבוהה- תקלה שאיננה גורמת ל"תעופה" אבל לא מאפשרת המשך פעילות תקין
תקלה בינונית- תקלה שאינה חמורה אך מפריעה למשתמש.
חומרה נמוכה- תקלה של GUI, שפה, הודעה וכד'.

4 נושאי בדיקה

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

4.1 נושא –

	בדיקת נהלים ומומחיות של תרופה מול סוג ביטוח חבר	סוג בדיקה
1		פונקציונאלית – תהליכית
2
3
4
5
6
7
8
9
10
11	כניסה עם רופא מומחה בחירת מטופל ת.ז. כסף ובחירת תרופה עם מומחיות בסיסי, כסף, זהב ועם נהלים בסיסי, כסף, זהב

4.2 נושא –

בדיקת סוג התחשבנות למבוטח

סוג בדיקה

פונקציונאלית – תהליכית

5 מיפוי ממשקים

5.1 ממשקים חיצוניים

מיפוי ממשקים חיצוניים היוצאים / נכנסים למערכת – לא קיים

זיהוי	תיאור	I/O	Online / Batch

5.2 ממשקים פנימיים

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

זיהוי	תיאור	I/O	Online / Batch

6 מיפוי קבצים / הסבות

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

זיהוי	שם קובץ/טבלה	תיאור תכולת הקובץ/טבלה

7 מיפוי תהליכי Batch

רשימה מלאה של תהליכי Batch אשר משפיעים על פעילות המערכת ומהווים חלק ממנה.

Job	שם התהליך	תיאור פעילות התהליך

8 נתונים לבדיקות

TEST DATAיבנה תחת אחריות ראשי צוותים בהתאם לטבלאות החלטה שיבנו לצורך נושא זה.

9 דרישות לביצוע הבדיקות

#	דרישה	סיבה
– Hardware תחנות עבודה


Software – תוכנות
	TEST
	CRM




אחרים
	הרשאות
	הרשאות
	הרשאות

10 משאבים נדרשים

11.1 טבלת משאבי בדיקות לתכנון וביצוע

שם עובד	תפקיד	סה"כ מתוכננים

11. סיכונים

#	סיכון	ניהול הסיכון	רמת סיכון	דרגת סבירות	חומרת גורם סיכון
	אי עמידה בלו"ז הבדיקות: עיכוב כתיבת מסמכי STD	הגשת מסמכי אפיון מאושרים וסגורים בזמן	0.8	8	6.4
	אי עמידה בלוחות הזמנים של הפרויקט. עיכובים בשלבי פיתוח התוכנה. וחוסר אינטגרציה בין הצוותים.	חלוקת עומס העבודה באופן יעיל, כך שהנתיב הקריטי של הפיתוחים הגדולים יסנכרן על פי הלו"ז מתוכנן.	0.4	9	3.6
	סביבת בדיקות לא יציבה/סביבת הבדיקות אינה מוכנה בזמן – פגיעה באמינות ואיכות הבדיקות	עדכון סביבת הTEST וניהול גרסאות	0.1	9	0.9
	הסבת פריטים לא תקינה	בדיקת הקישור של ההסבה בין 2 המערכות	0.5	9	4.5
	חוסר הרשאות למערכות בסביבת הבדיקות	מתן הרשאות	0.3	8	2.4
	עיכובים בטיפול בתקלות	עמידה בלוח זמנים לפתרון תקלות מול חומרת תקלה	0.5	9	4.5
	חשש במחסור בכ"א לבדיקות	סנכרון ותיעדוף חוזר של תכנית הבדיקות	0.1	5	0.5

#טכנולוגיה

דוגמא למסמך (תבנית) לתכנון בדיקות מערכת מידע (STP)