איך לבדוק?
בפרקים הקודים עסקנו בהרחבה בנושאים תאורטים.
ניגש כעת להיבטים המעשיים של בדיקת תוכנה.
הנחת עבודה
איש QC המתבקש לבדוק תוכנה, צריך תמיד לבוא בהסתכלות ביקורתית.
יש באגים בתוכנה !
וכיוון שכך, יש לשאוף למצוא אותם.
אסור בשום אופן להניח שהתוכנה נקיה מבאגים.
לא אחת, אנו נתקלים במתכנתים הבטוחים כי הקוד שיצא תחת ידם, הוא 100% מושלם.
קוד של מפתחים כאלו יש לבדוק במשנה זהירות.
בכל פעם שמתקבלת גרסה חדשה עם תיקונים לבאגים קודמים, אין לדעת מה השתבש במהלך
התיקון.
שינוי שורת קוד אחת, יכול להשפיע במקומות אחרים שאינם צפויים.
תוכנית עבודה
הבודק צריך להכין לעצמו תוכנית עבודה.
התוכנית תיקבע בהתאם לאפיון הקוד הנבדק:
- תהליך בודד - Process
- אפליקציה - Application
- תוכנית - Program
- אוסף תוכניות - Collection of programs
- מערכת שלמה - Entire System
התוכנית תושפע גם מאופי הבדיקות המבוקש:
- פונקציונליות - Functionality
- שימושיות - Usability, User friendly
- ביצועים - Stress test
- בדיקות עומס - Survivability, Loading Tests
- אבטחה - Security
תוכנית בדיקות נקראת בשפה המקצועית ATP
ATP
ATP מורכב מתרחישים רבים (Scenarios).
עבור כל תרחיש מתוארת התוצאה הצפויה (Expected Result).
הבודק צריך להשוות את התוצאה הרצויה לתוצאה בפועל (Actual Result)
התרחישים השונים צריכים לכסות על כל המקרים המופיעים בדרישות (Specification,
Spec), ובדגש מיוחד על מקרי הקצה.
ישנם תוכנות שונות המסיעות בבניית ATP, אחת מהן היא Test Director הנסקרת בפרק כלים.
יתכן ותוכנה מסוימת נבדקת על ידי יותר מצוות אחד. במקרה כזה, יש לוודא כי אין חפיפה בבדיקות של הצוותים השונים (יעילות).
יש לציין, כי לפעמים נעדיף ששני צוותים יבדקו דברים זהים בתוכנה, וזאת כביקורת על שיטות העבודה שלהם. כך נוכל לראות האם בצוות X גילו באגים רבים שצוות Y לא עלה עליהם.
תוכנית העבודה כוללת פרק המגדיר את סביבת העבודה הנדרשת לצורך הבדיקות.
סביבת עבודה כוללת רכיבי חומרה או תוכנה יעודיים, סימולאטורים מיוחדים, וכדומה
|
|
|
