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

נכון, רשמתי כבר פרסום אחד בנושא ורציתי לשתף אתכם בכלי נוסף, שמצאתי בתחום, הכלי מיועד לבדיקות דפדפנים ניידים. מה שונה ממה שנתתי קודם ? הפרסום הקודם היה כללי ומציג מגוון רחב של פתרונות לניידים לעומת כלי זה שהוא מתמקד במיוחד באופן הצגת האתרים (rander). שם הכלי : Keynote MITE הפתרון : תוכנה להתקנה מקומית. רישיון : חינמי עם אפשרות הרחבה הכוללת תמיכה. סביבת עבודה : חלונות.

לאחרונה אני מריץ הרבה בדיקות בחומרות ניידות ומצאתי כלי נחמד נוח לשימוש ברב המקרים וחשבתי לשתף אתכם. ShareKM - Share Keyboard & Mouse : האפליקציה הזו מאפשרת שיתוף עכבר ומקלדת בין מכשיר אדרואיד ומחשב שולחני בסביבת חלונות, כן, חלונות :-). אני מוצא את הכלי זה נוח ויעיל ברב המקרים אז לכל המעוניין... תיהנו! יתרונות: נוחות שימוש מקלדת + עכבר. אפשרות הכנסת קיצורי מקשים למכשיר הנייד. שימוש בלוח גזירים בין המכשיר למחשב (Clipbaord). שימוש באמצעות כבל, WIFI וBluetooth. 

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

בדיקות על גבי מכשירים ניידים הינו עולם ומלואו. כל מה שהכרתם בתחום אבטחת האיכות נכנס לעולם שלם של בדיקות ניידים. כמות הפלטפורמות השונות גדולה מאוד ומערכות ההפעלה כהיום מתחלקות לשלושת המתחרות העיקריות בשוק (IOS, Android, Blackberry) ובדרכן להפצה עוד שתיים מתחרות חזקות (Ubuntu וMicrosoft) להוציא מערכות נוספות. בנוסף הפלטפורמות מגיעות במגוון רזולוציות', עם הדפדפנים המוכרים לנו בגרסה הניידת שלהם ואחסון חיצוני ופנימי. כעת לאחר שרפרפנו במגוון הרחב ובשילובים הקיימים אפשר להתקדם  לשלב החשוב ביותר בבדיקות וזו הגישה, התכנון, האסטרטגיה, המטרות וכד'. חשוב להבין שאבטחת איכות על גבי מכשירים ניידים אינה שונה בתפיסתה מאבטחת איכות בדיקות אחרות הכל המקרים אנחנו נבחן את הצרכים, הדרישות והמטרות ונעבוד להתאם להן. אז מה כן חשוב לדעת?...

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

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

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

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

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

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

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

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

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

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