שאלה מהותית

[GuestOfHonor]

שאלה מהותית

כתוכניתן מזה מספר שנים, אף פעם לא הצלחתי להבין את אנשי הQA, או יותר נכון - למה הם בחרו בתחום הזה משלל התחומים שמציע עולם המחשבים. כ'צופה מהצד', ש"נאלץ" מדי פעם לעסוק בפעולות מתחום הQA (כתיבת וביצוע מפרטי בדיקות, ביצוע בדיקות אוטומטיות, חיפוש אחר memory leaks וכן הלאה) אני ממש לא מבין מה גורם לבן אדם לבחור בתחום הזה. אז מה גרם לכם בעצם להגיע לתחם הזה, ולא, למשל, לפיתוח תוכנה או איש סיסטם?

 

[אבי ע]

אין הביישן למד... ../images/Emo39.gif

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

 

[xslf]

הבאגים בחרו אותי ../images/Emo13.gif

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

 

[Rשף]

אתה מפספס את העיקר

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