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

יום רביעי, 18 בינואר 2012

בדיקות ביצועים

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


יום שני, 16 בינואר 2012

בדיקת פונקציונליות

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

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

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

איך ניתן לשלב בדיקות פונקציונליות במסמך בדיקות?

יום חמישי, 12 בינואר 2012

צילומי מסך - למה?

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

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

אז אילו כלים יכולים לעזור?

יום ראשון, 8 בינואר 2012

מהו תהליך פיתוח במודל V

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

מודל V הוא מודל שמעביר בצורה יפה את מורכבות ושלבי תהליך הפיתוח והתקדמות המוצר ומחזור החיים של התהליך.



ניתן להבין מהמודל מספר דברים:

  1. הבדיקה אינה חייבת להתחיל עם מסירת הקוד יכולה להתחיל עוד בשלב הגשת הדרישות.
  2. ניתן להפיק לקחים עוד בזמן כתיבת הקוד תוך כתיבת תסריטי בדיקה ובחינת הדרישות.
  3. הפקת לקחים ומדידת איכות יכולה להתבצע בכל שלב תוך התקדמות הפרויקט.
  4. ניתן להתקדם בכל שלב לשלב הבא לאחר סיומו ואישור ביצועו ואיכותו עם קריטריוני היציאה שהוגדרו.
  5. התהליך קל יותר לניהול ולקיחת ההחלטות בו קלה יותר כשמשוב האיכות בו מדורג ומפורט (מדורג) יותר.  
חשוב להבין שמודל זה עוזר להביא לעלויות פיתוח נמוכות בכ80% מהעלויות תיקונים זהים אם יבוצעו בסיומו של פיתוח המוצר. מוצר גמור שמועבר לבדיקה הינו בעל קוד מורכב יותר לאיתור סיבת הכשל, צורך זמן רב יותר לתיקון ובעל סיכון גבוה יותר לכשלים ורגרסיות בכל שינוי. 




יום ראשון, 1 בינואר 2012

תחילת הדרך בQA

מה זה QA?
ראשי התיבות של Quality Assurance, אבטחת איכות מוצר ותקינות. בשונה מבקרת איכות, תחום אבטחת איכות מטרתו להבטיח השקת מוצר באיכות גבוהה.

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

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

מה צריך להבין לפני שמתחילים:

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

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

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

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

QA אינו קשור לאפיון המוצר: טעות לחשוב שלQA אין חלק מהאפיון. לאחר מעבר על דרישות לקוח הארכיטקט ינסח ויעביר לכם מסמך אפיון, בחברה מסודרת תהיו נוכחים במעבר על מסמכי האפיון(DR (design review בנוכחות המפתח והארכיטקט. באמצעות מסמך האפיון נלמד את המוצר, נתכנן בדיקות, נבנה חזיון עבודה ואף נמצא בעיות/באגים בתכנון המוצר ברבדים שונים: ממשק משתמש, פונקיונאלי, אינטגרציה וכד'. 
חשוב! תיקון באג אפיוני הינו תיקון בעלות נמוכה בכ80% אחוז ויותר מעלות תיקון באג לאחר כתיבת הקוד, שלא נדבר על תיקון בסיום הפיתוח.