Monday, June 12, 2017

Nordic testing days - closing it all up

So, second day of NTD 2017... The scary part where I get to speak. At least, it was directly after the keynote, so I would have most of my day worry-free. 
Fiona Charles's keynote raised an important matter - As testers we should be responsible for our ethics - both towards the company that hires us, but more importantly, to the public that our product affect, and to ourselves. In a perfect world, everyone would be doing the right thing, so there will be no ethical dilemmas. Sadly, our world is not perfect, and we are asked to lie, or help in covering up information, or take part in a product that we think is morally inappropriate (my personal "no way I'll work there" include gambling sites, porn and most ad-services). In such cases, we have to know when to say "no". "No" to lying. "No" to deception. Also, it is very important to know that there are levels of saying that no. Most of the times, this no should be voiced internally - Letting the product owner know that the tests indicate a very high risk in releasing the software, asking again if we are comfortable with *this* business decision, going over your manager's head to make sure your concerns are not ignored irresponsibly, even resigning when you think the company is acting immorally (but not illegally) . Sometimes, when there's something more serious is on the line, it means that we should notify external entities - turn the external auditor's attention to the flaw that might cause a safety-critical component to malfunction, anonymously tipping the police when acts of fraud are being sanctioned by the CEO,  or even going to the media to reveal how irresponsibly the company is handling their user data despite all warnings and attempts to fix this. 
My main takeaway from this talk is that it's always easy to know what is the right thing for others to do. Especially in retrospect. Knowing the right thing to do yourself, and having the courage to do so - is not always that simple. Let's hope we won't face such dilemmas ourselves. 

Then, after the break, there was my talk. Was I nervous? yes. I think it went well, and some of the questions I got at the end indicated that my message had indeed reached at least some of the audience (my message, in short - threat modeling is very much like testing, so go and do that. 

After that, I could enjoy the rest of the conference worry-free, and went on to listen to some very good talks (such as Carly Dyson's talk on her insights from being a consultant, Melissa Marshall's thoughts about integration tests or Gwen Diagram's talk on logging and monitoring). 

Finally, was the closing keynote. Usually, I really like the keynotes - where you get great speakers with ideas that are inspiring and thought provoking. This one, sadly, was neither. The speaker, Kristjan Korjus, showed us a really interesting product - a robot that is meant to facilitate "last mile delivery" and make delivery a lot less expensive. It is, to borrow the Cynefin terminology, a very complex situation, and thus probably the most interesting situation, when the way forward is by probing fast and learning in retrospect, so I'm assuming that any of the directions there could have made out a great keynote that will give people something to take home except "oh, look, a cute robot". Instead, we got something that looked a lot like a sales pitch, and I'm not even sure who is supposed to buy what. 

Anyway, after the keynote and thanking the amazing conference team for their magnificent work we've moved to a nice bar for the after-party, where we got to say goodbye to those flying soon after the conference ends, and chat a bit more over dinner with those that were staying another night.
Yes, naturally we met a bit more with people at a(nother) pub for some more chats and fun. 

The last day where I could say it was still a bit conference-y was when we met the next morning for breakfast and final goodbyes. I then went with Sven for a day-trip in the countryside (where I took the picture you can see above). A really nice way to take a slow cooldown from a conference. 

So, all in all - it was a great conference. A lot to consider, great experiences and even greater people. If you are making a list of conferences you want to attend, this one should be very high on your list. 

Friday, June 9, 2017

Nordic testing days - day 1

So, the tutorials day is over, and the first day of talks began.
For starters, it was a lot more crowded. With ~500 attendees, it's the largest testing conference I attended, and the atmosphere is absolutely electrifying. A lot of things to learn and experience, and a whole lot of new people to meet.
With so much going on, I could probably babble about the experiences I had for quite a while, but instead I want to pinpoint some of the highlights of the day.
First to be mentioned is Franziska Sauerwein's workshop on refactoring JUnit tests. I'm quite comfortable with Java, so I came with the expectation of learning new coding habits by watching other people's (in this case - Franzi's) way of coding. And indeed, that is mostly what I got. The workshop went pretty well, at least as far as I can determine, and I got out with several pointers on how to improve some of the code I am writing (also, need to check Hamcrest, with which I was not familiar before). A workshop that makes a very clear promise, and then delivers it exactly.
Similarly, Kevin Harris's talk about losing third of the testers and surviving that. When a crisis happens, you must adapt, and Kevin shared with us some of the extreme measures they had to take to cope with this change. Some of them, probably, are better off when done with the luxury of time at hand - and even if they don't, they sure seem like the right thing to do (others, on the other hand, are crisis-only action, so I hope not to ever need them, but I'm stacking them in memory just in case).
The final keynote of the day was given by Alan Richardson, and was all about taking control of the way each of us treats testing. It was not a new message, but it sure was very inspiring and super important for new testers, while remaining not less important reminder to the rest.
And so, the day was concluded.
Or was it?
A conference dinner shortly followed, and then some sort of a party - with disco-lights and drummers. I took the chance to get some 20 minutes of quiet time before returning for the lightning talks and the Powerpoint karaoke - both of were real fun. I especially liked Gwen Diagram's lightning talk which was a very fast-paced,foul-mouthed ode to rapid development named "me and Mr. T".

A long day, and quite a fun one at that. Now, for the final day of the conference, where I'll be presenting my talk.
How did the Romans say? Ave, Imperator, morituri te salutant.

Thursday, June 8, 2017

Nordic testing days - tutorials day

Today was the tutorials day at NTD, and what a lovely start for a conference it was.
Choosing a tutorial was really difficult (so I'm glad I've done that part when registering) - with the exception of "java for testers" that claims to cover stuff I already know, I simply couldn't tell which one I prefer going to. By the end, I chose Fiona Charles's workshop on heuristics. It started out really well, with a short overview of what heuristics are - and I do prefer her way of looking at it as "shortcuts" instead of the overly wide "fallible methods of solving a problem", since it narrows the field at least a bit. My main difficulty with "heuristics" is that it can be used to describe just about anything people do, and using "shortcuts" narrows the field of discussion to useful heuristics and enables some sort of a meaningful discussion about it.
Before lunch, we played some children games, and tasked with the goal of finding some heuristics to solve the puzzles and track our heuristics as they changed over the exercise. What really got me was that none of the initial heuristics we tried to apply first held true, and soon after starting to actually solve the puzzle. Doing something only because it seemed to make sense in the past is not necessarily a good idea. The cool thing in this, though, is that heuristics that are not helpful were als really hard to follow for a longer period of time.
The second part of the workshop started by watching this video and being asked "what heuristics would be useful for testing this, if all the information that you have is this video?" Well, that was tougher than I thought it should be. Armed with the (tacit) knowledge that coming up with heuristics before actually doing some of the work would not necessarily be productive, we got to the task of coming up with test ideas and filling the information gaps we had with assumptions. After doing that for a while, we've tried grouping the test ideas to similar categories in hope of distilling it to a point where it would be easier to notice some of the heuristics we were using - that didn't go as well as I thought it would, since we found ourselves looking at a checklist (which is a great heuristic by itself), and not really knowing what was leading us. In the latest 3 minutes or so of the exercise something clicked and we were able to detach ourselves enough from test-idea generation, and look at how we were doing that. Our main heuristic to generate ideas was using scenarios (or use-cases, if you would prefer), which had a lot to with personas (the phrase "redneck with a crowbar" did come up once or twice). I could totally see how naming those heuristics could help me get a better coverage given some more time, but as it usually is in workshops - time is of the essence.

The day ended with speaker's dinner, which started in the cute train you can see at the top. quite a nice way to get to where we wanted - it started with a toast on some sort of a balcony, overseeing the beautiful Tallinn, followed by a medieval-themed dinner (in a dark, candle-lit restaurant), after which we were dragged to a bar to try out something called millimalikas (or something of the sort, I heard it means "jellyfish" is Estonian, but did not verify that), which is two sorts of alcohol, one of which is anise-based (read: really disgusting) and some tabasco to make it painful. Thankfully, the tabasco  burn did eradicate the anise after-taste, but it is definitely not something I would repeat.
All in all, a packed day, which was a prequel to an even more packed conference.

Thursday, May 25, 2017

שמות עתיקים ומעלי עובש

names that get old and stale

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

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

One of the first things that are being taught at every introductory programming course is "choose meaningful names for your variables". Those names make your code more readable, and save hours of work. 
A small point that don't get mentioned enough, is that names deteriorate. Sometimes, the domain language we speak is changing and old terms become meaningless, sometimes, it a matter of duplication - After all, what's more sensible than naming the permission to deactivate the main flow of our product as "PERM_DEACTIVATE" ? and, if we have another feature enabling full deactivation, why not name it PERM_FULL_DEACTIVATION? Three years later, you'll find yourselves asking each time "when you say 'deactivate', which of the two do you mean?". 
This week I got to deal with another, nastier form of term deterioration. 
In our systems there are users. As can be expected, where there are users, there are also admins that can manage those users. One of them is called "admin-all". Originally (we believe) it was meant to create all kinds of users in our system. As sometimes happens in developing systems - more roles were added at a later phase, and no one updated the admin-all permissions (it might even be that it was intentional and not a matter of negligence). Eight years later (at least), a crisis happens! Customers are furious! managers are gathering over phone to discuss! Chaos is reigning!
I won't bother you with the exact details of the problem, I'll only mention that we needed to provide someone with an admin that can create all other users. "Well, easy", I said. "Just give them an 'admin-all'". All the other people in the conversation, all of whom have more years of experience with the product than my mere 5 years, voiced their agreement. Yep, that's the user we need. Each and every one of us have encountered at least once in the past the gap between the claim "admin all" and the actual privileges, so when a short check we did showed that some privileges are missing, all of us had this "oh, right, I forgot" moment. 

I don't really have deep insights from this story, except, perhaps - make sure to maintain the names you choose, and update them if you have reason to. It saves confusion and mistakes later. 

Sunday, May 7, 2017

My problem with the screenPlay Pattern


Like anyone who is even remotely interested in Selenium, I too heard about the new emerging "Screenplay Pattern" (you can read about it here, or watch this talk) and took some time to consider it. My first reaction was "I think it's a bit silly, writing all of this for no gain at all", then "It looks like more overhead and duplication than I currently have with page-objects". And then I forgot about it.
In Selenium Conf UK (2016) Antony Marcano gave a talk about it which I watched just since it was well presented, and I wanted to see if I could figure out why is there so much fuss around this pattern. It turns out that the screenplay pattern is simply branded incorrectly, and presented as a (complex) solution to a problem that should be solved in a simpler manner. Apart from that, though, it is a really useful tool to have in my utility belt, after fixing the fundamental flaw it has, of course.
To put things simply - The screenplay pattern is not a good substitution for decent page-objects and, in fact, should co-exist with them.
If you read my previous posts about "page-objects are not enough" (pt.1, pt.2) then you might have noticed that I advocate for a layered infrastructure for your automation. Personally, I see three layers that are really needed (Alex Schladebeck is splitting it to 5 distinct layers, which might be a good idea, depending on your context). The three layers I need are: Tests, Business actions (or "flows") and atomic actions.
The atomic actions are stuff like "click on the 'next' button" or "select all users from the database" (In Alex's model, there's a lower level layer which will do "click on something" or "run this SQL query" - a layer very important if you have multiple technologies to drive your actions).
However, atomic actions are not really helpful for your day to day test, so the second layer is created - the business actions. Here you'll find stuff such as "add a new user", "change password" and so on. Business actions are the place to put the context knowledge in - today logging in requires a username and password. Tomorrow it might require an one-time-password sent by SMS. the business action is the place to invoke the specific atomic actions that compose the actual action (Again, in Alex's model, this is split into two layers - internal and external. I think it's nice that she made this distinction, I don't think it's crucial in my context).
Finally, there's the tests themselves - They should be calling the flows layer, and even though some atomic actions might be used for assertions, as a rule of thumb - test methods should not be calling atomic actions themselves. When it get's to UI actions, this rule is more strict - your test should not contain any selenium code or any page-objects (the same is true for any sort of technology you might be using to drive your UI).

As I hope it's easy to notice - the screenplay pattern fits very nicely to that middle layer. Clear business actions that hide the actual steps taken to perform them. I can think of no reason not to include page objects within the screenplay actions, thus separating "how do I interact with an element" from "which elements should I be interacting with?"
This brings me to another point that was touched upon in Anthony's talk - Bloated page objects should not exist.
By separating the responsibility (the "which" from the "how") , most of this is solved - a page object should contain only the elements in it and a way to interact with each element. Perhaps we might go as far as aggregating filling up an entire form, but anything more complex than "login" should be dealt with in the flows layer. By doing this and keeping the page-objects representing small pieces of the UI , no large classes are created, and the flows layer (where the screenplay pattern is really helpful) remains clean and without unnecessary duplication when two actions go through the same pages.


כמו כל אחד שמתעניין קצת בעולם של סלניום, גם לי יצא לשמוע על הדבר הזה שנקרא screenplay pattern (אפשר לקרוא על זה כאן או לצפות בהרצאה הזו) ועצרתי לחשוב על זה. תכל'ס? התגובה הראשונה שלי נעה בין משיכה בכתפיים לתהייה בשביל מה צריך את כל התסבוכת הזו - נראה שבמימוש סטנדרטי של התבנית הזו אני אסיים עם שכפול קוד משמעותי יותר מאשר יש לי כרגע עם page-objects. נו, מילא. קראתי, סיווגתי, המשכתי הלאה. 
בשנה שעברה, בכנס סלניום, Antony Marcano העביר הרצאה על התבנית הזו (נו, אותה הרצאה שקישרתי אליה שם למעלה), וצפיתי בה, בעיקר כי הוא העביר אותה היטב, אבל גם כי רציתי לראות - אולי אצליח להבין מה ההתלהבות הגדולה מסביב לזה. 
ואכן הבנתי משהו - כל סיפור התסריטים הזה (בפוסט הזה, לפחות, אשתמש ב"תסריט" במקום screenplay, כי זה נוח יותר להישאר בעברית) פשוט משווק לא נכון ולכן מציג פתרון מסובך לבעיה שעדיף לפתור באופן פשוט יותר. אבל חוץ מזה? נראה שהתסריטים הם משהו שכדאי להכניס לארגז הכלים שלי - אחרי שמתקנים את הפגם היסודי שבהם. 
בפשטות - התסריטים אינם חלופה טובה לpage objects בנויים כהלכה, וקל וחומר שאינם "הדור הבא" שלהם. למעשה, התסריטים צריכים לדור איתם בכפיפה אחת. 
אם יצא לכם לקרוא את שתי הרשומות שלי על page objects are not enough (חלק א', חלק ב'), בטח שמתם לב שאני ממליץ על אוטומציה שבנוייה בשכבות. בפרט, אני נוטה לחשוב על שלוש שכבות נפרדות (Alex Schaldebeck מציעה חלוקה לחמש שכבות שונות, מה שעשוי להתאים לפרוייקטים מסויימים). שלוש השכבות שלי הן שכבת הבדיקות, שכבת הפעולות העסקיות ושכבת הפעולות האטומיות. 
הפעולות האטומיות הן פשוטות - לחיצה על כפתור "הבא", שליפת מספר המשתמשים ממסד הנתונים. דברים כאלה (אצל אלכס יש שכבה בסיסית יותר בה יופיעו "לחיצה על אלמנט" או "הרצת שאילתה מול מסד הנתונים" - שזו שכבה חשובה מאוד אם יש לכם כמה דרכים לבצע את אותן פעולות אטומיות בסביבות שונות). 
עם זאת, פעולות אטומיות לא ייקחו אותנו רחוק מאוד - ולכן נולדה השכבה השנייה - שכבת הפעולות העסקיות. לפונקציות כאן כבר יש משמעות בעיני המשתמש. זה לא "לחץ כאן" "מלא את השדה הזה" אלא "הוסף משתמש חדש" או "החלף סיסמה". הפעולות העסקיות הן החלק בו נשים את הידע המוצרי - איך עושים דברים. הרי היום כניסה למערכת דורשת שם משתמש וסיסמה, אבל אולי מחר הכניסה תתבצע בעזרת סיסמה חד פעמית שתישלח במסרון. הפעולות העסקיות הן המקום ממנו נקראות הפעולות האטומיות, והן המקום בו מוגדר מה הפעולות האטומיות שצריך לבצע כדי להשיג תוצאה ספציפית (שוב, במודל של אלכס זה מפורט יותר ומחולק לשתי שכבות - חיצונית ופנימית. זו אבחנה שכדאי לעשות, אבל אני חושב שהיא פחות קריטית ברמה העקרונית). 
לסיום ישנה שכבת הבדיקות - כאן נכתבות הבדיקות בעזרת הפעולות העסקיות. למרות שניתן מדי פעם לקרוא לפעולות אטומיות לצורכי אימות (assertion), כלל האצבע הוא שהבדיקות קוראות רק לפעולות עסקיות.  כאשר מדברים על אוטומציה של UI, הכלל הזה צריך להיאכף בקפידה  - בבדיקות לא אמור להיות קוד של סלניום, או של page objects (והדבר נכון לכל טכנולוגיה בה אתם משתמשים כדי לגרום לממשק הגרפי לזוז). 

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

Tuesday, April 18, 2017

שתיים ועוד שלוש הן חמש

Two plus three is five

Source: Every conversation between a parent an a child in four conversations (link in the text)
- אני יכול את זה?
- לא? 
- אולי לא הסברתי את עצמי היטב, ביקשתי כי אני רוצה את זה. 
- למעשה, הבנתי.
- אולי אינך שומע אותי היטב, אני רוצה את זה.
הקטע הזה ממשיך עוד קצת (והרבה יותר מוצלח בלי התרגום החובבני שלי) ואפשר לקרוא את כולו כאן (ומשם גם התמונה בראש. לאחרונה אני נזכר בטקסט הזה לא מעט. 
ואיך כל זה קשור לתוכנה? זה לא סוד שיש לפעמים פערים בתקשורת בין מהנדסים לבין האנשים שמנהלים את הצד העסקי של הדברים - אנשי מכירות, מנהלי מוצר וכדומה. הפערים הללו מתבטאים לרוב בדרישות מורכבות, לוחות זמנים בלתי אפשריים או סתם בקשות חסרות פשר. בערך כמו שקורה למומחה הקווים האדומים (וכן, גם בסרטון הזה אני נזכר לא מעט, באותו הקשר). 
בעבודה, יש לנו פרוייקט חדש. יש לו תאריך סיום שלא אנחנו קובעים, קצת כמו שתעשיית המשחקים לא קובעת מתי בדיוק תגיע עונת החגים. הפרוייקט היה צריך להתחיל לפני הרבה זמן אבל בגלל עומס של דברים דחופים לא פחות, לא באמת התחיל לזוז עד לפני חודשיים-שלושה. במהלך הזמן הזה, הקדשנו המון זמן לישיבות אינסופיות בהן מנהלי המוצר ניסו להבין איך אנחנו יכולים גם לא לאחר בשנה וגם להכניס פנימה את כל התוכן שאנחנו רוצים. תוכניות נכתבו, שעות הושקעו בהערכת מאמצים, מדי פעם נערכו כמה חשבונות בסגנון "אם נשים עשרים אנשים על הפרוייקט, נסיים אותו בתוך תשעה חודשים" (מה שהזכיר לי את הבדיחה על מנהלי פרוייקטים והריונות), מה שהוביל לכל מיני משחקים בהם עובדים חדשים הופיעו יש מאין, משל היינו בתרגיל צבאי ומנהל הפרוייקט הוא השליש שמשלים את מצבת הלוחמים במטה קסם, תוך התעלמות מוחלטת מכך שלוקח לנו לפחות שלושה חודשים לאייש משרה.
בקיצור, למישהו היה כיף, והמישהו הזה לא היה אני. אבל, סוף כל סוף, נגמרו הקשקושים ואפשר לומר שאפשר להתרכז בעבודה ולא בתכנונה. ואז, במסגרת אחת מישיבות העדכון, מנהלת המוצר הודיעה על שינוי כיוון - אחד הספיחים לפרוייקט הזה הוא שיתוף פעולה בינינו לבין חברה אחרת, ושיתוף הפעולה הזה אמור להכניס לא מעט כסף לכל הגורמים המעורבים. כל התוכניות שנעשו עד כה הניחו שאנחנו יכולים לסמוך על כך שסיימנו את עיקר הפרוייקט הראשי ולהשתמש במה שנבנה שם, מה שמיקם את הספיח במרחק יפה על לוח השנה. ובכן, שינוי הכיוון היה כזה - הנהלה החליטו שאנחנו רוצים את הספיח מוקדם ככל שאפשר. רגע, מה? זה אומר שכל העבודה שצריך לעשות לפרוייקט הראשי ונדרשת כדי לתמוך בספיח צריכה להיעשות קודם. כלומר, כל מה שחסכנו הוא חודשיים או שלושה. תגובת מנהלת  המוצר הייתה פשוטה, ומרגיזה להחריד - "זה לא מספיק טוב, אני צריכה תוכנית שתאפשר לנו להעלות את זה לאוויר בתוך חודשיים מהיום". אוקי, אנחנו מכירים את המשחק. בטווח של חודשיים לא רלוונטי לדבר על תוספת משאבים, ואם התאריך נעול, כל מה שנשאר לדבר עליו הוא על התוכן. אבל גם על התוכן אי אפשר לוותר, כי את כל הוויתורים כבר עשינו כשהגדרנו את הפרוייקט הראשי. בכל זאת, בדקנו - "האם את מוכנה לוותר על א'?" "לא". כך גם לב' וג'. בקיצור - איך שלא מסובבים את זה, הבקשה היא לדחוף תשעה חודשים קלנדריים (לא חודשי אדם) לתוך שלושה. התגובה לכל הסבר שמצביע על הפער הזה הייתה "אז תעשו משהו מהיר ומלוכלך" (עד לנקודה בה אחד המפתחים הסביר שאנחנו אמנם יכולים לכתוב את הקוד מלוכלך יותר, אבל יותר מלוכלך ממה שכבר מתוכנן לא יהיה מהיר יותר).
אני יצאתי מתוסכל מאוד מהישיבה הזו, מקטר ביני לבין עצמי שזה לא משנה אם סופרים שתיים ועוד שלוש או שלוש ועוד שתיים, ואפילו לא שתיים ועוד שתיים ועוד אחת - התוצאה תמיד נשארת חמש ולעולם לא תהיה ארבע.

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

Child: Can I have this?
Me: No.
Child: Ah, perhaps I’ve miscommunicated. I’m asking for it because I want it.
Me: I understood that, actually.
Child: I think maybe you’re not hearing me. I’d like it because I want it.

This quote is from a longer text that goes on (and gets funnier), which you can read here. Lately, I'm reminded quite often of this text. 
And what does it have to do with software, you wonder? Well, it's no secret that there are sometimes gaps between engineers and business people - salespersons, project managers etc. . Those gaps often manifest as complex requirements, impossible timelines of simply senseless requests, as is happening to this poor red lines expert (yes, I'm reminded of this video as well, in the same context). 
We have a new project at work. It has a deadline that we do not set, in the same manner that the gaming industry cannot move holiday season just because the game is a bit more complex to build. Worse - this project should have started quite a while ago, but a load of other urgent tasks didn't actually begin to move until about three months ago. So, what's the first thing to do when you start a project late? Naturally, begin with a month-long estimations and planning phase. Ok, I'm being a bit over-sarcastic here, as the planning was quite important for us to know what we actually need to do, and start having a discussion about what must be released in the first deadline of the project and what can wait a bit, so there was value to it, but it was just so annoying to go through.  During those endless meetings, the product management goal was to understand how can we get all of the content that we need and not miss our scheduled release date in a year or certain times there were some calculations such as "if we'd put 20 people on the project, we could be done in 9 months". This reminded me the joke about project managers and child bearing and then I was reminded of some war-games where dead or injured soldiers are magically replaced by other troops when the discussion started guessing that we could assume we'd recruit three new employees within the next couple of months, ignoring the history (in which finding a suitable candidate usually takes us between 3 and 6 months during which the effectiveness of the employees interviewing drops sharply).
So, to state it simply - someone was having fun, and that someone wasn't me. But, finally, we got to the point where we can shift our time and focus from talking to doing. great. Then, during one of the update meetings the project manager announced a change of direction: One of the side tracks to this project was another sub-project that depended on many of the capabilities in the main project. This  sub project is a collaboration between us and another company, and should produce a nice revenue to all involved parties. So, instead of waiting until the main project is done, now we want to have the sub-project done as quickly as can be, so all of the work that had to be done in the main project and supports the sub project now have to be done separately and all that we would save is probably two or three calendar months. The product manager's response was simple and frustrating: "This isn't good enough, I need a plan that will enable us to go live with this in a couple of months". OK, we know this game - it's the triangle of resources\time\content.  Since it's a schedule of 2 months, adding people is not really an option, and the time is set, so it must be content. However, we already cut content to a minimum when defining the main project. Still, we asked "Are you willing to give up on A?" the answer was "no, we must have A", and the same went for B and C. In short, we were asked to find a way to cram some 9 calendar months into 3. Doesn't really matter how you do the math, it does not work. Any attempt to explain this was met with the response "just do something quick and dirty". This phrase came up so many times in the conversation that one of the developers reacted with "we can do it as dirty as they want it to be, but at the point we are, dirtier won't be quicker".
Personally, I got out of this meeting feeling very frustrated and ranting to myself that two and three is five, as is three and two, and even two and two and one - it does not matter how you count it, it won't stop being five.

But, later that day something interesting happened. After we were done ranting and got used to the fact that this new requirement is the reality - we need to do something in three months, what can we suggest?  - we came up with a solution: it solves only part of the problem, and it depends in our partner's capabilities and goodwill, but we can do it in a single month. We have something management can work with.
This made me think - It's really easy  to rant about how management knows nothing, It's easy to be annoyed with impossible schedules. But the whole purpose of a delivery team is to find solutions to problems. Those won't always be perfect or complete (or on schedule), but they are still good solutions. Sometimes, that little annoying brat who says "I want it!" and won't take no for an answer is what needed to nudge the team to find a solution.

Also, on another note - you people who preach #NoEstimates , how do you cope with projects of this size that have a deadline and you need to know whether or not you should recruit more people? If there's something these last months convinced me it's that I really don't enjoy estimating stuff. I would love to hear of another way of dealing with this problem. 

Wednesday, April 12, 2017

מה אני מחפש אצל מועמדים

What do I look for in a candidate

This post is written after James Thomas, who has a fascinating blog of his own, commented on this post and pointed out that I did not mention what I was looking for when interviewing candidates, and why. And, since to the best of my knowledge, James does not read Hebrew, I'm starting this post with the English version. 

Generally, we are trying to get an understanding about the following points:

  • Testing skills
    • System-wide view\ understanding
    • Technical affinity
    • Asking questions and questioning authority. 
    • Identifying context and understanding what does it mean for testing. 
    • Risk awareness (and tendency to spot risks)
    • "Thinking on your feet" 
    • familiarity with testing theory & terminology. 
  • Programming (roughly at the skill level of a university graduate)
  • Interpersonal skills
  • Career goals
      Each of these points can be broken down to smaller parts, and in some cases, those parts can be broken down again. And breaking those definitions is exactly what I'm about to do.

      • Programming - probably the easiest thing on this list to explain. We expect the candidate to be able to write code, we don't care in which language. We look for the ability to come up with algorithms that solve simple problems, some basic understanding of data structures, good coding habits (e.g.: meaningful names, division into functions) and while it's not a must, we sometimes also try to see if the candidate has some idea about what is happening in the memory below the code (not registers and assembly language, just an understanding of the stack, heap and garbage collection).
        Why are we looking for that? In short - because we use programming in our work. No, we are not "automation engineers", but we do write automated checks in a framework that we built and maintain (and I'm even somewhat proud of). Learning to code on the job is possible, but it's way too expensive for us to accommodate that. In addition, formal learning in this case will be more thorough and cover the things you need only once in a blue moon, but we're long past the point where one needs "just enough programming to manage", and a decent theoretical base is always helpful. Sure, one does not need 10 years of programming experience to work with us (in fact, universities graduates might  fit well), but sometimes there are problems that require some investigation and fiddling around. In a team as small as ours, we don't have the luxury of having this task within the skill-set of only part of the team. 
      • Interpersonal skills - A bit undefined, and can be roughly translated to "how much we like you". We look for people who are pleasant to talk with, won't cower in a corner in face of a loud voice. Into this category comes also the ability to explain oneself, to accept criticism and just about a million other things I can't exactly name, but can tell when they are missing.
        Why are we looking for that? First of all, because we look for people we would want to work with. I don't want to work with people I feel unpleasant around, so if I can affect that - I will. Secondly, because as testers, our work is all about communicating with others, so a candidate better not be horrible on this account. Third, and most importantly - We are quite of an aggressive team. We have some people in the team who respond fast and think while talking - which might push aside the more timid team members. Like it or not - and until we manage to change that - timid people will be run over, so when we assess the candidate fit for the team, this must be a parameter, even if it's only so that we'll know how much protection the candidate needs. Candidate who can hold the conversation when there is some cooperative overlap (I found this term here) and will not let themselves be pushed aside when the overlap becomes a bit competitive, will have easier lives in our team. One need not posses the glib tongue of a lawyer or a salesperson, but we prefer candidates who can join our team painlessly. By the way, this is more important for female candidates who will face unconscious gender bias on top of the general pushiness. 
      • Testing skills is a title for a long list of possible skills, and everyone has a slightly different definition of what it actually is. It's also an umbrella term for stuff we don't have anywhere else to put but deem important for a tester - stuff such as professional pessimism, familiarity with different kinds of testing (there's very little in common between performance testing to localization testing, despite the fact that both are "testing").
        Within this list, we try to focus on the following:
        • System-wide view: There are two ways in which systems can be understood: bottom-up, in which one learns all the fine details and slowly constructs the whole, and top-down, in which one learn how things are connected and what is the role of every part, and only later fills this schematic with details. The added value of testers is usually in putting the new feature in context - who will be using it? what other parts are affected? and so on. A person who learns in a top-down manner will probably have it easier to provide this kind of value, but in the end, it's about being able to see the system and zoom in and out as needed: if someone is very comfortable in the high-level descriptions, we'll drive to more technical details. If someone's very keen on the details, we'll push for a higher abstraction level. 
        • Technical affinity - Be as it may, we are testing software (or hardware), which is something technical. A tester should not be afraid of it, and should understand how computers work instead of regarding to it as magic. In addition, when something stops working, we dive into it and investigate, and this requires technical skills.
          (Also, if you're using "technical" as a euphemism for "knows to code", please stop. Thank you.)
        • Questions in face of authority: I hope I don't have to convince any of the readers that asking questions is one of the most important things testers do. The authority part is no less important. We ask questions that people don't like to hear such as "are you certain you want to release with this unfixed?" and sometimes we just call other people's baby ugly with questions like "will your solution still work when five people click on the button simultaneously? " There's always some sort of pressure against such questions, especially close to a release. A tester should not be too much intimidated by such pressure, and leave a question unasked only when there's a decent professional reason for that. Also, good questions that are based on understanding the system can save a lot of time and effort to everyone. 
        • Identifying context: This one's simple. We don't test everything the same way, and we don't test the same thing in the same way on a different project. Being able to justify our testing and prioritize them is important. A tester who can do that with no context is reading from a manual that was never relevant. 
        • Risk awareness & tendency to see risk: It's an extension to the previous bullet. Risk is what drives testing. If there is no risk, there's no need for testing. It also provides us with language to communicate with other team members - "I'm going to invest three days on this, since a minor defect will cost a whole lot of money, while no one will really care about the typos and spelling mistakes in the help file, so I'll go over it only if I'm really bored").  
        • Thinking on your feet: In many cases, a tester need to provide a quick response. For instance, if someone raises an idea during a design review meeting, the best time for a feedback would be right then, not after a week of analysis. In fact, in most situations I can think of, saying "here's my initial thoughts, and it seems to me that there's a week of analysis that can be done here to find out what I've missed" is by far more useful than "oh, really? Gimme a day to analyze and I'll tell you what I found". 
        • Familiarity with testing theory & terminology: Well, that's usually a probe to see if the candidate is familiar with some of the basic terms found in the ISTQB syllabus, maybe the difference between testing & checking or the ability to hold a short conversation about "why test?". Having a common language enables passing information precisely and concisely, but it has another aspect to it - behind each such term there's an idea. Once something has a name it can be easily recalled and used. Boundary values, for instance, is a really simple idea (which doesn't mean it's shallow) - but it's not something one will necessarily think about if they never heard of it before.
          In addition, being familiar with the jargon is a good indicator that the candidate is learning testing in some ways. There isn't anyone who is interested in testing and did not encounter some basic terms such as equivalence partitioning or a test oracle. From the experience I gained thus far, it seems that candidates that are not actively learning are not familiar with such terms. Sadly, it's true also for people who have recently bought their ISTQB CTFL certificate (and I say bought since learning or earning was clearly out of the question in their case. They passed the test, probably without cheating, and they didn't learn a thing).
        Why are we looking for that? Because we are hiring testers. Because we don't know how to teach stuff such as "system view" and while we can help people learn to stand their ground, it's not a short process, nor it is perfect (or fun to all involved parties). To put it simply - we are looking for employees, not offering training. We will be happy to hire inexperienced people, but they have to show us that they did the first steps themselves (or have some natural affinity to the testing mindset) to convince us that there will be value in investing in training them. 

    • Career goals: Here we try to guess whether the candidate is regarding software testing as a profession.  We try to understand what are the short term career goals of the candidate, and ask about the long term ones (we don't usually ask about the short term goals, since it's an invitation for a lie).
      Why are we looking for that?
      Two reasons: The first and only one that matters is that we have a long ramp-up period. Our product is carrying over fifteen years of history, and is quite complex. Usually we consider the first three months as pure training time, and don't really expect an employee to be highly effective in the first year. If a candidate will ask to switch role after a year (or worse - leave in favor of another place), we invested a lot and got little in return. Additionally, employees that are interested in testing will be more open to acquiring new skills in this domain. Employees that want to use testing as a stepping stone towards a different role will try to acquire skills that are relevant to that role.
      We ask for the long term goals for two reasons: One is to gain insight for the short term goals. The other is to see if we can accommodate such goals - Not everyone can be a manager, and if someone is keen on accessibility testing, there are better places for them to be in. A candidate that can only see progress as "becoming a manger" might need some guidance to find other options (unless specifically recruited to become a manager) in comparison to someone who is familiar with the technical career paths that are out there.
      The second reason is  a matter of ideology. I see testing as a profession and not as something temporary to do in order to "get into high-tech", or because someone lacks the skills to do what they actually want to do. I prefer to work with people who share this view. 

    • ------------------------------------------------------------------------------------------

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

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