אחת הסוגיות הכאובות באיכות תוכנה, זה אינטגרציה לקויה בין צוותים. מודל שירותים בין צוותי הפיתוח עשוי לייצר תהליכים שבורים שלמעשה אין ערבות על איכות המוצר והפתרון על ידי הצוות המאפשר את השירות ל Produact בעוד שהוא נעזר בעצמו בשירותי צד שלישי כמו לדוג' אטבחת מידע והלבנת קבצים. אז איך ה QA נכנס פה לסייע בתהליך ומה הדרך הנכונה לייצר אינטגרציה איכותית ובערבות משותפת על הצלחת האיכות?
מבנה אירגוני תומך QA
יש מספר מטודולוגיות למבנה אירגוני תומך דליברי כגון איג'יל או SCRAM, במבנים כאלה ה QA מוטמע כחלק מצוות הפיתוח ואחראי על מוצר בדיוק כמו המפתח או מנהל המוצר. במקרה כזה יש לחץ אדיר על הבודק לאשר את איכות המוצר, לטובת עמידה ביעדי הזמן והתכולות על חשבון האיכות. מבנים אלו עשויים לייצר כאוס ברמת האיכות, ומנוף ברמת הדליברי. אז איך נכון להתמודד? צוותי הבדיקות צריכים לדווח מעל מנהל המוצר או הפרויקט ישירות לדורש, כלומר הכפיפות המעשית של הבודק לא יכולה להיות בשום אופן ל IT אלא לדורש עצמו. ומצד שני להיות כחלק אירגוני מצוותי הפיתוח.
Fron End קודם לידע עסקי
ידע עסקי הוא המלך, בהחלט בתהליכי פיתוח. לא נכון לצאת למוצר או לפיתוח ללא הבנה מעמיקה של כל תהליך העבודה, הסתכלות על הצד התפעולי, הצד השירותי ולקוח קצה. במקרים כאלה נהוג לתת לידע העסקי להוביל את הפרויקט. כשל ייצורי הינו כשצוותי ה Front מנותקים מתחומי האחריות לידע העסקי, בהם שותפים לפרויקט, לייצור שלו, לממשקים שלו אבל ללא יכולת ביצועית לרדת לרמת התהליך העסקי. ולכן רמת הארכיטקטורה יורדת על חשבון מעקפים קצרי מועד לדליברי על חשבון פתרון יציב וארוך מועד.
לסיכום: בעיות אינטגרציה תמיד יהיו קיימות, הקושי של צוותי הבדיקות ועמידה על האיכות שלהן, קריטית בשלבים אלו. על מנת לייצר איכות על האירגון לקחת החלטות הן ברמת זמן, תכולות ואיכות והן ברמת מבנה האירגוני והכפיפויות להצלחת תהליך כזה.
מתעניין בבדיקות תוכנה? בוא להעמיק את הידע שלך איתנו >>
TesQA 