"התלות שלנו כיום בטכנולוגיות היא כמעט בלתי נתפסת", מסביר קובי יונסי, מומחה ויועץ בתחום בדיקות התוכנה QA מזה כ־20 שנה, ומייסד המרכז ללימודי QA המעביר קורסים להכשרת אנשי מקצוע בענף. "לצד זה, לקוחות הקצה מצפים שהמוצרים יעמדו ברף תפקוד ותקינות גבוה, כשמותג שלא מספק את הסחורה הזו, יוצא מהמשחק. זו הסיבה שהדרישה לבודקי תוכנה היא עצומה". על רקע המגמה הזו ובעקבות הניסיון הרב שלו בעבודה עם חברות הייטק והדרישות הגבוהות שלהם מבודקי QA ייסד קובי את המרכז המוביל ללימודי QA וקורס לימודי QA בהנחייתו, ומכוון לאנשים חסרי רקע בתחום או בעלי רקע מועט בלבד, כשהוא מציע הכשרה מעמיקה – תיאורטית ופרקטית, המאפשרת להם להשתלב כבודקי תוכנה בארגונים, בפרויקטים או בצוותי עבודה בתעשייה. חלק מבוגרי הקורס מועסקים כיום במגוון חברות מובילות במשק, בהן Ness, Moovit, פיליפס, אלטשולר שחם, עיריית ירושלים, בנק פועלים, בנק מזרחי טפחות, Intel, אלביט, צ'ק פוינט ועוד.

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

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

ראש החץ בהובלת ההכשרה

קובי יונסי מדגיש את החשיבות של חיבור הקורס לתעשייה עצמה: "הענף הטכנולוגי חווה עדכונים מסביב לשעון, ובודק תוכנה שהידע שברשותו לא רלוונטי, לפחות ממחצית השנה האחרונה, יהיה לא רלוונטי בעצמו". יונסי הוא המרצה הבלעדי בהכשרת בדיקת התוכנה ומסביר שהתכנים שלו נלמדים במוסדות אקדמאיים כמו הטכניון והמכללה להנדסה, ושהוא מרצה הבית בחברות הבדיקה המובילות במשק כמו SQLINK, Ness ו־Qualitest. הוא גם מנהל את בדיקות התוכנה בעיריית ירושלים, ומשמש כיועץ בכיר בלשכה המרכזית לסטטיסטיקה, כותב טור אישי למגזין "עולם הבדיקות" ומנהל את התוכן בפודקסט TestIL – שני ערוצים שייסדה העמותה הישראלית להסמכת בודקי תוכנה ITCB, שבה משמש יונסי כאחד היועצים. בנוסף, בקרוב יושק מרכז המצוינות בתחום בדיקות התוכנה בלשכה לטכנולוגיות מידע בישראל, בו הוא עתיד לשמש כיו"ר.

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

היצע מול ביקוש

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

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

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

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

The post פניית פרסה לענף ההייטק: קורס בודקי תוכנה appeared first on ICS-המרכז הארצי ללימודים.

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

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

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

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

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

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

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

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

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

The post העתיד של בדיקות QA בעולם הבינה המלאכותית appeared first on ICS-המרכז הארצי ללימודים.

איך בדיקות תוכנה קשורות ל Ecommerce?

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

חווית משתמש וביצועים לפני הכל

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

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

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

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

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

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

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

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

The post בדיקות תוכנה בעולם ה E-commerce appeared first on ICS-המרכז הארצי ללימודים.

מיתוס 1: "אם אין באגים, אין צורך בבדיקות QA"

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

מיתוס 2: "בדיקות QA מעקבות את שחרור המוצר"

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

מיתוס 3: "תהליך QA הוא השלב האחרון לפני שחרור המוצר"

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

מיתוס 4: "כולם יכולים לעשות QA לבד"

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

מיתוס 5: "בדיקות אוטומטיות יכולות להחליף את הבדיקות הידניות."

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

מיתוס 6: "בפרויקטים קטנים אין צורך בבדיקות QA."

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

מיתוס 7: "בדיקות QA זה יקר מדי."

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

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

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

The post מיתוסים נפוצים בעולם בדיקות התוכנה appeared first on ICS-המרכז הארצי ללימודים.

The post ללמוד ולעבוד בסייבר מכל מקום ובכל זמן appeared first on ICS-המרכז הארצי ללימודים.

The post לעבוד בסייבר ולהגן על עסקים ותשתיות ישראליים appeared first on ICS-המרכז הארצי ללימודים.

במאמר זה נסביר מה הוא ההבדל בין קריטריון כניסה ליציאה.

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

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

ההבדלים בין הקריטריונים

קריטריון כניסה:

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

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

הנחת המוצא היא שלא נתחיל בבדיקות לתוכנה שאינה יציבה או שלא הגיעה אלינו ברמה מספקת בכדי להתחיל להריץ בדיקות שהכנו מראש.

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

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

קריטריונים אפשריים שיכולים לשמש אותנו להחלטה אם להתחיל או לא:

• זמינות של סביבת הבדיקות
• זמינות של הכלים איתם נבצע בדיקות

(למשל אם הושגו הרישיונות הנדרשים)

• זמינות של נתוני הבדיקות
• זמינות של פריטי מידע שעמדו בקריטריון היציאה
• זמינות של דרישות אשר ניתנות לבדיקה

קריטריוני כניסה יכולים גם להיות מחוץ לעולמות התוכנה כמו למשל:

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

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

דוגמא ממשית לקריטריון כניסה:

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

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

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

קריטריון יציאה:

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

אנו נפגוש את הקריטריון במסמך תכנון הבדיקות (STP) וגם במסמך סיכום הבדיקות (STR) שבו נוכל לגלות אם עמדנו או לא עמדנו בקריטריון המבוקש.

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

כללים לקביעת קריטריון יציאה:

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

קריטריונים אפשריים שיכולים לשמש אותנו להחלטה מתי ניתן להפסיק:

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

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

בסופו של יום תמיד יתקיים המתח בין אנשי המוצר שמבקשים להרוויח זמן כאשר מה שמניע אותם הוא : Time to the market

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

דוגמא ממשית לקריטריון יציאה:

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

מסך הבדיקות שבוצעו:

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

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

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

• יש לכתוב קוד שמכסה את כל דרישות הלקוח
• הקוד חייב לעמוד בסטנדרטים מקצועיים (הערות מצורפות למשל)
• כל יחידת קוד עברה בדיקות קופסה לבנה (הצהרה או החלטה למשל)
• כל קוד שנכתב נבדק על יד חבר צוות נוסף בסקירת עמיתים (Peer Review)

קריטריוני יציאה אפשריים עבור פגישות עבודה או סקירות:

• הפגישה הסתיימה לאחר שלא נותרו נושאים פתוחים מאחור.
• הפגישה מתועדת בפרוטוקול מסודר על ידי אחד מהמשתתפים (סוקרים).
• ההחלטות שהתקבלו בפגישה עובדו מחדש (Rework) והתקיים מעקב (Follow Up) שנועד לוודא שהשינויים מומשו.

קריטריוני יציאה אפשריים עבור סבב בדיקות או ספרינט:

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

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

• כל הבדיקות נכתבו ותועדו במערכת ניהול הבדיקות.
• כל הבדיקות עברו סקירה על ידי חברי הצוות שמסרו משוב לגביהם.
• הבדיקות הורצו ותקלות שנפתחו מקושרים לכל סיפור משתמש בנפרד.

קריטריוני יציאה אפשריים עבור בניית תשתית אוטומציה:

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

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

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

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

מדדים שנוגעים בהתקדמות העבודה מול לוחות הזמנים כמו:

• אחוז הבדיקות שהורצו מול הבדיקות שנכתבו
• אחוז העבודה שבוצעה ביחס להכנת סביבת הבדיקות
• מקרי הבדיקה שעברו בהצלחה מול אלו שנכשלו
• עלות הבדיקות ביחס להשוואה של עלות מול תועלת התקלות שנמצאו

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

לסיכום

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

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

בדרך לשם נזכור שכללי הברזל יהיו:

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

יש נושאים ומושגים נוספים שהייתם רוצים לקרוא עליהם? תשלחו מייל ואשמח לכתובkobi757@gmail.com

The post האנציקלופדיה לבדיקות appeared first on ICS-המרכז הארצי ללימודים.

אתגרים של עבודת QA מרחוק:

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

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

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

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

שיטות עבודה מומלצות לשיתוף פעולה אפקטיבי של QA מרחוק:

השקיעו בכלים הנכונים: כלים כמו Slack, Jira ו-Zoom הפכו לחבל ההצלה של צוותים שעובדים באופן היברידי. עבור אנשי מקצוע בתחום ה-QA, מינוף כלים לניהול בדיקות המאפשרים מעקב, שיתוף פעולה ודיווח בזמן אמת הוא חיוני. פתרונות מבוססי ענן, כגון TestRail או Qase, יכולים לשפר את הנגישות ושיתוף הפעולה.

הקפד על רענון ולמידה: עבודה מרחוק יכולה לפעמים להגביל את יכולות הלמידה במהלך העבודה. השתמש בפלטפורמות כמו Coursera, Udemy או LinkedIn Learning כדי להבטיח שהידע שלך יישאר מעודכן עם החידושים האחרונים בטכנולוגיה. כמו כן ניתן גם לקחת קורס QA פרונטלי או קורס QA אונליין כדי להעשיר את הידע שלכם בדברים חדשים.

אבטחת מידע: השתמש ב-VPN, בכלי תקשורת מוצפנים ופתרונות אחסון ענן מאובטחים. למד בקביעות על החשיבות של אבטחת נתונים ושיטות עבודה מומלצות באופן היברידי, כגון אי שימוש ב-Wi-Fi ציבורי למשימות הקשורות לעבודה וכ'ו.

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

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

לחבק את העתיד:

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

The post QA בעולם ההיברידי: עבודה מרחוק appeared first on ICS-המרכז הארצי ללימודים.

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

אלו הקריטריונים שיעזרו לכם לבחור קורס בדיקות תוכנה שיתאים לכם אישית:

1. החשיבות בבחירת מרצה בעל ניסיון מוכח של לימודי QA

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

2. תוכנית הלימודים: התאמה לדרישות השוק המקצועי

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

3. התמקדות בפרקטיקה: יישום הידע במציאות

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

4.התמחות בתחום המתאים: בדיקות ידניות או אוטומטיות

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

5.תעודה או הסמכה: הערכה של הידע שלך

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

6.חוות דעת ומשוב מתלמידים קודמים

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

7.התאמה לסגנון הלמידה האישי: מה הכי נכון לך?

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

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

The post איך לבחור קורס QA ועל איזה דברים לשים דגש? appeared first on ICS-המרכז הארצי ללימודים.

The post ההצלחה של גיא לאחר קורס סייבר appeared first on ICS-המרכז הארצי ללימודים.