מחקרים אחרונים מראים ש-34% אפליקציות עם תקלות ננטשות על ידי המשתמשים בצורה מידית, תוכנה עם תקלות מרובות גורמת לעסק להפסיד לקוחות ומשתמשים. אז איזה טעויות קריטיות חשוב שאירגונים ידעו על איכות התוכנה שלהם.
1 בדיקות התוכנה נמצאים בסוף מחזור חיי פיתוח התוכנה, וככל שהתוכנה הגיע לבדיקות מתחיל לחץ גדול דרך צוותי הפיתוח, מנהלי הפרויקטים והלקוחות להשיק את המוצר לייצור, גם על חשבון האיכות, ובכך פוגעים בעבודת הבודקים במציאת תקלות הן בתהליך הקריטי והן בתהליכי הריגרסיה. לכן קריטי על בודקי התוכנה לייצר מיקוד ותיעדוף על תסריטי הבדיקות ולהספיק לבצע את התרחישים השכיחים מבחינה עסקית והחשובים ביותר, הן מבחינת תהליכי הפיתוח החדשים והן ברגרסיה על תהליכי ייצור קיימים.
2. איכות תהליכי האיפיון, וכתוצאה מזה הכנת תסריטי הבדיקות הפונקציונאלים התואמים לדרישות האיפיון המפורט, לאחרונה ולאור הצימצומים בתהליכי הפיתוח והבקשה לזריזות, אנו עדים גם על דילוג מפרטי ותכנון הבדיקות, מה שגורם לירידה משמעותית לאיכות התוכנה ולתקלות ייצור גבוהות. על כן נדרש וחובה לתעד את כמות תקלות הייצור ולהראות מגמה ישירה של כמות הבדיקות שנערכו בריצפת הייצור אל מול משך זמן הפיתוח וזמן ההתעסקות בתהליכי הייצור שהרבה יותר מורכבים הן מבחינה עסקית והן מבחינה טכנית.
3. מיקוד בתקלות החשובות ביותר – מציאת תקלות רבות איננה הדבר החשוב בבדיקות תוכנה ו QA, ההפך זה יכול להפיל פרויקט ברגע שאנחנו מנתבים את צוותי הפיתוח לטיפול בתיעדוף לא נכון בתקלות, ולכן יש חשיבות רבה תיעדוף רמת התקלה והשכיחות העסקית של התרחיש.
4. שימוש לא נכון ולא יעיל בכלים – לדוג' הכנסה של כלי אוטו' לשלב ראשוני של פרויקט איננה יעילה כלל, ובגלל שאנחנו יודעים שבגרסאות ובהשקה ראשונה של מוצר יש המון שינויי תוכנה הדורשים את יציבות התהליך הפונקציונאלי, מה שיגרום לתהליכי האוטומציה שלנו לא לעבוד כשורה ולתחזק את התסריטים האוטו' כאשר המוצר רק בחיתוליו, על כן, שימוש בכלי אוטו' נכון שייכנסו לשלבי הריגרסיה.
5. לייצר קונפליקטים עם צוותי העבודה השונים – בודקי התוכנה יכולים להיכנס די בקלות לקונפליקט עם צוות הפיתוח, מנתחי המערכות ומנהלי הפרויקט בעקבות אי הסכמות על התקלות, האם מדובר על תקלה, האם היא צריכה לקבל תיעדוף, הצורך לשחזר או לצרף סירטונים וצילומי מסך לתיעוד צעדי הבדיקה גורמים לעיתים קרובות למחלוקות בין הצוותים. בודק תוכנה טוב יודע לאוסף אליו את צוותי הפיתוח ולהסביר את חשיבות התקלה שהם מצאו מבחינה עסקית ולא ממקום של כוח, ככל שצוותי העבודה יסמכו על הבודק ככה הם ייתנו תיעדוף וחשיבות לתקלות המתועדפות של ה QA הרלוונטי. ובכל אופן אסור לזלזל באנשים שעבדו קשה כדי לייצר את המוצר ולהשתמש באימרות לא מקדמות כמו המערכת לא מתפקדת, היא לא טובה.
6. סביבות עבודה – סביבות נמוכות הם קו הייצור של צוותי הפיתוח, במידה ומצאתם תקלה ותיעדתם אותה על סביבה, שימו לב לתיזמון ריענון הנתונים, אתם יכולים למצוא את עצמכם עובדים קשה ולמצוא למחרת שכל התיעוד שלכם נמחק ובעקבות ריענון הנתונים. חשוב ללמוד את פרקי הזמן לריענון הסביבה, לתעד בווידאו את מציאת התקלות או בצילומי המסך ולהקל כמה שיותר בתהליך השחזור.
אירגונים הזקוקים לייעוץ באסטרטגית בדיקות, מוזמנים ליצור איתנו קשר.
בודקי תוכנה המעוניינים להתמקצע בתחום, מוזמנים להיכנס לקורס הדיגיטלי שלנו לבדיקות תוכנה
TesQA 