
הטקסט המלא של הדקות הראשונות בהרצאה «ראיון עבודה מקצועי בשילוב מושגים מתחום הבדיקות - QA - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טיפה שישי, מושגים שחייבים להכיר לפני שאנחנו מגיעים לרעיון. אז אמרנו שרעיון עבודה זה מין שיחה מקצועית בין המועמד לבין המנהל הפוטנציאלי, המנהל העתידי.
אנחנו רוצים להראות שאנחנו מסוגלים לדבר בשפת הבדיקות. אלה מושגים אני חושב שחייבים להכיר, ולעשות סימולציה לפני שאנחנו מגיעים לרעיון, שאנחנו רואים באמת שאנחנו משתמשים במושגים האלה ומבינים אותם בעצמנו ונותנים דוגמאות.
לדוגמה, Software Development Lifecycle, באזור חיים של פיתוח תוכנה. אז דיברנו על Software Development Lifescape. הדבר הכי טוב שאנחנו יכולים לעשות זה לתרגל את היכולת שלנו לצייר את הציור הזה. אז יש לנו Planning שזה תכנון, יש לנו את ה-Analyzing, את הניתוח, יש לנו את ה-Design שזה העיצוב בעצם של הפרויקט.
ב-Planning אנחנו מתכננים, ב-Analyzer אנחנו מנתחים את הדרישות, ב-Design אנחנו כבר מתחילים לפרוט את התכנון לפסים יותר ספציפיים, וזה כמובן ברמה תיאורטית, אנחנו לא באמת עושים את זה, אני רק רוצה להסביר את ה-SDLC.
יש לנו את הפיתוח עצמו, ואז יש לנו את שלב הבטחת האיכות. כלומר, אנחנו רוצים לוודא שהמוצר שפותח עולה בקנה אחד עם התכנון, ומה שרצו שיהיה מבחינת הלקוח, מבחינת הפלנינג והאנלייזינג.
כלומר, השלב הזה הוא מאוד קריטי, ופה אנחנו צריכים להתמקד, שזו העבודה שלנו. השלב האחרון הוא maintenance. כלומר, לקבל פידבק מהמערכת המוגמרת ולראות האם יש תיקונים הכרחיים שצריך לעשות.
זה דבר שהייתי ממליץ ללמוד לצייר במקרה שאנחנו מגיעים לרעיונות עבודה, לתפקיד איש בדיקות. אז יש לנו בדיקות ידניות, מה זה בדיקות פונקציונליות?
דיברנו על זה בסרטון הקודם. בדיקה פונקציונלית מוודא שהאתר עושה מה שאני רוצה, לדוגמה, אז אני רוצה לדעת באמת שהטופס מבצע את הפעולה. כלומר, כשאני ממלא את הטופס, באמת זה מה שקורה.
נגיד יש לי אתר לרכישה כמו ebay או אמזון או אתר e-commerce אחר, אני רוצה לוודא שאני מסוגל לרכוש מוצר דרך האתר. לעומת בדיקה שאינה פונקציונלית, זו בדיקה שמתמקדת ב-user experience, בחוויית משתמש, בעיצוב, מותאמות של האתר לכלים שונים או למערכות שונות, לבראוזרים שונים, למערכות הפעלה שונות.
כל זה נכנס למעטפת של ה-non-functional. גם בדיקות עומסים, בדיקה של המערכת מול עומס של משתמשים היא בדיקה שנקראת לא פונקציונלית אלא בדיקה שהיא בודקת עומסים.
אז יש לנו פונקציונל שזה לבדוק את היכולת של האתר שלנו לעשות את מה שנדרש ממנו, לעומתנו פונקציונל בדיקות שהן יותר כלליות ורוצות לבדוק את המערכת מבחינת שאר הדברים, לא רק הפונקציונליים.
יש לנו את שיטת העבודה האג'ייט, דיברנו גם על זה, שיטה גמישה שבה איש הבדיקות ואיש הפיתוח עובדים במקביל וביחד על הפיתוח על מנת לקצר את זמן הפער בין הפיתוח לבין אבטחת האיכות, וכך לקצר את זמן הפיתוח.
לעומת זאת, שיטת ווטרפול זה גישה שמרנית, מיושנת קצת, שבה הצוותים עובדים בטור, כל צוות מסיים את החלק שלו, ורק אז מתחיל הצוות השני לעבוד, מה שיוצר פער של זמנים בין צוות הבדיקות לצוות הפיתוח, והפער הזה גורם לאיטיות
בתהליך הפיתוח והמשוב על תקלות במערכת. בלאקבוקס ווייטבוקס, כלומר, בדיקות קופסה שחורה מול קופסה לבנה. וייטבוקס זו בדיקה שקשורה לקוד, שמבוצעת על ידי מתכנתים, קולגות למתכנת שכתב את הקוד, לעומת בלאקבוקס, בדרך כלל על ידי מישהו שמייצג את הלקוח הסופי,
שלא אמור להסתכל על API וקוד, בדרך כלל הם יהיו אנשי הבדיקות. אנחנו נרצה לבדוק בלאקבוקס, זאת אומרת, בדיקות פונקציונליות של המערכת, ולא whitebox דרך הקוד עצמו. איך לכתוב טסט קייס? גם על זה דיברנו.
אמרנו שאנחנו רוצים לתאר צעדים ספציפיים במערכת שאנחנו מבצעים, על מנת בסוף להגיע למצב שהמערכת צריכה לבצע את המערכת על פי הציפיות שלנו,