אחת לכמה זמן אני נתקל באינטרנט בשאלה "אני מתחיל ללמוד על בדיקות, האם כדאי לי ללמוד אוטומציה?" והתשובה של יותר מדי אנשים היא "קודם צריך ללמוד את הבסיס - מתודולוגית בדיקות".
ובכן - בולשיט. זה כמו לומר שאי אפשר ללמוד חשבון לפני ששולטים היטב באנגלית כי שמות המשתנים הם באנגלית. בסופו של יום, תכנות ובדיקות תוכנה הם שני כישורים חשובים כל אחד בפני עצמו והם אינם עומדים בסתירה זה לזה.
אז כן - רוצים להתחיל את דרככם בבדיקות ותוהים מה כדאי ללמוד? תכנות זה אחלה, גם סטטיסטיקה, וגרפיקה, וניהול מסדי נתונים, ורשתות תקשורת, ואלקטרוניקה, וכתיבת מסמכים יעילה, ופסיכולוגיה ותקשורת (אנושית) וכלכלה, וניהול ו... הבנתם את הקטע.
יש המון דברים שעוזרים במידה זו או אחרת בזמן בדיקות, וכדאי ללמוד את כל מה שאנחנו יכולים. כמובן - אי אפשר ללמוד את הכל יחד, וכדאי להתמקד בדברים החשובים יותר קודם. בכישורים ובידע שאפשר להגדיר ככישורי ליבה של המקצוע. את כישורי הליבה חשוב ללמוד קודם, כי בלעדיהם קשה. שאר הדברים? רק אם יש זמן ומספיק קשב כדי לא לפגוע ברכישת כישורי הליבה.
נשאלת השאלה - האם תכנות נכלל בכישורי הליבה של בדיקות תוכנה? אחרי הכל, יש המון בודקי תוכנה שלא יודעים לתכנת. לדעתי, התשובה היא בהחלט כן. אנחנו בודקים מוצרים שונים מעולמות תוכן שונים, אבל לכולם יש משהו משותף - אלו מוצרי תוכנה. בבסיס כל אחד ואחד מהמוצרים האלה יש קוד שרץ. אולי זה קוד שנכתב בשפה עילית, אולי זה בכלל מעגל משובץ שהקוד צרוב לתוכו - אבל זה תמיד קוד, והוא תמיד מתנהג כמו קוד. לכן, כמינימום, חשוב שנהיה מסוגלים להבין איך קוד פועל ואיך קוד נכשל. הדרך היחידה להבין דברים כאלה באמת היא לכתוב קצת קוד בעצמנו. זה לא חייב להיות קוד מסובך מאוד, אבל מאה פעמים בהן נקרא או נשמע על Off By One Bug לא יהיו שקולות לפעם האחת בה נכתוב לולאה ונפספס פעולה אחת.
ובכל זאת, כל מיני אנשים שהשקיעו מאמץ ומחשבה טוענים חזור וטעון ש"צריך ללמוד לבדוק לפני שלומדים אוטומציה" - איך זה הגיוני? האם הם כולם טועים?
אז לא בדיוק. אם מתעלמים מאלו שלא יודעים לתכנת וצועקים חזק כדי לנסות ולמנוע מהעולם להשתנות, עדיין יש שתי סיבות שאני מצליח לחשוב עליהן שיובילו לתשובה כזו:
- הטיית השורד. אנשים נוטים לייחס חשיבות לדברים שפעלו עבורם - אני מנחש שרוב אלו שיענו כך למדו לתכנת אחרי כמה שנות ניסיון בבדיקות, והם רואים את הערך שידע מעמיק במתודולוגיות בדיקה הוסיף למאמצי התכנות שלהם. כמובן, גם הגישה שלי לפיה לומדים לתכנת כמה שיותר מהר נובעת מהטיית השרידה שלי - אני הגעתי למשרת הבדיקות היישר מהאוניברסיטה, שם למדתי לתכנת, וגם כמה דברים על בדיקות תוכנה. לא שמתי לב שהידע התכנותי שלי פגע ביכולת שלי לרכוש ידע בבדיקות תוכנה.
- התקת מטרות (ובלע"ז - Goal Displacement). אני רוצה להצביע לרגע על כך שהשאלה המקורית הייתה "האם כדאי לי ללמוד אוטומציה", והתשובה שלי הייתה "כן, כדאי ללמוד לתכנת". מי שהגדרת התפקיד שלו היא "אתה כותב אוטומציה" יתמקד, באופן טבעי, בכתיבת אוטומציה. כאשר משלבים מיקוד שכזה ביחד עם היעדר ניסיון בבדיקות תוכנה, לא נדיר למצוא אנשים שכותבים קוד לבעיות שעדיף היה לא לכתוב קוד כדי לפתור אותן (או שהיה עדיף לכתוב קוד במקום אחר ובצורה אחרת כדי להתמודד איתן). כל מיני תופעות מגונות של אנשים שכותבים תסריט שלם שמזיז את הממשק הגרפי כדי לכסות דברים שעדיף להם להיות מכוסים בבדיקות יחידה, או כאלו שמוסיפים "חכה עשר שניות" לכל המבדקים רק כי לפעמים פעולות לוקחות המון זמן (במקום, למשל, לחקור למה דברים לוקחים עשר שניות, או חלילה, לפתוח על זה באג). ואחרי הכל, אם התפקיד שלי הוא "לכתוב אוטומציה", אני לא כאן כדי לבדוק את המוצר, אני כאן כדי לוודא שהתסריטים שקיבלתי מצוות הבדיקות רצים כמו שצריך.
בקיצור - התשובה לשאלה "האם ללמוד אוטומציה" איננה "אחר כך", אלא, באופן חד וחלק - לא.
כן חשוב ללמוד לתכנת, כי תכנות הוא כלי נהדר ומגוון שיש לא מעט דברים שקשה לעשות בלעדיו. המטרה1 לא מושפעת מהתשובה לשאלה "האם אני יודע לתכנת", בתנאי שהתכנות משרת את המטרה הזו.
Every now and then I see a question posted somewhere "I'm starting my way in testing, should I learn automation?" And too many times I see the response "You should learn first to test well, and expand to automation only once you have a good testing foundation".
Well, I call bullshit. Saying such a thing is similar to stating that one cannot learn higher math before mastering Greek, as many of the symbols are Greek letters.
Programming and testing are two important skills for a software tester, and acquiring one is not impeding acquiring the other in any way.
So, what should a software tester know? Testing is one thing, programming is another, as are statistics, graphics, network, electronics, databases, communication skills, finance, management, psychology and ... - you got the gist.
There are a whole bunch of skills that help us when we test software, and it is a great thing to learn any part of them. Naturally, we cannot learn everything, and certainly not everything at the same time, so we have to prioritize. It's better to focus on the skills that will deliver the most value in most positions (or, if you know the position you aim for - most value in that position), and I'll call those "core skills" - it does not mean that everyone has them, but only that they are not esoteric and possessing them would benefit most practitioners. The core skills are what we should focus on "first". Learning other stuff? only if it does not hinder our efforts to acquire the core skills (or we are already comfortable enough with them to expand).
The question is - is coding a core testing skill? After all, many testers do not code. Personally, I answer this question with a definite yes, based on the fact that all of us are testing software, and we should have a pretty good understanding of "how software works" (and how it fails). The only way I know to get a feeling around this (which later can lead to understanding, but feeling is good enough for beginners) is to actually write code. One can hear a million times about the "Off By One Bug" and even understand it pretty well, but those million times pale in face of the one time that person wrote a simple for loop just to find out that one step was missing.
Still, some people who have invested genuine thought about this subject still claim that one should learn to test before they learn to code. Could it be that they are all wrong?
Well, they could, but it's not very probable. Putting aside some of them who simply don't code and are trying to assert everyone that nothing is changing in the testing world, I can think of two reasons to prefer focusing on "manual" testing (BTW. I really hate this term, any suggestion of replacing it are welcome. I've tried "human testing" and it's not working for me) before learning to write automated checks.
- Survivorship bias: Some people learned to code after they had some experience with testing, and I'm assuming they see the value they gained from having this testing experience. This value then becomes "the way to do it". Naturally, my own opinion, as someone who started as a coding tester, is biased just as much.
- Goal displacement: I want to point out that the original question was "should I learn automation". It is only my response that was "learn to code". People whose role is to "create automation" tend, amazingly, to focus on creating "automation" (which, in most places having such role, means E2E scenarios). When combined with lack of testing knowledge, it is not rare for people in this role to "automate" thoughtlessly - writing code at the wrong level, or trying to write code to solve problems that are better left to humans, or working around a defect in the system (say, a screen is taking 10-20 seconds to load) instead of investigating the problem or opening a bug. After all, if my role is to "write automation", I'm not here to test the product. I'm here to make sure the test execution is delivered on time and is stable.
So, in short, the answer to "Should I learn automation" isn't "later", it is a resounding "no".
It is important to learn how to code, since coding is a powerful tool that can help quite a bit with our tasks and there are several things we simply can't do without it. Our goal1 as testers should not be affected by whether we know to code or not - as long as the coding serves this goal.
1 Initially I wrote "the goal is to test the software", which leads to another discussion about what is the role of software testing, which I'll leave for another time (don't hold your breath for it, though). Currently, I like ATAOSQ quite a bit ↩
No comments:
Post a Comment