מטרות של בדיקות תוכנה
פרקי ההרצאה: מטרות של בדיקות תוכנה
תמלול ההרצאה: מטרות של בדיקות תוכנה
הטקסט המלא של הדקות הראשונות בהרצאה «מטרות של בדיקות תוכנה» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום, בפרק זה נמשיך ללמוד את פרק 1 בחומר של ה-STQB להסמכה. מחומר זה בעצם ייגזרו השאלות למבחן ההסמכה ל-STQB. אז בסעיף 1 אנחנו רואים 1.11 מטרות אופייניות של בדיקות.
בכל פרויקט תוכנה יש מטרות שמוצבות מעבר למטרות של התוכנה עצמה, מה שהיא צריכה לבצע, אם זה תוכנה בנקאית, יש לה מטרות לשרת את הלקוחות של הבנק.
לצוות הבדיקות בעצם יש את המטרות שלו שהן נגזרות מהמטרות של אותה אפליקציה, אותה תוכנה שאנחנו באים לבדוק.
לדוגמה, הערכת תוצרי עבודה כמו דרישות Requirement. אם הדרישה של האפליקציה הבנקאית היא לספק מבט ללקוח על העו"ש שלו, על העובר ושב שלו, אז גם המערכת הבדיקות תצטרך לדעת לבדוק את הפעילות הזאת.
סיפורי משתמש, מה זה אומר סיפור משתמש? נשאר בדוגמת האפליקציה הבנקאית. אותו משתמש רוצה לבדוק את העובר ושב שלו. אז הסיפור של אותו משתמש הוא שהוא נכנס לאפליקציה, מבצע הסדרות, מכניס את כל הפרטים האישיים בלוגין והמערכת עושה לו איזשהו ולידציה ללוגין שלו ולאחר מכן מראה לו את הפרטים בעובר ושב שהוא ביקש לראות.
סיפור נוסף יכול להיות זה שאותו משתמש נכנס ורוצה לבדוק את מצב ההלוואות שהוא לקח או לבצע הלוואה אונליין ישירות דרך האתר הבנקאי זה סיפור משתמש נוסף. הסיפור משתמש זה משהו שאנשי הבדיקות צריכים להבין ולנסח ולראות את הבדיקות כחלק מסיפור של אותו משתמש קצה, אותו לקוח.
פעילות נוספת של צוות הבדיקות יהיה בדיקת עיצוב, האם הלוגו מוצג בצורה תקינה, האם הפונטים הם ברורים וקלים לקריאה. פעילות נוספת של הבדיקות, אבל לאו דווקא של צוות הבדיקות הידני או צוות הבדיקות הנפרד, זה לבדוק את הקוד שנכתב.
לכל מערכת תוכנה נכתב קוד ומישהו צריך לבדוק אותו אחרי שהוא נכתב. ברוב הפרויקטים שמנוהלים בצורה נכונה מי שכותב את הקוד יש איזשהו review איזושהי בקרה על כתיבת הקוד ועל אופן הביצוע של העבודה כך שזה איזשהו שכבה נוספת של בדיקה.
כל הנושאים הראשונים שאמרנו הערכת requirements סיפורי משתמש הם ועיצוב הם ברמה בעצם של קופסה שחורה או איזשהו תוצרי בדיקה או להסתכל על האפליקציה מבחוץ.
לעומת זאת בדיקת הקוד היא קופסה לבנה white box testing ואנחנו מבקשים לראות מה קורה בתוך התהליך של הכתיבה עצמו של המפתח. ברוב הפעמים אנשי הבדיקות יעסקו רוב הזמן בצורת בדיקה של black box אנחנו נדבר על המושג הזה קופסה שחורה שבה הם משתמשים על המערכת מבחוץ כאותו בודק קצה אותו לקוח.
פעילות נוספת של צוות הבדיקות, של אנשי הבדיקות, נגזרת מהסעיף הקודם. אימות Verification שכל הדרישות ממומשות. הרבה פעמים אנשי הבדיקות יעבדו ממש בצורת צ'קליסט, זאת אומרת רשימת דרישות מול סיפורי לקוח שבודקים שאכן הם מומשו.
אנחנו נרצה לעבור בצורה מסודרת ולוודא דרישה דרישה לפי סיפור לקוח איך היא מומשה בצורה תקינה באפליקציה שאותה אנחנו בודקים. דרישה יכולה להיות משתמש קצה באפליקציה בנקאית, נכנס ומזמין צ'קים.
סיפור המשתמש יהיה המשתמש מבצע הזדהות לתוך האפליקציה, נכנס למסך הפעולות ולוחץ על פעולת הזמנת צ'קים והפעולה מגיעה בעצם למערכת שאחראית על ביצוע התהליך עצמו של שליחת הצ'קים.