כשאנחנו מוצאים תקלה, אנחנו בדרך כלל מתעדים אותה ב QC או ב TFS תלוי בכלי איתו אנחנו עובדים, אם התקלה היא לוגית, אז המצב מאוד פשוט, כי אנחנו נרשום את הצעדים שהובילו אותנו לאיתוה התקלה ולמעשה התוכניתן יוכל לבצע את אותם הצעדים כדי לשחזר את התקלה, כמובן שיעזור מאוד אם נסריט לו איזשהו סרטון הממחיש את הבעיה, או לפחות נעלה מספר צילומי מסך שיעזרו לו באיתו הבעיה והפתרון.
הבעיות המורכבות יותר נופלות על ריצפת הייצור, או על בעיות סביבתיות בריבוי ממשקים ורכיבי תוכנה כגון, F5, או WAF המתערב באמצע התהליך, ואז לבודק התוכנה הרבה יותר מורכב לשחזר את התקלה כי היא מושפעת מתהליכים ספורדיים, אז מה עושים?
- לייצר לוגים וכמה שיותר בנקודות כאלה ואחרות שיוכלו להצביע על התקלה.
- להכניס סניפר, שיוכל להבין לאן המידע זורם והאם יש בעיות רשתיות כאלה או אחרות.
- לבודד כל רכיב המשתתף בארכיטקטורה, ולנסות להפעיל את התהליך תוך התמקדות רק ברכיב אחד בכל פעם.
- יצירת SUP UI המזרים מידע רב במידה ומדובר על ממשקים.
תקלות מסוג זה באמת המורכבות ביותר לניטור, מציאתן ומתן פתרון איכותי, אבל זה בהחלט אפשרי. עם אנשי המקצוע הנכונים ומטודה ברורה יהיה אפשר למצוא כל תקלה ככל המורכבת שתהיה.
אם אתם רוצים להרחיב את הידע שלכם בעולמות בדיקות התוכנה וה QA, יצרנו עבורכם קורס דיגיטלי לבודקי התוכנה, לפרטים נוספים >>
בתי עסק ואירגוניים הזקוקים ליעוץ, הכוונה או לבודקים חזקים. השאירו פרטים ואחד הנציגים יחזור אליכם בהקדם.
TesQA 