שובך יונים Pigeon hole (אשרי אדם מפחד תמיד Happy is the man who always fears)

On October 24, 2016, in Syndicated, by Association for Software Testing

(Reaction to an English speaking source, so Hebrew will come later)

I listened to the Gem Hill’s latest episode of “let’s talk about tests baby” (Ep. 62), where she interviewed Neil Studd and they spoke about some very interesting topics – from motivation, to mental health, working 9 to 5 and coping & promoting change. It was a great episode that I will have to listen to again at least a couple of times to process everything that went there.
As usual, Neil is is always quicker than I am in posting something related, so you can read some background to this interview in his blog.

While I listened to the discussion I re-thought my views on 9 to 5 testers, and despite initially being pretty much in favor of the idea, and that there wasn’t a single argument voiced against this approach, I started wondering whether 9 to 5 really is a valid choice. Each and every argument for not doing anything work-related after work is sound and solid, yet somehow each such argument just enforced my gut feeling that it is only a valid reason to completely avoid participation if you don’t care.

But before I start, I just want to make sure that I’m clear on what I call 9 to 5 testers, since while I was writing this post I found that it’s not the hour cap that bothers me, but what I associate with this term. For me, a  9 to 5 tester is someone who comes to work every morning, leaves somewhere in the evening or even late at night, and have exactly zero interaction with a testing community. They might work 14 hours a day, but if they know only what they see in their own work, I call them 9 to 5 testers.
Another assumption I am making and don’t really feel the need to justify, is that testing is an intellectual work – which means that one must take interest in it in order to become really good. I’m not sure I would say that al 9 to 5 testers are bad testers  (though I am quite tempted to say that), but they sure can be much better.

I have mainly the projection of how I feel about my profession – I like being a tester. I think that when you do something you like, you cannot simply stop thinking about it when your shift is over. Just like any other subject – if you invest time thinking about it, you start seeing and interpreting other matters from that unique perspective – football (or soccer, as some of you might call this game) fans, for instance, will often borrow football terms to describe events or ideas that have nothing to do with football since the terms and thought patterns are readily available in their mind. This way, testing, if you care about it, doesn’t stop when we’re not at the office – we will still smile when we’ll see this car and still use insights we learned as testers, or use what we experience outside of work to improve our testing skills. When I can put something aside and say “I don’t do anything about it outside of the time I have to”, it means that I don’t care. Putting aside something I care about is a gradual process – I decide to do something else, then, after the third time I decide it’s time to wrap things up, I actually do that, and I will still occasionally think about it.

Neil & Gem mentioned some good and valid reasons for testers not to participate, but while each such reason sounds convincing, I found that I don’t see them as good enough to completely avoid participating. There were two distinct reasons I could identify: Having other commitments (such as family or other interests) and Being an introvert, which means one feels drained when socializing.
When facing those reasons as binary questions – there’s a clear cut: Work stuff should not trump one’s personal life, and forcing someone to overcome their discomforts and fears just because I say so is quite inappropriate. But the question at hand is not Boolean – it’s a scale, and there’s a world of difference between turning down the dial to a comfortable level and switching it off. I came to this understanding when I’ve heard Neil describing himself as an introvert, and mentioning that his way of coping with the massive energy drain at CAST was being the first one leaving in order to crash at the hotel (which, at least from my perspective, was completely invisible. I think I recall at least one evening where I left before him, simply since I wanted to get five or six hours of sleep). While I can’t really imagine how does being an introvert feels, since I tend to take energy out of interaction (which makes me an extrovert, I think) – but unless we take the extreme case of a person left in a state of acute lethargy or anxiety – Neil describes the  perfect solution: Moderate your participation level. One does not have to attend each and every event, and it’s perfectly fine to leave a meetup after an hour or so. It’s also ok to prefer small events where you can get to know people. And even if participating in any sort of event is extremely difficult, there are ways to participate online – Writing a blog, or commenting in a web discussion. You gain a bit less from written discussions, but it’s still a way to keep track on what’s going. People can just share something interesting they read with their team.
Having other interests that take time is a great reason to skip a specific event, or avoid taking on big commitments, but given enough time ahead and high enough priority, scheduling an evening event once every six monts or so is feasible. If someone says “I don’t mind going, it’s only that I can’t fit my schedule”, that person is saying “I don’t care enough to make time for it”. Someone with a tight schedule can still find time to do things that are important enough – it might not be as often as desired, but aiming for an evening once or twice a year is not impossible. There are also some events that take place during work hours – it will take a bit more effort to get permission to attend such an event, but it’s doable.

You might have noticed that despite my claim of not approving the “9 to 5” choice, I don’t expect everyone to start investing heavily outside of work – There will always be different levels of involvement between people, and that’s fine. I get to work every day on my bicycle, and I even enjoy riding a bit in the countryside in weekends. despite that, I wouldn’t call myself a bicycle enthusiast – I don’t own a 10,000$ bike, have no idea what’s the difference between the different brands and part names and I don’t spend my time in any biking forum looking for my next trail. Still, since it’s something I enjoy – I invest in it a bit. I own a nice pair of bike, I join a riding event once a year and siphon some knowledge about bicycle maintenance and stuff from my local experts. It’s a nice thing to talk about with others who bike. Similarly, a tester who has this amount of interest in testing is perfectly fine. I just find it really difficult to imagine such a tester remaining invisible – even such level of care should be visible at least to some of the co-workers around.


הקשבתי לפודקאסט של ג’ם היל (let’s talk about test baby), לפרק בו היא אירחה את ניל סטאד ובו הם דנו במגוון נושאים די מעניינים – ממוטיבציה ובריאות נפשית ועד התמודדות עם שינוי ובודקי תוכנה של תשע עד חמש (תשע עד שש בארץ). זה פרק מצויין, ואני כנראה אצטרך להקשיב לו עוד פעמיים לפחות כדי לעכל אותו כהלכה. 
כרגיל, ניל כותב מהר ממני, אז אפשר לקרוא קצת רקע על מה שהוביל לראיון בבלוג שלו.
תוך כדי האזנה, יצא לי לחשוב מחדש על הגישה שלי לאותם בודקי תשע עד חמש, ולמרות שמראש הרעיון נראה לי לגיטימי לגמרי, תוך כדי האזנה הבנתי שאני פחות ופחות מקבל את הגישה הזו. זה היה מעניין, כי כל הטיעונים שנשמעו היו מאוד בעד הרעיון הזה. פתאום, כל טיעון נשמע לי כמו “נכון, אבל בעצם…”
מה שכן – לפני שאני נכנס לעומק ומסביר מה מפריע לי, אולי כדאי להבהיר למה אני קורא בודקי תשע עד חמש: מבחינתי, מי שמגיע לעבודה בבוקר, יוצא ממנה בערב (או מאוחר בלילה) ולא מקיים שום אינטראקציה עם קהילת בודקים כזו או אחרת – הוא בודק של תשע עד חמש. כן, גם אם הוא עובד 14 שעות ביום. 
הנחת היסוד שלי היא שבדיקות היא מקצוע אינטלקטואלי – וככזה, מידת העניין של אדם במה שהוא עושה משליכה על הביצועים שלו. בודק תוכנה שלא מתעניין במה שהוא עושה לא יהיה בהכרח בודק גרוע, אבל הוא בהחלט יהיה פחות טוב מאשר הוא עשוי להיות. 
בגדול, יש לי בעיקר את החוויה שלי להציב מול התמונה של תשע עד חמש – אני נהנה להיות בודק תוכנה. כשאני עושה משהו שאני נהנה ממנו, אני לא יכול פשוט לעצור ולומר “עכשיו די”, כי האמירה הזו היא רק ההתחלה. בפעם השלישית בה אני אומר את זה אני גם קם ומפסיק והולך לעשות דברים אחרים. אבל אני לא מפסיק לחשוב על זה – מדי פעם אשקיע קצת זמן בלחשוב על הבעיה איתה אני מתמודד, או בלקרוא משהו קשור פשוט כי הוא מעניין אותי. חוץ מזה, כל תחום בו משקיעים זמן ומחשבה משפיע על הדרך בה אנחנו חושבים על תחומים אחרים. חובבי כדורגל, למשל, ישתמשו מדי פעם במונחים מעולם המשחק כדי לתאר מצבים שאין בינם ובין כדורגל דבר וחצי דבר. באותו אופן – תחום הבדיקות משפיע על שאר החיים של בודקי תוכנה – אובנו לפחות נחייך כשנראה (שוב) את התמונה הזו, ואנחנו יכולים להשתמש בכישורים שרכשנו במהלך העבודה גם מחוצה לה, בדיוק כמו שאנחנו יכולים ללמוד על בדיקות מאירועים שקורים לנו בחיים.

ניל וג’ם העלו כמה סיבות לא רעות בכלל להיות לא מעורבים יותר בקהילת הבודקים (יש יותר מקהילה אחת, אבל זה פחות חשוב לענייננו), ובפרט, אני חושב שאפשר לבודד את הטיעונים שלהם לשני טיעונים מרכזיים – חיים מחוץ לעבודה, והיות האדם מופנם (יש לציין, “מופנם” אינו תרגום מדוייק של introvert במקרה הזה, שכן לא מדובר בביישנות, אלא באנשים שאינטראקציה חברתית שואבת מהם אנרגיה, בניגוד לטיפוס המוחצן שעבורו מפגשים כאלה הם זריקת מרץ של ממש). אם מסתכלים על השאלות האלו כעל שאלות בינאריות, אין ספק שכל אחת מהן בפני עצמה היא סיבה מצויינת לא להשתתף. זה ברור לגמרי שאנשים צריכים לעבוד כדי לחיות ולא לחיות כדי לעבוד, ולהכריח מישהו להתגבר על חרדות, או לשנות את האופי שלו רק כי אני אומר שצריך זה מאוד לא לעניין.
אלא שלא מדובר פה בשחור ולבן, לא נכון להציב “לא משתתף” לעומת “משתתף”, כי השתתפות היא סקאלה די רחבה. אם מסתכלים על מידת ההשתתפות, יש הבדל של שמיים וארץ בין “משתתף, אבל רק מעט במידה שנוח לי” ובין “לא משתתף”. מבחינתי, רגע ההבנה היה כששמעתי את ניל מגדיר את עצמו כמופנם ומספר על החוייה שלו בCAST, בה הוא מצד אחד נהנה מאוד, מצד שני היה הראשון לצאת בכל ערב כדי לקרוס תשוש בחדרו (לי זכור לפחות ערב אחד בו עזבתי לפניו פשוט כי רציתי להספיק לישון חמש-שש שעות בלילה, כך שמבחינתי המופנמות שלו הייתה שקופה לחלוטין). תיאור הבעייה, למעשה, מכיל גם את תיאור הפיתרון – צריך למצוא את מידת ההשתתפות הנוחה, שלא יוצרת עומס אישי מוגזם. לא חייבים להגיע לכל אירוע קיקיוני שיש בסביבה, ולא חייבים לצאת לכנסים רב-יומיים. זה גם בסדר גמור להגיע למיטאפ ולצאת אחרי שעה-שעה וחצי. ואם המצב באמת קשה – אפשר להשתתף בדיונים אונליין – אפשר לכתוב בבלוג, או להגיב בדיוני פורום כאלה או אחרים (יש גם פייסבוק, אבל אני מתעלם ממנו בכוונה). כן, מקבלים קצת פחות מדיונים כתובים, אבל גם זה משהו. אפשר גם לחלוק עם החב’רה במשרד משהו מעניין שקראתם ולקשקש על זה כמה דקות – מעורבות בקהילת בודקים לא חייבת להיות מעורבות בקהילת בודקים מחוץ לעבודה.

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

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

How to kill UI regression testing: git source control (zagorski software tester)

On October 22, 2016, in Syndicated, by Association for Software Testing

TL;DR This is third part in series how to kill UI regression testing. It is about git source control system and its web application part, github, bitbucket or gitlab. I have already wrote about this topic in Product moving parts as a source for test strategy, and Micro tracking changes for regression test. In this post, … Continue reading How to kill UI regression testing: git source control

Making Fünf Myself (Hiccupps)

On October 22, 2016, in Syndicated, by Association for Software Testing

The first post on Hiccupps was published five years ago this week. It’s called Sign Language and, reading it back now, although I might not write it the same way today, I’m not especially unhappy with it. The closing sentence still feels like a us…

He Said Captain (Hiccupps)

On October 21, 2016, in Syndicated, by Association for Software Testing

A few months ago, as I was walking my two daughters to school, one of their classmates gave me the thumbs up and shouted “heeeyyy, Captain!”Young as the lad was, I congratulated myself that someone had clearly recognised my innate leadership capabiliti…

Interview with Olof Svedström, QA Chapter Lead at Spotify (Nicky Tests Software)

On October 19, 2016, in Syndicated, by Association for Software Testing

Olof Svedström has worked as an engineering lead within software testing and quality at Spotify for 5 years, during a period when he has been part of the journey where they have grown from 5 to 100 million active users and from 150 to 2000+ employees. Before Spotify he spent some years as a tester in a spectrum of companies, ranging from small product ones to international giants.

What does your role as QA Team Lead at Spotify involve?

Being a chapter lead (team lead) at Spotify is a people manager position and not e.g. a test lead position. I do very little to none test leading as the development is done in small development teams, each owning the responsibility for the quality of what they produce, with a QA in each dev-team. QA at Spotify stands for “Quality Assistance” and not “Quality Assurance”, we are there to help the dev team (as a part of it) to deliver.

The role of the QA is more of a coach and inspirer than a quality police/toll gate.   My role in this, as a people manager of QA’s, is to grow the team. Both by helping the people we have onboard grow professionally as individuals, but also hiring. I also work with explaining and teaching the view we have on Quality work to stakeholders in our vicinity when needed. As a side show I also spend some (limited) time as an individual QA-contributor in a dev-team, both because I can help, but also to have an ear to the ground and understand the real issues, problems and challenges we face. 

Spotify engineering model is fairly well known in the tech community, what’s it like, working as a tester, under this model? 

We strongly believe that developers care and should care about quality. Delivering high-quality products is a team sport. As a QA (being a tester is a part of what you do as a QA) you help the team with quality, but you don’t own it (more than anyone else in the team). This means that you can’t be the quality control-gate. Leaving that role behind can be harder to do than it might sound like. It takes some effort as a QA to not have full control of what goes out to the end-user, but to try to have that would be detrimental to true engagement from the others in the dev-team, and also slow all of you down immensely. 

As most of our teams deliver full-stack products the tech-stack you will need to know is vast and deep. Finding a level of knowledge you feel comfortable with might be hard, but keeping up a 100% with 6-8 world class developers within backend/frontend/mobile/data at the same time is impossible, so you need to accept to not know and understand everything. At the same time you need to know enough to help, so finding a balance is potentially tough. I would say that the role is very much up to you as an individual, only you will be fully able to see and understand what is your most important task at hand, how can you help the best at this point in time? It might not be (most often isn’t) pure testing, but could be process, stakeholder management, help with deploy and integration chains etc. 

Did joining Spotify change your perspective of testing in terms of how it can be done? 

I had worked in similar ways before joining Spotify, but the pace of change (software, organisation and process wise) was clearly higher here. To some extent the difference I have noticed over the years is how the model kind of works (sic!): have few but some QA and the rest of the org is forced/given a lot of the responsibility for quality and actually embraces it. Not everyone, and definitely not from day 1, but it definitely beats more traditional “quality police”-models. 

Spotify is one of the most used apps I’ve seen here in Sweden, seems like everyone has an account. Does being an actual user of Spotify change how you test? If so, how? 

It gives a sense of purpose, knowing you yourself really care about the product and so does your friends and family. At the same time you need to acknowledge that you are in some sense a superuser (and will complain about small issues that really isn’t a problem) but also don’t fool your self into thinking what you fully cover true user behaviour. Being a 40-year old Swedish suburb-living middle class man, I probably use and expect very different things from Spotify compared to a 15-year old teenager in Mexico City. 

What advice would you give to someone who is starting out their testing career? 

Do it, and try to tweak it! Don’t focus too much on learning the latest cool tools (they won’t be cool anyway in two years time), or try to grasp and write everything from unit to end-to-end system tests and all the things in between. 

Instead take the chance to try to understand as much as possible about how a development team (large or small) actually works, what are their impediments and how does it affect the quality of what they produce? Then, what can be done about it, and how do I as a QA do that?

It takes much more people- and social skills to have an impact than one might think from the start, but “just more testing” will too often only result in more issues reported somewhere in a tracker system (that no-one will care about, rather those reports will only slow everyone down).  Just don’t do it as a “this is a way to become a “real” developer”, and then do a half-dedicated effort.

Give it a chance in it self, you will learn so much about software development in general, things developers actually learn less about early in their career, experiences you will have immense use of when you two years down the line again evaluate what you want to do the coming years. Done right, you will have a great foundation to build on, knowing so much more about the true, full, life-cycle of a product.

REACT to Bugs (Assert.This)

On October 18, 2016, in Syndicated, by Association for Software Testing

The most common artifact that testers produce are bug reports. So what do you do when you actually find a bug? You react, here’s a mnemonic that may help your process… R eproduce The cornerstone of proving a bugs existence is if you can track down steps to reproduce it. Like ghosts, bigfoot, or aliens … [Read more…]

Leetspeak: My First Developer Conference – An Experience Report (Nicky Tests Software)

On October 16, 2016, in Syndicated, by Association for Software Testing

Up until yesterday, I had only gone to testing conferences – for me these were a safe familiar place. I was with my “own kind”.  So when my boyfriend asked me a few months ago if I wanted to go to Leetspeak, I surprised myself a bit by saying yes….

How to kill UI regression testing: development framework tests (zagorski software tester)

On October 15, 2016, in Syndicated, by Association for Software Testing

TL;DR This is second post about idea how to kill UI regression testing. In first post I described symptoms for UI regression testing that I would like to kill. I will describe development framework tests that are precondition for killing UI regression testing. Development framework tests (DEFRATE) are automated tests that are written by developers. … Continue reading How to kill UI regression testing: development framework tests

And Now Repeat (Hiccupps)

On October 15, 2016, in Syndicated, by Association for Software Testing

As we were triaging that day’s bug reports, the Dev Manager and me, we reached one that I’d filed. After skimming it to remind himself of the contents, the Dev Manager commented “ah yes, here’s one of your favourite M.O.s …” In this case I’d created …

Start Making Sense with Sensemaking – a #TheTestingShow Follow-up (TESTHEAD)

On October 13, 2016, in Syndicated, by Association for Software Testing

One of the primary reasons that my blog is not as frequently updated as in the past is that I have been putting time into producing The Testing Show. Granted, I could do a quick edit, post the audio and be done with it, but we as a team made the decisi…

Page 1 of 38612345...102030...Last »

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!