מומחי בקרת איכות.
לא רופאים כלליים.

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

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

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

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

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

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

אנו מאמצים את אופן העבודה שלכם. בצוות אג'ילי, צוות הבטחת האיכות (QA) הוא חלק מהצוות, והגדרת ה"מוכן" (definition of done) כוללת את הבדיקות — אין שלב קבלה שנדחה לסוף. ב-SAFe, אנו משתלבים בתכנון ה-PI ובבדיקות אי-רגרסיה משותפות. במודל ה-V, חוזרים לתוכנית בדיקה קלאסית. השינוי האמיתי בשנים האחרונות אינו המסגרת, אלא העובדה שהבדיקה הועברה לשלב מוקדם יותר: ככל שתקלה מתגלה מוקדם יותר, כך העלות שלה נמוכה יותר.

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

כי כבר 27 שנים ש-TTC עוסקת בדבר אחד בלבד: איכות תוכנה. אנחנו לא חברה כללית שמציבה גם בודקי תוכנה — בקרת האיכות (QA) היא כל העיסוק שלנו. בפועל, מי שמוכר לכם את הפרויקט ביצע פרויקט כזה בעצמו, ואתם לא משמשים כשטח אימונים לעובד זוטר שמשתכר לפי טבלת תעריפים.

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

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

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