מהן סוגי הבדיקות ב - QA

בפוסט הזה אני אסביר מה הבדיקות שמבצעים בודקי התוכנה. לפני שאני אסביר מה הבדיקות, נסביר מה זה בדיקות תוכנה בכלל ולמה אנחנו צריכים בודקי תוכנה. נתחיל מההתחלה.

אז מה זה בדיקות תוכנה בכלל?

בפשטות, בדיקות תוכנה הוא תהליך שבמהלכו בודקי תוכנה מוודאים שהמוצר עובד בהתאם לדרישות – לפני שהוא מגיע למשתמשים.

הדרך הטובה ביותר לוודא שהמוצר שלכם מוכן להגיע למשתמשים היא להתנהג כמו משתמש היעד. זה יכול להיות תהליך מילוי טופס יצירת קשר ובדיקה שאין בו טעויות או אולי להוסיף יישום של לייב צ'ט לאתר ובדיקה שלכם לפני שמוסיפים את היישום לאתר באופן קבוע. במיוחד כשיש הרבה דברים שמשתנים, לדוגמא באתר קניות, שינוי קטן בקוד יכול לייצר שינוי לא רצוי במקום לא מתוכן. בודקים מוצאים ומדווחים על בעיות אלה.

למה אנחנו צריכים בדיקות תוכנה?

בתעשיות רבות יש בודקי איכות מקצועיים והתחום הטכנולוגי לא שונה מהן. חקלאים חייבים לוודא שהמוצר שהם מוכרים הוא בטוח לאכילה. יצרנים נבונים מוודאים שהמוצר שלהם מתנהג כמו שהם הבטיחו כשהם שיווקו את המוצר, איך הם עושים את זה? כמובן על ידי בדיקות חוזרות של המוצר. לכן, בודקי תוכנה הם לעיתים קרובות הקו האחרון בין מחלקת פיתוח לבין המשתמשים. 

מהן הבדיקות שמבצעים בודקי תוכנה?

בדיקות פונקציונליות (Testing  Functional)  

לאימות פעילות המערכת. בדיקות אלו מבוססות על מסמך הדרישות ומסמך האפיון ומטרתן לבדוק כי המערכת עושה את מה שהיא צריכה ולא עושה את מה שאינה צריכה לעשות (valid and invalid testing)

בדיקות ממשק לקוח (Testing GUI) 

 בדיקות הפקדים והשדות במסך. התנהגות תקינה, פורמט של שדות, בהתאם לחוקיות המוגדרת ברמת המסך ולא הלוגיקה העסקית. לדוגמה: בדיקת מינימום ומקסימום תווים בשדה.

בדיקות ביצועים (Testing Performance) 

 בדיקה שהמערכת יודעת להתמודד עם אתגרים ביצועיים בזמן שהוגדר (כמות משתמשים קיצונים, זמן תגובה, זמן טעינה, התמודדות עם כשלים).

בדיקות שפיות (Testing Sanity) 

 בדיקות בסיסיות המאפשרות לזהות במהירות וביעילות אם הפונקציונליות הבסיסית של המוצר פועלת כנדרש, והמוצר במצב יציב.

בדיקות אבטחת מידע (Testing Security) 

 בדיקת המערכת מתוך מטרה לאתר כשלים במערך ההגנה על המידע במערכת: בדיקת מערך ההרשאות והמידור, בדיקת סיסמאות - מבנה ותוקף ובדיקות חדירה.

בדיקות אינטגרציה (Testing Integration) 

 בדיקת שילוב יחידות תוכנה בהיקפים שונים, החל משתי יחידות ועד לכלל היחידות במערכת.

בדיקות מערכת (Testing System) 

 בדיקות המערכת בכללותה, בדרך כלל בראיית המשתמש של יכולות המערכת.

בדיקות קבלה (Testing Acceptance) 

בדיקות הנעשות על ידי המשתמש או הלקוח במטרה לוודא כי המערכת פועלת בהתאם לדרישות שהוגדרו במסמך הדרישות המקורי ובשינויי דרישה (change request) שהועברו במהלך מחזור חיי הפיתוח.

בדיקות שימושיות (Testing Usability) 

 בדיקות נוחות השימוש לכולם ויעילותה עיצוב של האפליקציה ונגישות לבעלי מוגבלויות. לדוגמה: נוחות השימוש בתפריטים, ניווט נוח והתמצאות באתר.

בדיקות התקנה Installation Testing))

 בדיקת תהליך התקנת המערכת בסביבת הייצור ובדיקת התקנת מערכות צד שלישי.

בדיקות התאמה (Testing (Compatibility 

בדיקה שהמערכת מתאימה לכל סוגי המשתמשים, כולל מערכות אחרות שמשתמשות במערכת (בדיקות התאמה למכשירים, רזולוציות, מערכות הפעלה, דפדפנים..)

בדיקות רגרסיה (Regression Testing) 

בדיקת המערכת כולה לאחר שינוי בכל מודול שלה או בפונקציונאליות. קשה לכסות את הבדיקות לכן משתמשים בבדיקות אוטומטיות עבור בדיקות אלה, אם הן אפשריות.

זוהי רשימה חלקית של סוגי הבדיקות השכיחות ביותר. אם אתם בודקים חדשים, אני ממליץ להתעמק יותר בבדיקות, להכיר אותן לעומק ולחשוב איך הייתם מיישמים את הבדיקות האלה על מוצר כלשהו בזמן שנוח לכם. בהצלחה.

טיפים לכתיבת קורות החיים בתחום בדיקות תוכנה

איך לכתוב את דגם קורות החיים הטוב ביותר עבור בדיקות תוכנה?

אני מוצא דגימות קורות חיים רבות הנשלחות אליי כשאני מנסה לראיין עבור משרות בדיקות תוכנה בארגון שלי. רוב קורות החיים נדחים רק מלהסתכל עליהם במשך כמה שניות. ברוב הפעמים זה מפני שהם לא משתמשים בתבנית קורות החיים טובה לבדיקות תוכנה. אז אני מציג את 10 הטיפים המובילים שלי עבור תבנית קורות חיים מצוינת לבדיקות תוכנה . הנה:

1.     אל תכתבו את המילים 'קורות חיים', 'קו"ח' וכו 'על גבי קורות החיים. במקום כתבו את השם שלכם באותיות מודגשות. אתם יכולים לכלול את מספר הנייד שלכם וכתובת המייל שלכם ליצירת קשר.

2.     מחק את מטרת הקריירה שהעתקת מקורות החיים של החבר שלך. שאל את עצמך - מי לא רוצה לעבוד בחברת מכוונת צמיחה שבו הוא או היא יכולים לנצל את כישוריו או כישוריה במלואם? מטרת קריירה היא פשוט בזבוז של מקום בדף ותאמינו לי, אף אחד לא קורא את החלק הזה.

3.     כללו סיכום בשתי שורות על הניסיון שלכם, הכישורים שלכם, הכלים וכו', כך האדם שקורא את קורות החיים שלכם יכול לדעת על הפרופיל שלכם ב-10 שניות.

4.     הסירו את כל המידע המיותר כמו שם האב, תחביבים, מקום לידה, מידע על בתי ספר וכו'. יהיה לכם מספיק זמן כדי לספק את המידע הזה כאשר תיבחרו.

5.     בנו את תוכן קורות החיים בהתבסס על ניסיון העבר שלכם כגון כישורים, כלי אוטומציה, תחומים וכו'.

6.     הדגישו מיומנויות חשובות שלכם ותחום מומחיות. דברו על איך תוכלו להוסיף ערך לארגון שמגייס אותכם.

7.     מטרת קורות החיים היא ליצור מספיק עניין בכם כדי לגרום למעסיק פוטנציאלי לזמן אתכם לראיון. אין למלא את קורות החיים עם יותר מדי מידע. אף אחד לא ייקרא קורות חיים של יותר מ-2 דפים מקסימום.

8.     השתמשו בנקודות כדי לרשום מידע. הפכו את המידע זמין ונגיש למגייס. אבל היו בטוחים שכל מה שכתבתם בקורות החיים, תוכלו גם להסביר.

9.     השתמשו בגופן אחד לכל אורך קורות החיים (Garamond , 12pt- האהוב עלי). אל תשתמשו יותר מדי בקו תחתון, פונט מודגש וטקסט מובלט בתבנית קורות החיים לבדיקות תוכנה.

10. תנו את קורות החיים שלכם לחבר או מומחה שייבדקו אותם. קבלו משוב ושפרו את קורות החיים. השתמשו בתבנית טובה המתאימה לתחום שלכם ועדכנו את קורות החיים שלכם לעתים קרובות.

טיפ בונוס

 חפשו באינטרנט מילות מפתח כגון תבנית קורות חיים טובים, דוגמה לתבנית קורות החיים לבדיקות, קורות חיים בדיקות תוכנה, אתם יכולים גם לחפש לפי מילת המפתח שלהלן ב- Google filetype: docx קורות חיים בדיקות תוכנה או קורות חיים QA. אתם תקבלו מאות דוגמאות לקורות חיים לבדיקות תוכנה מ- Google.

קורות חיים הם הרושם הראשוני שלכם על המגייס ויש לכם רק כ-10 שניות כדי להרשים מגייס. תאמינו לי שאף אחד לא מעיין בקורות החיים שלכם במשך יותר מ -10 שניות. אז זה מאוד חשוב שתדגישו את הכישורים המיוחדים שלכם בקורות החיים לבדיקות תוכנה שלכם. בחרו בתבנית קורות חיים לבדיקות תוכנה טובה והמשיכו לשנות אותה עד שהיא תהפוך לדוגמה טובה לקורות חיים. אם יש לכם כמה שאלות על תבנית קורות החיים לבדיקות תוכנה יידעו אותי על ידי תגובה בפוסט הזה.

לקריאה על קורס QA שמכללת qaexperts מציעה הקליקו כאן

טיפים לכתיבת תסריטי בדיקות

אנחנו יודעים שכתיבת מקרי מבחן (Test Cases) טובים זה אחד מהפעילויות העיקריות מתהליך ההכנה לבדיקות. לפעמים יכול להיות קשה להחליט איפה להתחיל, לכן, במאמר הזה ניתן לכם כמה טיפים שימושיים על איך ליצור Test Cases.

מה זה Test case?

“A test case is a set of conditions or variables under which a tester determines whether a system under test satisfies requirements and works correctly.”

בעיקרון טסט קייס זה סט של צעדים ותנאים שבודק תוכנה צריך ללעקוב אחריהם בשביל לבצע את הבדיקה. הבודק צריך לעקוב אחרי ההוראות של ה- test caseבכדי להעריך התנהגות נכונה/פונקציונאליות של כל אפליקציה.

כתיבת טסט קייסים זאת יכולת נרכשת ותרכשו אותה רק אם תתרגלו ותעמיקו את ההיכרות שלכם עם המוצר שאתם בודקים.

מה היתרון של test cases?

·         בלי תסריטי בדיקות קשה לוודא איך ומה באפליקציה נבדק קודם. אין שום הבטחה שהאפליקציה תיבדק באותו אופן בפעם הבאה.

·         בלי טסט קייסים פורמליים, יקרו יותר טעויות בבדיקות ובאגים קריטיים עלולים לא להתגלות מאוחר מידי.

·         במהלך ההכנות לקראת כתיבת טסט קייסים, אנליסט צריך לקבוע מה המידע שיבדק, התנאים ומי הבודק שיבצע את הבדיקות. ההכנות לטסט קייסים למעשה קובעות מראש שכל התרחישים האפשריים נבדקים (ורק פעם אחת). לאחר מכן הבודקים מבצעים את השלבים שכתובים בטסט קייסים ומשווים את התוצאות בפועל מול התוצאות הצפויות (actual result VS expected result)

איך לגרום לתסריטי בדיקות להיות מעולים?

·         תכתבו טסט קייסים פשוטים- ההוראות לביצוע צריכות להיות פשוטות ומחולקות לשלבים. תהיו ישירים כשאתם כותבים טסט קייסים. לדוגמא: תזין סיסמא, תלחץ על...

·         תתמקדו במטרה אחת- תבדקו רק פונקציונאליות אחת בכל בדיקה. אם תנסו לבדוק מספר תנאים בבידקה אחת יהיה קשה מאוד לעקוב אחרי התוצאות והטעויות.

·         תהיו מדויקים- אל תניחו ששום פונקציונאליות מתרחשת, תכתבו בהתאם למסמך אפיון.

·         תמיד תעבדו לפי כללים קבועים- תסדרו את הטסט קייסים באופן עקבי. תשמשו באותו דפוס כשאתם מארגנים את הבדיקות. זה מקל על הבדיקה של הבודקים שיבדקו אחריכם.

·         הבדיקות צריכות להיות קצרות- אם הטסט קייסים הן רשימה ארוכה של שלבים וקוראת טעות, המפתח יצטרך לחזור לשחזר את כל השלבים. אם יהיו יותר מידי שלבים, זה חיסרון גם עבור הבודקים בגלל שהבודקים צריכים לבצע את כל השלבים בשביל לוודא שהטעות אכן תוקנה.

·         תעשו שימוש חוזר במה שהכנתם- תזכרו שניתן להשתמש מספר פעמים בטסט קייס טוב בפרויקטים/צוותים אחרים. זה יחסוך לכם הרבה זמן!

·         ביקורת- תשלחו את הגרסה הסופית של הטסט קייס לקולגות שלכם ותעשו ישיבת צוות שבה כל אחד מחברי הצוות ששייך לפרוייקט יציע הצעות וישתף בדעה שלו. אנשים שונים מסתכלים על אותו הבעיה בצורה שונה.

·         חשוב מאוד לעדכן את הטסטים שכתבתם כל הזמן ולוודא שהשינויים במוצר מעודכנים בטסט קייסים שכתבתם כבר.

לכתוב טסט קייסים אפקטיביים עם כל המידע הרלוונטי זאת מטלה זאת מטלה חשובה. כל עוד אתם חושבים על משתמשי הקצה, יודעים מה עושה האפליקציה שבודקים מקצה לקצה ומיישימים את הטיפים שציינתי, אתם תסתדרו!

עכשיו כשאתם יודעים איך לכתוב טסט קייסים, תחזרו לשלב התכנון, תפרקו את האפליקציה

לקומפוננטות ותייצרו את הטסטים הכי טובים שאתם יכולים שיענו על כל התרחישי השימוש

האפשריים.

מאמר מאת מכללת qaexperts
/http://www.qaexperts.co.il