בכל הצעה לפיתוח תוכנה יש שורה שאומרת "בדיקות" או "QA", ובדרך כלל היא נראית זהה אצל כל הספקים. אבל מאחוריה יכולות לעמוד עבודות שונות מאוד: מפתח שלוחץ על כמה מסכים לפני שהוא מעביר לכם, או תהליך מסודר עם תרחישים, מכשירים וסביבה נפרדת. המדריך הזה הוא מדריך תכולה לקונה: איך לפרק את המילה לחלקים, איך לחלק אחריות, ומה לדרוש שייכתב בהצעה. הוא לא מדריך למי שבונה אוטומציה של בדיקות, והוא לא משווה בין ספקים.
אם אתם רוצים להבין איך בדיקות משפיעות על התמחור בכלל, הגיעו קודם למדריך עלויות פיתוח האפליקציה — הוא מפרק את גורמי העלות, ובדיקות הן אחד מהם. כמה עולה לפתח אפליקציה — גורמי העלות
ששת סוגי הבדיקות שמסתתרים מאחורי המילה
לא כל סוג בדיקה נדרש בכל פרויקט. מה שחשוב הוא שההצעה תגיד אילו נכללים — ואילו לא, ובמפורש.
| סוג | מה זה בודק | שאלה לשאול את הספק |
|---|---|---|
| בדיקות ידניות | אדם עובר על המערכת כמו משתמש ובודק שהיא עושה מה שהוגדר, כולל מצבים חריגים | מי עושה את זה — מישהו שלא כתב את הקוד? לפי אילו תרחישים? |
| בדיקות אוטומטיות | קוד שבודק קוד: מריצים אותו בכל שינוי ומקבלים התרעה אם משהו נשבר | על אילו חלקים יש בדיקות אוטומטיות, ואם הן נמסרות לכם עם הקוד |
| רגרסיה | בדיקה שפיצ'ר חדש לא שבר משהו שעבד קודם | איך מוודאים את זה בכל גרסה — ידנית, אוטומטית, או בכלל לא? |
| מכשירים ודפדפנים אמיתיים | שהמערכת עובדת על המכשירים, גרסאות המערכת והדפדפנים שהקהל שלכם באמת משתמש בהם | מהי רשימת המכשירים והדפדפנים, ומי קבע אותה |
| עומסים וביצועים | איך המערכת מתנהגת כשהרבה משתמשים או הרבה נתונים נכנסים בו־זמנית | האם נכלל בכלל, ואם כן — מול איזה עומס מוגדר מראש |
| בדיקות קבלה (UAT) | אתם, או נציגי העסק, מאשרים שהמערכת עושה מה שהזמנתם — לפי קריטריונים שסוכמו | כמה זמן יש לכם לבדוק, ומה קורה אם נמצאו ליקויים |
כדי לראות איך זה נראה אצלנו: בעמוד פיתוח האפליקציות מפורטת בדיקה על מכשירי iPhone ו-Android אמיתיים, בגרסאות ורזולוציות שונות, כחלק מתכולת הפרויקט — כשרשימת המכשירים נקבעת לפי קהל היעד. מה כלול בפיתוח אפליקציה — כולל בדיקות על מכשירים אמיתיים
מי אחראי למה: ספק מול לקוח
בדיקות הן עבודה משותפת, ורוב הבעיות נולדות כשכל צד מניח שהצד השני עושה חלק. הטבלה הבאה היא נקודת פתיחה לשיחה — לא חלוקה קבועה. מה שחשוב הוא שהיא תהיה כתובה.
| פעולה | בדרך כלל אצל הספק | בדרך כלל אצל הלקוח |
|---|---|---|
| כתיבת תרחישי בדיקה | תרחישים טכניים ומקרי קצה שנגזרים מהאפיון | תרחישי עסק אמיתיים: איך העבודה היומיומית נראית, ואילו מקרים בעייתיים קורים אצלכם |
| הרצה בזמן הפיתוח | בדיקות פנימיות, אוטומטיות ו-QA לפני כל מסירה | בדיקה של כל גרסה שמוצגת לכם, בזמן, ומשוב כתוב |
| סביבה ונתוני בדיקה | הקמת staging ותחזוקתו | נתוני בדיקה מייצגים, בלי מידע אישי אמיתי שלא אושר לשימוש |
| תיעוד ליקויים | מערכת מעקב, וטיפול לפי סדר עדיפות מוסכם | דיווח ברור: מה עשיתם, מה ציפיתם, מה קרה, צילום מסך |
| קבלה | הצגת מה בוצע ומה נשאר פתוח | החלטה: מאשרים או מחזירים — בכתב ובמועד שהוסכם |
מה נכנס לסעיף הבדיקות בהצעה — ומה לא
סעיף בדיקות שאפשר לעבוד איתו מכיל רשימה ברורה של מה כלול, ורשימה נפרדת של מה לא. הרשימה השנייה חשובה לא פחות: היא מונעת את השיחה "חשבנו שזה כלול" אחרי ההשקה.
- סוגי הבדיקות שנכללים, לפי הטבלה הראשונה, כולל מה שלא נכלל במפורש (למשל: בדיקות עומסים).
- רשימת הפלטפורמות: מכשירים, גרסאות מערכת הפעלה ודפדפנים שהמערכת נבדקת עליהם.
- חלוקת האחריות, כמו בטבלה השנייה.
- קריטריוני הקבלה לכל שלב או לכל פיצ'ר, או התחייבות מתי הם ייכתבו ומי מאשר אותם.
- הסביבה: האם יש staging, מי נכנס אליו, ואיזה נתונים יש בו.
- הגדרת "ליקוי" מול "בקשה חדשה", ותקופת תיקון ליקויים אחרי המסירה — כהסכמה כתובה ולא כהבנה בעל פה.
כשמשווים הצעות, הסעיף הזה הוא אחת הסיבות שהצעה זולה יותר לא בהכרח זולה יותר: לפעמים היא פשוט כוללת פחות בדיקות. איך מיישרים תכולה בין הצעות ומה עוד לשאול ספק — במדריך הבחירה בבית תוכנה. איך בוחרים בית תוכנה — ומה להשוות בין הצעות
קריטריוני קבלה כתובים
קריטריון קבלה הוא משפט שאפשר לענות עליו ב"כן" או "לא" אחרי שמנסים את המערכת. הוא נגזר ישירות מהדרישות — ולכן מסמך דרישות מסודר הוא תנאי לקריטריונים טובים. אם אתם עוד בשלב שלפני המסמך, הדוגמה במדריך המסמך מראה איך נראית דרישה ברמת מסך. דוגמה למסמך דרישות לאפליקציה
| במקום | כתבו | למה זה עדיף |
|---|---|---|
| "ההרשמה תעבוד" | "משתמש חדש שמזין פרטים תקינים מקבל הודעת אישור ונכנס למסך הבית; משתמש שמזין כתובת מייל שכבר רשומה רואה הודעה שמסבירה זאת ולא שגיאה כללית" | אפשר לנסות ולענות כן/לא, וכולל מצב שגיאה |
| "המערכת מהירה" | "מסך הרשימה נטען ומציג תוצאות בזמן שסוכם מראש, על המכשירים שברשימה, בחיבור רגיל" — כשהזמן נקבע בין שני הצדדים, לא מועתק מכאן | הופך תחושה למשהו שניתן למדוד |
| "הרשאות מתאימות" | "משתמש בתפקיד X לא רואה ולא יכול לפתוח נתונים של משתמש בתפקיד Y; ניסיון לפתוח קישור ישיר מחזיר הודעת חוסר הרשאה" | בודק גם את המקרה שהמשתמש "מנסה לעקוף" |
סביבת staging: איפה בודקים
staging היא עותק של המערכת שמיועד לבדיקות: אותה תצורה כמו הסביבה החיה, אבל עם נתוני בדיקה ובלי משתמשים אמיתיים. בלעדיה בודקים או על המחשב של המפתח — שם הכול "עובד" — או על המערכת החיה, ואז בדיקה שגויה יכולה לשלוח הודעה ללקוח אמיתי או לשנות נתון אמיתי.
| שאלה | למה היא חשובה |
|---|---|
| האם יש staging נפרד מהסביבה החיה? | בלי הפרדה, כל בדיקה היא סיכון למערכת החיה |
| האם אתם יכולים להיכנס אליו בעצמכם? | בדיקות קבלה שנעשות רק בהדגמה של הספק הן הדגמה, לא קבלה |
| אילו נתונים יש בו? | נתוני בדיקה מייצגים מאפשרים לבדוק תרחישים אמיתיים בלי לחשוף מידע של לקוחות |
| איך מחברים לשירותים חיצוניים (תשלום, מסרונים, מייל)? | חיבור סביבת בדיקה לשירות אמיתי עלול לחייב או לשלוח הודעות. כדאי לברר עם הספק החיצוני אם יש לו מצב בדיקה נפרד |
| מי משלם על הסביבה ומי מחזיק בגישה אליה אחרי המסירה? | סביבה שנשארת אצל הספק משאירה אתכם בלי מקום לבדוק שינויים עתידיים |
דוגמה מסומנת: סעיף בדיקות בהצעה
| סעיף | ניסוח לדוגמה |
|---|---|
| כלול | בדיקות ידניות של כל פיצ'ר לפני כל מסירה; בדיקות אוטומטיות לחלקי הלוגיקה העסקית המרכזיים; רגרסיה לפני כל גרסה; בדיקה על המכשירים והדפדפנים שברשימה המצורפת |
| לא כלול | בדיקות עומסים (ניתן להוסיף כשלב נפרד לפי נפח משתמשים צפוי); בדיקות חדירה על ידי גורם חיצוני |
| אחריות הספק | תרחישים טכניים, הרצה, תיעוד ליקויים ותיקונם, הקמת staging |
| אחריות הלקוח | תרחישים עסקיים; בדיקת קבלה של כל גרסה תוך ___ ימי עבודה ממסירתה; אישור או החזרה בכתב |
| קריטריוני קבלה | נכתבים לכל פיצ'ר לפני תחילת הפיתוח שלו ומאושרים בכתב על ידי הלקוח |
| אחרי הקבלה | ליקוי שנמצא בתוך ___ אחרי המסירה ומנוגד לקריטריון שאושר — מתוקן ללא תוספת; שינוי בהתנהגות שאושרה — בקשה חדשה |
מה קורה כשבדיקות לא תפסו משהו
בדיקות מצמצמות סיכון ואינן מבטלות אותו. תמיד יימצא משהו אחרי ההשקה, ולכן חשוב לדעת מראש מה קורה אז. הסכמה טובה כוללת מי מקבל דיווח ואיך, איך מדרגים חומרה (תקלה שחוסמת עבודה מול תקלה קוסמטית), ובאיזה מסגרת טיפול התיקונים נעשים — כחלק מתקופת תיקון מוגדרת או כחלק מהסכם תחזוקה. בעמוד פיתוח התוכנה מתואר שבאג אחרי ההשקה הוא לא הסוף: יש מי שמטפל בו, בהיקף ובשעות שנקבעו בהסכם התחזוקה. איך מגדירים ומוסרים פרויקט תוכנה — כולל קריטריוני קבלה לכל שלב
מה אנחנו עושים בשלב הזה
בעמודי השירות שלנו מתוארת תכולה מוגדרת שנמסרת בשלבים עם קריטריוני קבלה לכל שלב, ובדיקות על מכשירים אמיתיים בפרויקטי מובייל. אם יש לכם הצעה ביד ואתם לא בטוחים מה כלול בסעיף הבדיקות שלה — של ספק אחר או שלנו — אפשר להביא אותה לשיחה ולעבור עליה לפי הטבלאות במדריך הזה. פיתוח תוכנה בהתאמה אישית — הגדרה ומסירה