קיואיי -QA

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

עמוד זה מתאר את תהליכי ה- QA (בדיקות תכנה) בסדנא לידע ציבורי.

מהו QA

ה- QA הוא שלב ביניים בין פיתוח ראשוני של תכנה לשחרורה למשתמשים מחוץ לסביבת הפיתוח. ה- QA הוא תהליך שיטתי מתמשך המלווה את הפיתוח במעבר בין הגרסאות השונות, לכן בדיקות QA מבוססות על תרחישים (scenarios) הניתנים לשחזור, אותם בונה הבודק/ת בהתאם לאפיון של התכנה הנבדקת.

  • QA ידני - הבודק/ת מדמה תרחיש אמיתי שסביר שהמשתמש הבודד יעשה.
  • אוטומציה - רצף של תהליכים קבועים מראש שאפשר לכתוב לתוך סקריפט ולהריץ בעת הצורך. שימושי בעיקר לבדיקות עומסים ולבדיקות שלא דורשות שיקול דעת של משתמש. מומלץ לכתוב ולהריץ כחלק מתהליך הפיתוח השוטף, ולבדוק שהקוד לא נשבר בין גרסאות.

מטרת ה-QA

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

מה עושה איש/אשת QA?

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

  • סוגי בעיות
    • בעיות פונקציונליות - האתר לא עושה מה שהוא אמור לעשות.
למשל: בחרתי להציג את נתוני התקציב של שנת 2000 וקיבלתי את הנתונים של 1999 במקום; 
לחצתי submit והאתר לא עולה יותר; קיבלתי שגיאה בעקבות פעולה מסויימת; 
יש כפתור שלא עושה כלום וכו'. 

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

    • בעיות ביצועים ועומסים - האתר עובד לאט מדי או לא עומד בעומס של כמות משתמשים גדולה. בדיקות מסוג זה ייעשו לרוב באוטומציה.
    • בעיות שמישות (יוזביליות) - האתר לא נוח לשימוש או לא מאפשר שימוש בו.
למשל: האתר דורש ממני log in אבל לא מאפשר לי sign in; 
הכפתור הזה קטן/גדול מדי או לא נמצא במקום שנוח לי להשתמש בו; 
האתר לא מוצג טוב בדפדפן מסויים.

איך כותבים תרחיש (ידני)?

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

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

מומלץ לפתוח קובץ ]google spreadsheet ולנהל בו את רשימת התרחישים. חשוב שהתרחישים יהיו ברורים לקוראים חיצוניים (בודקים נוספים, מפתחים, וכו'). בתרחיש צריך לציין את:

  • הפעולה שאני עושה
  • מה סביבת העבודה שלי
  • מה אני מצפה שיקרה בעקבות הפעולה.

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

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

למשל: היכנסו לאתר באמצעות שלושה דפדפנים שונים (IExplorer, Firerox, Chrome) 
ובדקו שהאתר נראה טוב בכל אחד מהם. מומלץ להיעזר במוביל הטכנולוגי כדי להבין 
אילו תרחישים עלולים להציף קשיים או תקלות.

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

איך כותבים תרחיש (אוטומטי)?

תרחישים הדורשים אוטומציה יכולים להיות: 1000 כניסות בו"ז, תרחישים נוספים הדורשים סימולציה של אותה פעולה על ידי משתמשים רבים; דוגמאות ייכתבו בהמשך (מוזמנים להוסיף משלכם)

איך פותחים באג?

פותחים חשבון ב- Github [1] (פשוט כמו לפתוח חשבון בכל אתר אחר) ונכנסים לעמוד של הפרוייקט אותו אתם בודקים. ה- Github הוא אתר מורכב, אבל לצורך הבדיקות נשתמש רק בחלק אחד שלו, ה- Issues (בעיות).

כך תפתחו Issue חדש

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

  • מה צריך להיות כתוב בהודעה על Issue?
    • Title - טקסט תמציתי שמתאר את הבעיה בדרך של סיבה ותוצאה. למשל: כשלוחצים על "בקשה חדשה" מקבלים שגיאה
    • Description - טקסט שמתאר את הבעיה בדרך של פתרון מצוי ופתרון רצוי. למשל: נכנסתי לעמוד הראשי של האתר ולחצתי על כפתור "בקשה חדשה". הכפתור הזה אמור להוביל אותי למסך שיאפשר לי להכניס פרטים של בקשת חופש מידע חדשה אבל במקום זה קיבלתי שגיאה. על המסך היה כתוב "Sorry the page was not found".
    • Reproduction info - טקסט שמתאר את סביבת העבודה שלכם ואת השלבים שעברתם כדי לגלות את הבעיה. למשל: יש לי מערכת הפעלה Windows Vista ואני גולש עם דפדפן IExplorer 8.0. כדי לשחזר את הבעיה לחצו על כפתור "בקשה חדשה" בעמוד הראשי.
    • Sevirity: רמת החומרה נועדה לעזור למפתחים לסווג את הבאגים שהם מקבלים ולהבין במה חשוב לטפל קודם.
  • איך קובעים חומרה (severity)? כדי להימנע ממצב שבו כולם בוחרים באופן שרירותי והתיעדוף מתייתר, מומלץ להשתמש בכללים אלה:
    • blocker - בעקבות הבדיקה מצאתי בעיה שמונעת ממני להמשיך להשתמש באתר (כל האתר קרס/נתקע). מעט מאוד באגים יהיו כאלה.
    • high - בעקבות הבדיקה מצאתי בעיה שמונעת ממני להמשיך לבדוק מה שבדקתי (חלק מהאתר לא עובד אבל אפשר להמשיך לבדוק חלקים אחרים). פחות באגים יהיו כאלה בשלבים מתקדמים של פיתוח.
    • medium - בעקבות הבדיקה מצאתי בעיה שאפשר לעקוף (צריך ללחוץ פעמיים על כפתור כדי שהוא יעשה את הפעולה שאני מצפה שיעשה)
    • low - בעקבות הבדיקה מצאתי בעיה שחשוב שתטופל אבל היא לא מפריעה לי להמשיך לבדוק את האתר

המלצות לטיפול בבאגים (למפתחים)

  • סווגו את הבאגים לפי עדיפות: critical/high/medium/low.
  • התחשבו בשלב הפיתוח ובקרבה ל launch. באג usability שהייתם מתעדפים יחסית נמוך בשלבי פיתוח התחלתיים עולה בעדיפות ככל שמתקרבים לשלב שבו משתמשים אמיתיים אמורים להשתמש באתר. זה השלב שבו באגים על מיקומים של כפתורים מוקפצים בעדיפות.