QA - בדיqות aיכות תוכנה ומה שמסביב

כשאני עובד על מכשירים ניידים אחד הדברים החשובים לי בזמן פתיחת באג זה תיעוד מלא הכולל צילום מסך. צילום מסך במכשירים ניידים לרב פעולה פשוטה של שני לחצנים אך לעתים מרגיז לחפש את הצרוף. יחד עם זאת, הצירוף גם תלוי ברום(OS) שצרוב על המכשיר אלא אם התקנתם תוסף. אז הכנתי לכם רשימה נוחה שבניתי למגוון מכשירים ניידים: Galaxy Tab GT-P1000 : לחיצה ארוכה על מקש חזור + לחיצה על לחצן הכיבוי והדלקה. צילום המסך נשלח לגלריה בתיקיה חדשה ששמה Screenshots.

כמה פעמים הייתם צריכים לחזור על אותו תסריט מס' פעמים? לא נמאס לכם לעבוד לא יעיל? לעתים יוצא לי לבצע בדיקות חוזרות (בדיקות web) לצרכים שונים כגון בדיקות אימות, בדיקות רגרסיה, בדיקות ביצועים ועוד. זכיתי להכיר תוכנה קלה לתפעול, נוחה להבנה והרצה בשם Selenium. התוכנה ניתנת להתקנה כתוסף של FF אך ניתנת להרצה גם בפלטפורמות אחרות (ההתנסות שלי נכון ליום כתיבה פרסום זה על גבי FF). התוכנה מאפשרת עריכה וייצוא למס' שפות קוד אך גם אם אין לכם ידע בשפת קוד ולא התנסיתם בפיתוח היא מאפשרת הרצה ואימות בצורה קלה, מהירה ויעילה מאוד. אז מה אפשר לעשות איתה ? הIDE הוא תוסף לדפדפן הFireFox המאפשר הרצת תסריטים באופן אוטומטי בבדיקות אתרים ע"י למידת האובייקטים במצויים באתר וכתיבת תסריט באופן קל נוח ומהיר. את התסריט אפשר לייצא בלחיצה פשוטה לקוד JAVA, PYTON ועוד מה שעושה את זה קל מאוד לייצור אוטומציה רחבה יותר למי שיש לו ידע בקוד.

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

לא בכל החברות הפרויקט מאפשר עבודה עם שרותי ענן. ישנם פרויקטים שמנהלים אפילו מעבדת שרתים המכילה עשרות ארונות (Recks). בפרויקט בו עבדתי היו ברשותי 2 מחשבים מקומיים ו4 שרתים במעבדה ולעתים היה עליי להתרוצץ בין הקומות. פרסום זה אני רוצה להקדיש להצגה של כלים לשליטה מרחוק שיעזרו לכם הן ברמה האישית והן ברמה המקצועית. כלים אלו יאפשרו לכם להשתלט על המחשב המרוחק או בעצם לעבוד על מספר מכונות/מחשבים/שרתים ממחשב אחד עקרי. חשוב! אם אתם מריצים בדיקות ביצועים או ביצועים גרפיים כלים אלו אינם מומלצים כי הם צורכים משאבים. אז הנה אנחנו מתחילים בזמינים ביותר לאלו שדורשים התקנה:

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

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

אחד הדברים הכי חובבניים באתר, מקצועי אשר יהיה, הם הקישורים השבורים. אני בטוח שאתם משלבים בדיקת תקינות קישורים בתסריטי הבדיקות שלכם בצורה יעילה אך כמה פעמים מצאתם קישור שבור לאחר תיקוני באגים או לאחר שינויים של הרגע האחרון? ישנם עשרות כלים ברשת אך הנה תוסף קטן לדפדפן כרום בשם Check My Links  שכל מטרתו היא למצוא קישורים שבורים בדף ולסמן אותם. לחיצה קטנה, המתנה קצרה ושיפרתם את איכותו של פרויקט הWeb שלכם. הורידו את ה תוסף הקטן מדף זה (או אחד דומה מהרשימה של הדומים) לחצו על התוסף בדף הרלוונטי והנה רשימת קשורים שבורים והשגיאה הנלוות להם. תיהנו :-)

כיצד לכתוב תוכנית בדיקות? מה נכון לעשות ומה לא נכון לעשות? למה יש הרבה שיטות והרבה רעיונות סותרים? הרעיון של פירוק לגורמים יוכל לעזור לכם לענות על הרבה שאלות שעולות בראשכם לפני תכנון תוכנית בדיקות. הרעיון יעזור לכם לגשת לתהליך כתיבת מסמך STD בקלות ובבהירות. יש הרבה שיטות, רעיונות ודעות כיצד לתכנן אך בסופו של דבר לכל אחד יש את הדרך שמתאימה לו. לפני הכל חשוב להבין את המטרה? כאשר מקבלים מערכת לבדיקה ולא רכיב (Unit testing) חשוב לנו להשיג כיסוי טוב ורוחבי בכדי לגעת בהרבה חלקים של המערכת ולהעמיק בדיקות בחלקים בעלי הסיכון הגבוהים יותר (סיכון כספי, סיכון תקינות עקב מבנה וכד'). פירוק לגורמים, למה? חברות גדולות דואגות להעביר לכם מסך אפיון, סכמות פיתוח וכד', השתמשו בהם כי זו התורה שלכם. בבדיקות חומרה זה שונה כמובן אך בכל בדיקה העיקרון זהה; אנחנו נחלק את המערכת לאזורי בדיקה, מרכיבים, גורמים מעורבים (רוחב רשת, סוג כרטיס מסך, מהירות כתיבה וכד') ונפרוס אותם בטבלה או רשימה וכך נקבל תמונה ראשונית ברורה ומסודרת יותר. שלב שני אנחנו נמנה את סוגי הבדיקה הנדרשים לנו בכל חלק, אזור או

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

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

השבוע נשאלתי לגבי אופן הזנת באגים וחשבתי שמעולם לא רשמתי על דבר זה בפורום שהינו מעוד בסיסי. אז הנה אני מתחיל.... בכל תהליך בדיקות תפגשו סוגים שונים ומגוונים של באגים ברמות שונות. כל באג או דפקט שנחשף בפניכם חשוב לתעד ממספר סיבות, ביניהן; היכולת להריץ בדיקות רגרסיה, מעקב תיקון באגים, סטטיסטיקות על איכות, עדכון אוטומטי לכל המעורבים בפרויקט, מיקוד בדיקות באזורים מרובי באגים ועוד. כל חברה ואופן העבודה וההרגלים שלה וביניהן סוג השרת והתוכנה בה משתמשים. בין אם אתם עובדים עם; Quality Center, OnTime2007, Synergy, Mircrosoft virtual Studio2010 או כל תוכנה אחרת, תיעוד הבאגים תמיד יהיה זהה במהותו ואני אתמקד במה חשוב לדעת ולא על אופן ההזנה הטכני (אותה תרכשו לרב במהלך החפיפה). נתחיל מההבנה שמדובר באנשים ולכן חשוב להיות כמה שיותר מפורט כדי להעביר את המסר למפתח (נסו להיות סובלניים אם המפתח מתלונן שאינו מבין את הבאג וזיכרו שאנחנו מעבירים ביקורות על עבודתו הקשה ולעתים הפניה היא ממקום אמוציונלי). אז אחרי שנגעתי בכל מה שמסביב נעבור לעיקר :

הרבה פעמים אני מוצא עצמי מחפש ברשת כלי בדיקה מתאים לצורך מסוים והפעם אני משתף עימכם כלי שימושי המאגד מגוון של כלי בדיקות שימושיים בממשק אחד. הרבה עצמה, נוחות וחסכון בזמן. הכירו את ה WSCC – כלי שפותח על ידי KLS-Soft בשיתוף   עם NirSoft המאגד מגוון רחב מאוד של כלי מערכת וניתור שימושיים בתחומים שונים; ניתור מערכת, ניתור רשת, ניתור תהליכים, ניתור חומרה ועוד. ניתן להוריד את התוכנה מ הקישור הזה או מ האתר הזה . בנוסף, מי שרוצה להרחיבו עוד ולהוסיף כלי עבודה כמו צילום מסך ואפליקציות נוספות יכול לשלבו עם זה: Portable Apps  והנה לכם  תיק עבודה יעיל, רחב, נוח וכולו בדיסק נייד ( DOK ) אחד.

מאתר www.globalnerdy.com אתם בטח מכירים את הבדיחה הנפוצה הזו (התמונה). אז מנקודת מבטי הבדיחה הזו היא כישלון ניהולי המוביל לכישלון מוצרי והיה שכיח מאוד בעבר. אחד הדברים החשובים ביותר בפרויקטים הינה האינטגרציה בין אנשי אבטחת האיכות (QA) לאנשי הפיתוח (R&D). נושא זה עלה בעבר יותר מבהווה והולך ונעלם מעולם הפיתוח. אנשי הQA לאט לאט מצאו את מקומם בהכרה של המעורבים בפרויקטים בארץ אך עדיין ניתן להיחשף למקרים בודדים המציפים קושי בעבודה בין אנשי QA לאנשי פיתוח.

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

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

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

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

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

עובדים על פרויקטים המכילים הרבה UI?! במטרה למנוע החזרת באגים לQA בסטטוס "זקוק למידע נוסף" או בעקבות אי הצלחת הפיתוח לשחזרם תמצאו שכתיבה מסודרת ושימוש בצילומי מסך יורידו את המקרים ב80% או יותר (סתם מספר שזרקתי כדי להעביר את המסר) כי תמונה שווה אלף מילים. באפליקציות WEB, עבודה עם ניידים ואפליקציות למשתמש הקצה (CLIENT) אני מוצא את השימוש בצילומי מסך חלק בלתי נפרד מתיעוד באג. תופתעו לגלות שהקלטת המסך תוך כדי הרצת בדיקות תעזור נפלאות למצוא באגים שלא היו קשורים לתסריט שלכם ואינכם מצליחים לשחזרם. אז אילו כלים יכולים לעזור?

ניהול תהליך הבדיקה הינו מורכז ומכיל פרטים רבים בתהליך כגון; הבנת התהליך, מהירות תגובה, מסירת משוב מסודר ומפורט לצוות הפיתוח, בניית סקריפטים לאוטומציה, כתיבת מסמך בדיקות מסודר לייעול העבודה וכד'. מרשימה זו אפשר להבין כי תהליך ניהול העצמי עוסק בשליטה מלאה ובמבט הרחב על המטרה והמוצר. מודל V הוא מודל שמעביר בצורה יפה את מורכבות ושלבי תהליך הפיתוח והתקדמות המוצר ומחזור החיים של התהליך. ניתן להבין מהמודל מספר דברים: הבדיקה אינה חייבת להתחיל עם מסירת הקוד יכולה להתחיל עוד בשלב הגשת הדרישות. ניתן להפיק לקחים עוד בזמן כתיבת הקוד תוך כתיבת תסריטי בדיקה ובחינת הדרישות. הפקת לקחים ומדידת איכות יכולה להתבצע בכל שלב תוך התקדמות הפרויקט. ניתן להתקדם בכל שלב לשלב הבא לאחר סיומו ואישור ביצועו ואיכותו עם קריטריוני היציאה שהוגדרו. התהליך קל יותר לניהול ולקיחת ההחלטות בו קלה יותר כשמשוב האיכות בו מדורג ומפורט (מדורג) יותר.   חשוב להבין שמודל זה עוזר להביא לעלויות פיתוח נמוכות בכ80% מהעלויות תיקונים זהים אם יבוצעו בסיומו של פיתוח המוצר. מוצר גמור שמועבר לבדיקה הינו בעל קוד מורכב יותר