תכלס השאלות מתוך ראיונות עבודה ב-QA - חלק 3
פרקי ההרצאה: תכלס השאלות מתוך ראיונות עבודה ב-QA - חלק 3
תמלול ההרצאה: תכלס השאלות מתוך ראיונות עבודה ב-QA - חלק 3
הטקסט המלא של הדקות הראשונות בהרצאה «תכלס השאלות מתוך ראיונות עבודה ב-QA - חלק 3» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, אנחנו ממשיכים בשאלות, בהכנה לשאלות שעלולות לצוץ או עשויות לצוץ ברעיון עבודה לתפקיד איש בדיקות תוכנה. אז אחת השאלות שיכולה לעלות היא שאלה כזאת שמופיעה באתר גורו 99, מה ההבדל או מה הם ברנץ' טסטינג ולעומת זאת מה זה באונדרי טסטינג.
אז בואו נתחיל בבאונדרי טסטינג. באונדרי טסטינג זה סוגי בדיקות ששייכות לקופסה שחורה, שבהם אנחנו נותנים קלטים שעומדים על הגבול שבהם המערכת אמורה להתמודד.
לדוגמה, אם אנחנו צריכים להזין פרטי משתמש ויש לנו סיסמה נדרשת לאותו משתמש, והסיסמה חייבת להיות בין 8 ל-16 תווים, אז ערכי הגבול של השדה של הסיסמה שאותו אנחנו רוצים לבדוק זה בין 8 ל-16, אז אנחנו ננסה לתת סיסמה של 8 תווים או 7 תווים או סיסמה של 16 תווים ו-17 תווים.
שהקצה התחתון שבעה תווים אמורה לקבל הודעות שגיאה כסיסמה לא תקינה בפרטי המשתמש החדש ולעומת זאת שבע עשרה אמורה גם לקבל הודעות שגיאה כלא תקינה מבחינת הרמה העליונה ושמונה ושש עשרה מבחינת התווים של הסיסמה אמורה להיות חוקית ותקינה זה דוגמה לבאונדרי וליו לעומת זאת ברנץ' טסטינג שייכת לתחום של
בדיקות קופסה לבנה וזה אומר כשאנחנו צריכים לבדוק את כל ההצטרפויות של הקוד, כשאנחנו רוצים לבדוק את כל ההצטרפויות של הקוד, אנחנו קוראים לזה Branch Testing.
זאת אומרת, כל ה-if, else, כל השאלות האלה שעולות בתהליך של בדיקת קוד, אז אנחנו בודקים בעזרת Branch Testing, וזה שייך לתחום של בדיקות קופסה לבנה.
What are the contents of test plan and test cases? אז מה אנחנו בעצם מכילים או מחזיקים בתוך המסמכים האלה, שנקראים טסט פלאן, תוכנית בדיקה וטסט קייסס, מקרי בדיקה.
אז יש לנו את היעדים של הטסט וטסט פלאן, מה אנחנו רוצים להשיג, איזה בדיקות אנחנו רוצים לבצע, על איזה תחומים בתוך המערכת אנחנו רוצים לבצע, מה הסקופ של המערכת, זאת אומרת מה אנחנו נבצע ומה לא נבדוק, אנחנו צריכים להגיד גם
מה הגבולות של הבדיקות, הגבולות של הטסטים, התחומים של הטסטים מבחינת מודולים שאנחנו נבדוק במערכת הנבדקת באיזה סביבה אנחנו נבצע אם זאת תהיה בסביבת דיבלופמנט בסביבת טסט בסביבת UAT בסביבת ייצור אנחנו נבצע את הבדיקות כל הדברים האלה בעצם אנחנו צריכים לציין והם ישפיעו על
הטסט פרנד ועל הטסט קייסס למה אנחנו נבצע את הטסטים שאנחנו מחליטים לבצע ולא טסטים אחרים הקריטריון של כניסה זאת אומרת ויציאה זאת אומרת מתי מבחינתנו מספיק הבדיקות מתי אנחנו חושבים שתהיה אינדיקציה שהמערכת היא מספיק טובה זאת אומרת אנחנו לא בודקים לנצח אנחנו בודקים עד שאנחנו מקיפים את כל תחום הבדיקות שאנחנו רוצים ואין באגים
קריטיים ואנחנו מרגישים שאנחנו בטוחים מבחינת הגרסה עצמה אוקיי אז זה קריטריון כניסה וקריטריון יציאה שדיברתי על קריטריון יציאה שאנחנו מפסיקים לבדוק שיש איכות, שאין באגים קריטיים ושכיסינו את כל הטסטים שלנו וקריטריון כניסה זה שבאמת כל ה-unit
testing מבחינת בדיקות רכיב עברו בהצלחה. אוקיי? בתחום הזה של בדיקות שאנחנו קיבלנו גרסה יציבה או שהבדיקות רכיב עברו בהצלחה וה-smoke test עבר בהצלחה מבחינתנו זה יהיה תנאי כניסה לשלב הבדיקות.
אוקיי? Deliverable, איך אנחנו נבצע בעצם את ההעברה של הגרסה או העברה של המערכות לידיים של האנשים שיבדקו בדיקות אלפא או בדיקות בטא את המערכת ורשימה של סיכונים שיש בגרסה מבחינת צוות הבדיקות.
אז זה בעצם עונה על השאלה של התוכן של טסט פן וטסט קייסס. יש לנו פה שאלה שאומרת מה זה אג'ייל טסטינג. בעצם כשאנחנו מדברים על אג'ייל טסטינג אנחנו מדברים על זה שאנחנו בונים את הבדיקות בסביבה אג'ילית, בסביבה של פיתוח אג'ייל.
סביבה בפיתוח אג'ייל זו סביבה שהפיתוח נעשה בצורה אינטנסיבית יותר, באיתרציות קצרות. ולכן אנחנו נצטרך להתבסס הרבה על בדיקות אוטומטיות שיכסו את הרגרסיה בתהליך הפיתוח המהיר הזה.
אנחנו נצטרך לבצע בבדיקות מהירות על מנת לתת פידבק מהיר לאנשי פיתוח. הצוותים בדרך כלל היו צוותים של אינטגרציה בין אנשי בדיקות לצוותי פיתוח ואנחנו נרצה לענות כמה שיותר מהר על הדרישות של צוות המפתחים על מנת לשרת ולקדם את הפיתוח המהיר הפיתוח הגמיש הזה בצורה של אג'ייל אז מאפיינים של פיתוח בסביבת אג'ייל זה התבססות על אוטומציה מענה מהיר
לדרישות של צוות הפיתוח שינויים מהירים הבנה