תחילת הדרך בQA

מה זה QA?
ראשי התיבות של Quality Assurance, אבטחת איכות מוצר ותקינות. בשונה מבקרת איכות, תחום אבטחת איכות מטרתו להבטיח השקת מוצר באיכות גבוהה.

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

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

מה צריך להבין לפני שמתחילים:

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

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

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

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

QA אינו קשור לאפיון המוצר: טעות לחשוב שלQA אין חלק מהאפיון. לאחר מעבר על דרישות לקוח הארכיטקט ינסח ויעביר לכם מסמך אפיון, בחברה מסודרת תהיו נוכחים במעבר על מסמכי האפיון(DR (design review בנוכחות המפתח והארכיטקט. באמצעות מסמך האפיון נלמד את המוצר, נתכנן בדיקות, נבנה חזיון עבודה ואף נמצא בעיות/באגים בתכנון המוצר ברבדים שונים: ממשק משתמש, פונקיונאלי, אינטגרציה וכד'. 

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

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

לסיכום:

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



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

• פארי תרבות ומרחק שיוצרים כשלי עמידה בציפיות.
• פארי שעות עבודה כקושי ניהולי לייעול תהליכים.
• קשיי אמון/בקרה ושמירת סודיות.
• קשיי ניהול במקרה של פרויקטים דינמיים המצריכים אינטראקציה גדולה. 

אז במקרה הרע יוציאו את כל הפרויקט לחו"ל אבל אז נראה את החברה תובעת עובד על הפרת הסכם סודיות.