תפקידי הבודק בכל מחזור חיי הפיתוח

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

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

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

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

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

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

מתעניין בבדיקות תוכנה – הקורס שלנו קריטי עבורך, כנס עכשיו>>