מה ערכו של בודק תוכנה?

 

English

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

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

מעבר לזה, גם בעולם האידיאלי שבעיני רוחי, זה לא שאין בכלל צורך בבודקי תוכנה. פשוט, צריך הרבה פחות מהם. אם אמרנו שלפחות 95% מהעבודה לא דורשת מומחיות משמעותית, זה עדיין משאיר לנו כמה אחוזים של עבודה קשה שעבורה כדאי שיהיה איזה מומחה בסביבה. למשל, במקום העבודה הקודם שלי התחלנו לפתח מוצר מבוסס ענן, בלי שהיה לנו הרבה ניסיון בסביבה. כדי להפוך את העניין למאתגר, יחידת הייחוס הבסיסית הייתה "חשבון AWS", כך שהפרקטיקה של יצירת סביבת פיתוח או בדיקות בכל פעם בה היה צורך לא הייתה טריוויאלית ועלתה השאלה איך צריכים להיראות מאמצי הבדיקות שלנו. היו לא מעט מגבלות ודרישות שהשפיעו על ההחלטות - מה קצב הפיתוח שאנחנו שואפים אליו? כמה צוותים שונים יעבדו על הפרוייקט במקביל? מה רמת הביטחון שנדרשת כדי לשחרר את המוצר לשטח? במסגרת ההחלטות האלה היה צורך להוביל דיונים עם ההנהלה ומובילי הפיתוח כדי להחליט איך יראה התהליך כולו, מה בחירות עיצוב שונות יאפשרו לנו ואילו פשרות מקובלות עלינו. היה צורך גם לנסות כמה טכנולוגיות חדשות (כך, למשל, למדנו שעבודה עם PACT בפיית'ון לא הייתה ברמת הבשלות שהיינו צריכים באותו זמן) וליצור כמה דוגמאות טובות לסוגי הבדיקות האוטומטיות שרצינו לראות ברמות הבדיקה השונות. כדי להצליח בזה גייסתי את היכולת שלי לדבר על בדיקות באופן מעמיק ולוודא שכולם בחדר מסכימים לגבי מה אנחנו מנסים להשיג ועל מה אנחנו מוותרים, ניצלתי את ההיכרות שלי עם קהילת הבדיקות ורעיונות ששמעתי בכנסים שונים כדי לשים על השולחן כמה אפשרויות שונות (למשל, בדיקות חוזה נועדו לאפשר לנו לעבוד מהר יותר בלי ליצור תלויות בין צוותים, המחיר לזה הוא עלות הקמת התשתית וויתור על בדיקה מלאה של כל המערכת - אז אם משהו התפספס בחוזה, חבל), כדי להבין איך להתגבר על על המגבלה של "התקנה אחת לכל חשבון AWS" נדרשתי לכישורי מידול טובים - בקיצור, כל מיני משימות שדרשו ממני כישורים טובים למדי בתחום הבדיקות - אולי לא משהו מטורף, אבל בהחלט יותר מאשר מביא לשולחן מפתח תוכנה ממוצע. 
המוטיבציה האישית שלי, במקרה הזה, ברורה - אלו בעיות שאני נהנה להתמודד איתן, ולכן הגיוני לשפר את היכולות שלי בתחום. אם יום אחד נגיע לעולם האידיאלי שאני מזכיר כאן ונגלה שהמומחיות הזו היא עוד אחד מהכישורים שיש לארכיטקט תוכנה ולא חונים אצל מומחה בדיקות ייעודי? אחלה, אז יהיו לי חלק מהכישורים הנדרשים, ואפתח את האחרים לרמה הנדרשת.

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

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

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

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

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

What is the value proposition of a tester?

עברית

In the previous post I have laid out my reasoning about why most places should not have dedicated testers, eventually. Despite that, I'm working as a tester, and investing effort in becoming a better one. How does that align with my claim that having dedicated testers is a bad business decision? Am I just cheating my employers by performing some task that looks important but have a negative value?

Naturally, I'd like to think I don't do that, which leads me to try and articulate both my motivation in performing a dedicated tester role, and the value testers (including myself) are bringing to the organization, even if the extremely special conditions that make dedicated testers a good idea don't apply. 

First and foremost, quite naturally, is being a transition guide. In essence, I believe this should be a part of the role of any tester - it might be a minor part when one is learning the ropes, or it can be a significant one when someone is filling a leadership position, but it should almost always be there. Saying that most organizations don't need testers is not the same as "send all of your testers home, now". Some organizations will survive such a change and even thrive, but for others, and I guess most, ripping the tourniquet (as I heard Alan Page refer to it once) will lead to a period of chaos resulting in founding another test team and declaring the experiment a failure.  An organization needs to get to a point where responsibilities that were part of the dedicated testers' mandate are being covered skillfully by other parts of the process or organization. Some call this "whole team accountability" or something along those lines. I might not be very good at this yet, but pushing towards this change is something I enjoy doing, and I believe it is creating benefit for my workplace, even if I still have a lot to learn. Figuring out the process improvements, dropping small bits of education here and there and building some of the safety nets that allow for faster, more informed SDLC is a super interesting challenge. If I want to be a central figure in those transitions I need to have a strong testing foundation that I can leverage to help dealing with the hurdles and surprises that are inevitable in these situations.

In fact, in my ideal world, it's not that there are no testing experts at all - some of the problems are difficult and require deep testing skills and knowledge, and for tackling those, an expert is needed. For instance, consider the following example: at my previous workplace I have to come up with a testing strategy for a new, AWS native product. It involved a lot of constraints - on the resources that would be available to develop and test, on the different teams that would participate and on the cadence we wanted to operate at. Just to agree on those, I had to lead some discussions with management and the lead programmers and make sure we were in agreement about how the work should look like - who is best positioned to perform which task and what complications each choice added to the rest of the system - In short, I had to articulate the testing needs and contributions in a language that would fit other software professionals, and take their input to adjust. When suggesting solutions I leveraged some ideas I've heard about in conferences (such as using contract testing to enable independent development of components, or using approval testing to speed up complex validations), at the very least, to create some options for us. I then went on to discuss how to design our system so that we could deploy most of it without creating endless AWS accounts, which for a product that assumes it manages an entire account, is far from trivial - which required strong system modeling, and balancing between ease of test system deployment and fidelity to the real world (as well as other tradeoffs). Without my testing skills and familiarity with the testing community and the ideas flowing in it - all of which are beyond what your average senior developer would usually have - I would have done a poorer job. Those difficult problems will mean that every now and then an expert tester will be needed. Probably at similar numbers to software architects (which need not be different people, I can easily imagine a world in which solving difficult testing problems is part of the architect's tasks.
My personal motivation is quite simple on this point - those difficult testing problems are something I like to tackle, and building my skills towards it makes a lot of sense. If when we get to my ideal world it'll turn out that those are handled by a software architect? well, I'll be starting this learning journey with the testing part covered and work on building the rest of the necessary skills.

But, I'm not only trying to become a better tester myself, I also strive to help others do the same. What justification do I have there? Some people might make the same choices as I did (do?) and in such case, no more defense is needed, but most people probably would have other goals and intentions. For those, I'd point that while teaching people to be better testers, I actually teach (and learn) various testing skills. which, in contrast to the tester role, are necessary. This knowledge will help also when teaching non-testers to how to test better.

So, we have difficult problems and we have a transition guide. Pretty hollow, so far - I have claimed that the difficult problems are less than 5% of the actual work, and helping a transition happen isn't much of a big deal if the value currently residing in the dedicated tester role is nonexistent, right? So, what are the responsibilities that make a tester valuable during this transition journey? Or, in other words, what is the value proposition of a tester? Here's my list. As can be expected, none of these items can be addressed only by having a dedicated tester and I would claim that it's usually better to either hand them over to another role or to change the process so that it is no needed anymore, but building those alternatives takes some time and conscious effort - exactly why we need a transition guide.

• Risk seeking: Developers can sometimes be bold, maybe even too bold for everyone's good. It's really important to be bold if you want to tackle hard problems and not daring to make the first step. It does, however, needs to be balanced to avoid bold decisions that drive us off a cliff. An easy way to do that is to have someone who is looking on what we're building and asking "what if...?". That look for potential misuse of the application and raising them so that the risks can be either mitigated or consciously accepted. 
• Design stakeholder - This is tied to the risk-seeking perspective: A tester is a force in the team pushing for a design that is easier to monitor, that deals with expected failures, perhaps something that is simpler or broken down to simple modules. Things that might evade a team that is focused on fast delivery on the short term - all those choices a tester might be the right person to advocate for, or to put pressure towards using them, should, if done properly, accelerate the team eventually, they just seem like needless hassle when only the immediate term is taken into consideration.
• Safety net building. Some people call it feedback, but a tester does, in some places, build a set of tools that can detect errors and broken parts of our application. Building those tools is an expertise in itself,  that is not yet common enough among software practitioners, very much like it was with unit tests a decade (or two? probably closer to two) ago. 
• Translating between the technical and business layers. Brendan Connolly wrote about this about a decade ago, and it is as true now as it was then. Testers usually navigate between two semantic worlds - the developers one, and both sides of the business world - requirements and customer support. As such, they are probably the best suited to translate between the layers. A customer opens a bug? the tester can translate it to something actionable by a developer. There's an ambiguous requirement? A tester might be able to help put it in technical terms that are easier to understand and communicate with the product manager to make sure nothing is lost in translation. Sometimes you even need someone to translate between two development teams, each with its own context and viewpoint.
• Calming upper management. Sometime, you just need a magic 8-ball that will tell you that everything is going to be alright. Most testers will face some time in their career the question "is it ok to release?", when the  other side just wants to hear "yeah, we're good, you can trust me". No, it's not a call to lie - just to know that sometimes your stakeholders want the bottom line - either all is good, or there's something they need to know about.
• Evaluating operational properties - performance, security, and all of those other side effects to a program's functional development. Since programmers tend to focus on the functional aspects of their work, it takes more time and maturity to add the operation properties to the scope of concern and testing. It's also a harder testing task, so a specialist will be required there for a little longer. 

There are two roles that I intentionally didn't put in this list, not because they never happen, but because I don't think they are part of the tester's value proposition (And I would claim they might actually be harmful). Those are:

• Verification of functional correctness - the developers working on the features are big kids. They should be able to tell if they done a good enough job. Having a tester whose job is to find stupid mistakes is both a waste of talent and a call for developers to abdicate their responsibility.
• Regulatory scapegoat. While some regulations might refer to testers, if that's the only reason for keeping them, - the organization is probably harming itself and would be far better off by showing the auditor that the regulation is satisfied by their process. Scapegoat needed?  Have some manager tick a box in the form and "take responsibility" on the outcome. In fact, it could be the very same person who is setting up the procedures required for this regulatory mandate. For cases where an "independent" validation is required,  a well functioning test team is not really aligned with the spirit of the regulation since it's too close to the development. In such cases, and auditing company (or department) is much more aligned - someone whose interest is not to ship the product but rather to make sure they can't be blamed for not doing their due diligence. 

למה אני ממשיך לעשות את זה?

English

 

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

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

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

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

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

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

 

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

Why do I keep doing this?

עברית

Yesterday, I volunteered a couple of hours to help review the translation of an ISTQB paper into Hebrew. Specifically, the "CT-AI" syllabus. I did it mostly because someone asked and I thought it won't hurt to give it a little time a small part out of wanting to see how bad they managed to get it, and a tiny fraction of hope that maybe this time it won't be as terrible (spoiler - it was).

So I got an excuse to read parts of the document (I didn't bother with the entire thing, just a random chapter or two and the example exam), and it's the same problem all over again - a silly multiple choice questionnaire that you can pass with some common sense and guessing. One bonus point is that the syllabus mentions some practical hands on exercises that can be done. No, of course there's no enforcing of this, but a serious training vendor could, in theory, cram some useful learning that will not be needed for the certification exam but is, officially, expected. Self learners and less reputable training providers? they will probably skip those exercises. 

Also, very much like CTFL, CT-AI also misses the mark completely, but it does so on a more profound level. To be more specific -  It aims for the wrong goal. Most of the syllabus is aimed at "how to test a neural network" (it does recognize that there are other types of "AI" in the form Bayesian algorithms or oven simple decision trees, but almost all properties they attribute to "AI" are more in place with neural networks than with other sorts of machine learning algorithms - which is ok, most people saying "AI" today do mean a neural network of a sort). Now, neural network development (or, "training" is the parlance goes) is testing. The data people let the computer run until it passes their defined test cases and then they declare it done. They might tweak with the network's geometry, weighting or calculations, but most of your work will be collecting the right data, and evaluating the model's performance. This sort of testing usually involves some heavy math and big data techniques - both are not really something mandatory in a tester's background. For testers, such as me, who don't have those math skills sharpened, their contribution to testing the model itself will be fairly limited and will be inferior to that of the data people.Testers who do have shaken the dust of the relevant math (or learned it from scratch) - don't need this basic mess of a certification. 

A better goal for this certification would have been to accept the fact that most testers won't spend their time testing models but rather test systems with embedded "AI" in them and deal with the complexity of a nondeterministic element in the system. Only caveat with that? Testers have been doing that for years, and it's not really different than simply testing, so you can't scam more money out of people. 

 So, sadly, no surprises here - somehow the ISTQB organization has managed yet again to get a bunch of really smart people to produce a piece of work that has a negative value. It's a waste of time for everyone involved in writing, teaching, or learning it. It has unrealistic goals that are unmatched by the weak certification conditions. 

 And one last thing - The first (and currently latest) version of the syllabus was out in October 2021, riding the wave of "deep neural network" that seemed to be in every start-up name. ChatGPT was out a mere year later, and today  most of the material in this syllabus might not be outright obsolete, but it's heavily dated, as the capabilities of "AI" have leaped and our understanding of how we might use such systems has evolved quite a bit.

As for why do I keep doing this - mainly, it comes to a strange dissonance - while I do think that ISTQB is harming our profession, in a strange turn of events, the local chapter, ITCB, is doing some good by being the center of  the local testing community - organizing meetups, releasing a quarterly magazine and maintaining a podcast - so I keep around those people and when they ask for help, I'm sometimes there, even if it means paying the devil his due. I should probably make better judgement in the future. 

בודקי תוכנה זה דבר מיותר

 

English

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

1. אין צורך במומחיות. ברוב המקומות בהם הייתי, לפחות 95% מעבודת הבדיקות שנעשתה, וזו שהייתה צריכה להיעשות, הייתה ברמה שבודק תוכנה מתחיל היה יכול לבצע, או ביצע בפועל. המשמעות של זה היא שאנשים בלי הכשרה יכולים לבצע את המשימות האלה בקלות יחסית, או לכל היותר אחרי הדרכה קצרה וקצת תרגול. נכון, ישנם מקרים בהם באמת נדרשת מחשבה מעמיקה או מומחיות - כשצריך להגדיר אסטרטגיה לפרוייקט גדול או מורכב במיוחד, כשצריך להבין איך לבדוק מוצר קשה לבדיקה או פיצ'ר מסובך במיוחד. שם נזדקק לבודק תוכנה מומחה, אבל המקרים האלה נדירים. 
2. הסרת אחריות - כשיש מישהו שתפקידו הוא למצוא את הבעיות, שאר האנשים בסביבה יכולים להרשות לעצמם להיות קצת פחות זהירים, גם כשזה לא קורה באופן מודע. הם מגישים את התוצרים שלהם "לבדיקה", אז לא צריך להיזהר מאוד - מקסימום, יעזרו לי למצוא את הטעויות. 
3. הסחת יעדים -  אם יש אדם אחד שאחראי לכתוב תוכנה ואחר שאחראי לבדוק אותה, כל אחד מהם נמדד על הביצועים שלו בתחום האחריות הספציפי הזה. המטרה המשותפת שלהם - להוציא לשוק את התוכנה הנכונה במהירות האפשרית - לא שייכת לאף אחד. לאחד יש "דאג לספק תוכנה בקצב מהיר, ואילו לאחר יש "ודא שהתוכנה כתובה כיאות", וזה אם יש לנו מזל. במקומות מסויימים, היעד כפי שהוא משודר בפועל הוא "מצא סיבות טובות לעכב את שחרור המוצר". זה יכול להוביל למגוון בעיות התנהגותיות, ולקושי בשיפור כאשר כל צד מנסה לשפר את החלק שלו ולא מסתכל על המערכת בכללותה. אי שם לפני קצת פחות מעשור זכיתי לחוות את השינוי הזה בצוות בו הייתי. את הפיצ'ר אני כבר לא זוכר, אבל אני זוכר שכחלק מתכנון העבודה, ביקשתי לשנות את המימוש כך שחלק מסויים יהיה חשוף החוצה כך שיהיה קל יותר לבדוק חלק משמעותי של הלוגיקה. המתכנת שהיה אחראי על כתיבת החלק הנ"ל, התנגד. קודם כל, הוא כבר התחיל בכיוון מסויים, וזה לא נכון לעוות את התוכנה רק בגלל צורכי בדיקות, ובכלל, הנה כמה סיבות שנשמעות די משכנעות בגללן נכון יותר להישאר עם הבחירות הנוכחיות. אז קצת יותר קשה לבדוק את זה? נו, שוין.  רצה הגורל, ובגלל בעיות עומס, אותו מתכנת קיבל גם את המשימה של לבדוק את הפיצ'ר. גם כי היה עמוס, וגם כי היינו בשלב מתקדם יחסית של מעבר לצוות נטול תפקידים, בו כל חברי הצוות הם "מהנדסי תוכנה" או משהו כזה. כמה ימים אחר כך, במהלך הדיילי, הוא סיפר שהוא הסתבך קצת עם בדיקת הפיצ'ר, ומצא פיתרון יצירתי שהפך את הבעיה לטריוויאלית. בגדול? אותו דבר שביקשתי ממנו קודם. כל הטיעונים הטובים מקודם הפכו פתאום להיות פחות חשובים מאשר לשמור על קוד קל לתחזוקה ולבדיקה. 
4. לולאת משוב ארוכה יותר. לא משנה איך מסובבים את זה, או כמה טוב התיאום בין חברי הצוות, לולאת משוב שכוללת שני אנשים תהיה איטית יותר מכזו שכוללת אדם אחד. כאשר אותו אדם שמבצע עבודה גם בודק את התוצאה, יש לנו סיכוי הרבה יותר טוב לראות התנהגות של "בדוק, תקן, בדוק שוב". גם הפעולה בעקבות המשוב זורמת הרבה יותר - לא צריך לשכנע אף אחד שהבעיה אמיתית, ולא צריך לבזבז זמן על הסברים כמו "איך לשחזר את זה?". זה יכול גם לקרות כאשר כמה אנשים עובדים יחד - כאשר הם עובדים יחד על אותה משימה, בזוג או באנסמבל.
5. ריבוי צווארי בקבוק פוטנציאליים - אם יש לנו פונקציה ייעודית של בודק תוכנה, יש לנו עוד קודקוד בגרף התקשורת שלנו ובגרף התלויות - כלומר, יש יותר מסלולים שצריך לוודא שעובדים, יותר פקקים שיכולים להיווצר ויותר מקום לטעויות. מבנה פשוט יותר תמיד עדיף, כאשר הוא מתאפשר.
6. יש ראיות אמפיריות שמוכיחות את זה. ספציפית, אם אנחנו קוראים את מה שכתבו מחברי accelerate נראה שהם מוצאים קורלציה חזקה בין הצלחת החברות לבין זה שמי שכותב ומתחזק את הבדיקות האוטומטיות הוא אותו אדם שכותב את הקוד למוצר. ומה לגבי בדיקות שאינן אוטומטיות? ובכן, הם מאוד דיפלומטיים שם, ולא מזכירים את הנושא לטוב או לרע. מספיק לזכור אולי שהספר הזה מסכם כמה שנים של סקר בשם state of devops כדי להבין שאין בעולם שלהם המון מקום לבדיקות שאינן אוטומטיות. 

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

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

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

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

אני מקווה שהטיעונים האלה משכנעים אתכם לפחות כמו שהם משכנעים אותי, אבל גם אם לא, 

Testers should not be

עברית

People who heard me speak about testing, or noticed what I wrote  here, for example, might know that I believe most companies should strive to get rid of dedicated testers. I think it's time to put some more words to it. There aren't that many reasons, but I find them convincing, and hope you will too.

1. No specialization required. In most places I've seen, at least 95% of the testing work can either be done or is being done by junior testers -  people without a lot of experience, and any skill they might possess can be taught to just about any software professional with relative ease. There are some cases where we need to define a strategy for a large project, or find a way to deal with large amounts of data, or cases where it's hard to define "correct". In those cases we might need an expert tester - but those are the rarity. 
2. Abdication of responsibility - when there's someone whose role is to find problems, the rest of the people are less careful. Even when they don't mean to. They submit their artifacts for "testing", so they assume they need to do very little of it themselves. 
3. Goal displacement - when there's one person writing code and another testing it, no one actually has the supposed shared goal - "deliver the right thing at a good pace". One has "deliver at a good pace", the other has "deliver the right thing" (if we're lucky, it might be "find reasons to delay the delivery"). This can lead to strange behaviors, that are perhaps best illustrated in an experience I had about eight or nine years ago, when I spent some time asking a developer to change the design of a feature in order to make it easier to test. His response was "it's not right to change design just for testing, and here are a few reasons why the current design is preferred". This very reasonable (yet wrong) response flew out of the window a couple of weeks later when the same developer was tasked testing the feature (we were transitioning to a role-less development team, which worked really well, I think) and after struggling for a few days, he came to the daily standup saying "I was having trouble testing the feature, so I made some changes to the design and now it's easy to test". All the good reasons suddenly were less important than having maintainable (which includes easy to test) code.
   We don't want people in the team to have different goals, unless it's really necessary.
4. longer feedback loop. It doesn't matter how hard we collaborate, how good are our tools and practices, getting the feedback from someone else almost always adds some overhead to the feedback loop. when we have the same person who does the work also verifying the job is done well, we get a faster feedback loop, and action is taken on that feedback more easily. We are much more likely to see the loop of "test-tinker-test" when the same people are doing both tasks (either as a pair or ensemble comprised of different skilled people, or as a homogenous group of one or more people)
5. More (potential) bottlenecks - with a dedicated tester, we've just made another vertex in our communication  and dependency graphs. This means that there's one more party to update and hope no significant information gets lost, and there's one more kind of work that we need to coordinate with the rest of the work. 
6. There is some empiric evidence this is the case, I'm familiar with the claims in "accelerate" (that have been very careful to narrow their scope to "automated tests", but I suspect this choice is a political one, as they don't mention any other kinds of testing that has any correlation to business success)

Ok, let that sink for a while. I can hear some rant in the distance, rambling about "What about the tester's mindset??", and there are a few examples where dedicated testers are simply a must and I'm sure they jump into your mind. As for the first objection - there isn't a thing like that. Testing, and the thinking associated with it are skills that are being taught and honed by experience that includes focus on risk seeking. In this aspect, a developer with a decade of experience will probably do a better work testing than most testers with two or three years under their belt. 

The second point, however, holds true, and this is why I believe only "most" companies can do without dedicated testers, and not all of them. The most notable example I've met is while I was interviewing for the team I was at a few years ago. The interviewee held a masters degree in physics and was testing a ground radar. His day job included a lot of calculations and applying his knowledge - knowledge the developers didn't have, nor did they have the time to acquire it. This is probably the only situation I can think of where having separate testers is more efficient than making testing a part of the creator's work. There might be some constraints that would make having dedicated testers a good choice for the time - we might not have the right culture, or we might be testing an application that we pay someone to develop and we don't trust their testing is good enough for us, or our budget and reporting mechanism might encourage us to behave in that way -  but those are conditions that should be eliminated over the longer term.

I hope you find those arguments convincing as much as I do, but even if you disagree, I hope it helps to understand my stance on dedicated testers.

Next: Why, despite those thoughts, I identify as a tester and invest effort in becoming better at it.

ושוב איתכם

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

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

אז התחלתי, באופן רשמי, באפריל האחרון. עד אז הייתי בצוות כבר תשעה חודשים, ולפחות באופן רשמי, נוהלנו באופן ישיר על ידי ראש הקבוצה שתפקד כראש צוות זמני. יש סיבות טובות לעיכוב הזה במינוי ראש צוות קבוע - כשלוקחים סטארט-אפ ברמת תפקוד ישראלית סטנדרטית ומצרפים אותו לתאגיד אמריקאי לא קטן, יש לא מעט שריפות שצריך לכבות בכל מיני צוותים, יש אנשים אחרים שעוזבים וצריך למלא את התקן שלהם, וצוות קטן וחדש שלא גוזל המון קשב ניהולי ובונה את עצמו בשקט יחסי בינתיים הוא לא הבעיה הכי דחופה. חוץ מזה, כמו שיודע כל מי שניסה לגייס אנשי בדיקות - השוק מלא במועמדים לא טובים מספיק, והדבר נכון שבעתיים לגבי ראש צוות. וכן, אני מניח שגם לזה שהייתי שם כדי לסתום חלק מהחורים שהיעדר מנהל משאיר בדרך כלל עזר קצת להפוך את המצב לנסבל. חוץ מזה, בשנתיים האחרונות הכל התנהל לפי סדר עדיפויות אחר לגמרי בכל המדינה. בכל מקרה, הדבר הכי נכון כדי למלא את המשימה שלי - להקל על המנהל שלי ולעזור לו להשיג את המטרות שלו בארגון - היה לקבל ניהול פורמלי של הצוות. אני לא בטוח אם קראתם את הפוסט של תומר על תסמונת המתחזה אבל הוא לגמרי צודק - תסמונת המתחזה אף פעם לא הולכת, גם לא אחרי עשור של חיזוקים חיוביים, למידה והצלחות בעבודה. ידעתי שעדיין לא פיתחתי את הכישורים הדרושים לעבודה החדשה, ושאני אפילו לא יודע עדיין במה היא שונה מהתפקידים הטכניים שביצעתי קודם.  מה שכן משתפר עם הידע והניסיון הם מנגנוני ההתמודדות עם ההרגשה הזו - אחרי התחושה הראשונית של "שיט, למה נכנסתי?" מנגנוני החשיבה האיטית נכנסים לפעולה ואני יכול לשים לב לכך שזו לא רק חוויה מפחידה, אלא גם הזדמנות צמיחה מצויינת. או לזכור שאני אולי לא יודע לנהל, אבל היו לי גם מנהלים טובים וגם מנהלים טובים פחות, ושאני יודע לזהות חלק מהמאפיינים של אלה או של אלה, שלאורך השנים קראתי והקשבתי ללא מעט תוכן שכלל גם פילוסופיה של ניהול צוות ושבסופו של יום, יש לי מנהל ישיר שאני יכול להיעזר בו. בנוסף, גם הידיעה שעד היום האסטרטגיה של fake it until you make it עבדה לי היטב, ושהחלקים נרחבים בעבודה היומיומית הם דברים שהתנסיתי בהם בעבר - כמוביל טכני יצא לי לעזור לאנשים לפתח את הכישורים שלהם, לכוון את העבודה הטכנית , לבנות backlog של משימות ואפילו לשבת לשיחות 1X1 עם אנשים. יש עדיין לא מעט חלקים חדשים, כמו לדעת מה עושה כל חבר צוות, או להעריך את תפקוד הצוות והחברים בו ולשפר אותם, או לתת פידבק לאנשים גם כשהם לא מגיעים אלי כדי לבקש אותו, אבל אני יכול להישען על החלקים שאני כבר יודע לעשות כדי ליצור איזו שגרה בתוכה אני יכול לתת שירות טוב מספיק בעודי משפר את החלקים החדשים ומגלה מה עוד אני לא יודע. זה גם עוזר שאני יודע מה אני רוצה לעשות כמנהל - אני רוצה לקדם את הרמה המקצועית בצוות ולתת לעובדים סביבה בה הם ירגישו שמקשיבים להם, ושהם מתפתחים ומשפיעים. אני רוצה לפנות להם את הזמן לעבוד ולא להתעסק בשטויות מעבר למה שצריך' ואם אפשר, לתת להם להתמודד עם משימות שיאתגרו אותם בדיוק מספיק כדי לצמוח.

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

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

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

Hi again

 It's been a while since I last wrote here. A bit over a year, in fact, and I have many excuses. Truth is, some things have caught my attention and I dropped the habit of writing here, I think I want to catch up again on it. 

One of the things that happened in the past year, is that I was asked to lead the team I was in. Becoming a manager was something I have avoided so far since I was in a position to enjoy most of the fun parts of managing without the tedious or annoying parts. It was also an inertia thing - I started wanting to avoid managing at almost all costs, and having expressed that clearly and loudly, people around that kept assuming this was my position even when I started to warm up to the idea in the past few years when I got to experience more of the fun parts about managing. 

I officially started last April. By then, I was about 9 months into my new place, and my team was being managed by our group leader as an interim team lead. There have been a lot of reasons for this delay - we were a start up acquired by a corporate, there were other teams that needed attention, and finding a decent manager for a testing team is a difficult task. There were also external factors that took our attention. So, true to my claim of doing my best to help my manager in whatever way - I agreed to fill the gap. Despite having over a decade of good (and bad) managers, of functioning as a tech lead and mentoring team members, I felt unprepared for the task. After all, it's the first time that other I had such a direct impact on other people's careers. It is now up to me not only to provide guidance when asked or when I feel like it, but to actively evaluate the skills of the team members, identify gaps in the team and have a plan to fill them. It's also the first time I needed to define future plans that were not relying solely on my execution abilities but had to factor in the ability of other people to complete their work, based on their skills that I have no idea how to evaluate. One advantage I did have is that I knew, in theory, what was important for me as a manager. Specifically, I want to focus on nurturing my team into one I'll be proud to be a part of (which, to be frank, was not the starting condition, and was one of the reasons I was asked to join and then to manage) and my way of doing that is to try to provide my team members with what I got from my good managers and what I was missing from the less proficient ones - a sense of direction (what should they be doing next and why), coaching on their tasks - including feedback and help when needed, but allowing them to stretch their skills and a safe environment where they'd know they are heard.

Knowing something in theory, even if I  read about it in a book or a dozen, is very different than actually living up to it. I found out how difficult is to tell someone they need to improve without getting them defensive is a challenge, and keeping tabs on who does what at any given time is a lot even with just four people in my team. Add to that maintaining a backlog for the team, some code reviews and still taking a task every now and then, and I'm stretched pretty thin. On top of that I still need to raise my head above water and take the long-term view, which is a skill I'm still learning. So, great fun all around. 

As is my approach with most tasks in the recent years, I'm building from the things I know - I'm ok in coaching and in the technical aspects of the work,  I had the chance to practice one on ones in my previous workplace and for some odd reason, I'm good at making people think I listen to them (even when I don't, but I am honestly trying), I am also relying on my manager to take care of  some aspects I don't have the attention span to do now such as figuring out whether we have need for another person on the team or forcing me to stop and consider whether the work we're doing is effective. 

It's a new experience for me, and it really makes me wonder - it's not uncommon to see people transitioning to the management track early on in their careers - how much impact does this have on their technical abilities? I'm in a relatively relaxed situation - not a lot of team members, our deadlines are meaningful, but they don't  threaten to run the company out of business if we miss them, and still I find very little time to dedicate to the technical aspects of work, and mostly rely on the skills I've built in the past  decade or so.  Can a manager without such experience transition back to an IC role if they don't have such a foundation? It really makes me reevaluate the way I interpret CV's - managing a team, even a small one, strengthens a lot of leadership and bureaucratic skills, but even when being super involved in the technical aspects, it's still fairly limited. While I have no doubt that if asked, people in my team will say I'm into every detail of their work, that's true only in the superficial sense - Hopping around that many topics is preventing the deep diving into details needed for true work to happen - so I comment, I skim occasionally, and mainly - I rely on the tasks beings similar to ones I've done dozens of times, so I can seem to know what I'm talking about and still bring some value with low effort. 

Anyway, I'm not sure there's a message or a point to this post, I manly wanted to say hi again, and tell I'll be back to writing here. At least until I pick up the habit again,  I don't expect to write more than one blog a month (you'd be amazed how much time it takes me to write the same post in a 2nd language), but I'll try to keep at least to this pace.