Hello! I know some of you have seen me around, but I’d like to take the chance to introduce myself. I am a newer member of AST, who not very long ago had context blinders removed, revealing what software testing can be. I’ll never go back to prescriptive process! Because I love an adventure, the AST Board […]
- הזדמנות לשמוע על מגוון נושאים מעניינים. כן, נכון. יש מלא נושאים מעניינים באינטרנט, עם וידאו באיכות נפלאה והיכולת לצפות בזה מתי שרק מתחשק לכם ולסנן את הנושאים שמעניינים אתכם בלבד. אבל מתי בפעם האחרונה ראיתם משהו במחשב בלי הסחות דעת באמצע? בלי הפיתוי לשים את השיחה ברקע ולעשות עוד שלושה דברים? זה קורה פחות עם אנשים אמיתיים. יתרון נוסף שיש להרצאות בכנס הוא שלפעמים אתם נכנסים להרצאה רק כי אתם שם, או כי כולם נכנסים, או כי אתם רוצים לשמוע את הדובר (או הדוברת), ומגלים הרצאה מפתיעה. זה מה שקרה לי בהרצאת הפתיחה של היום השני בCAST.
- הזדמנות לשאול שאלות – שמעתם הרצאה ממומחה שמתעסק בתחום שאתם מתקשים בו? לא הבנתם משהו בהרצאה בתחום חדש לכם? יש משהו שנראה לכם חשוב לומר? אם אתם נמצאים בכנס אתם יכולים לקום ולשאול. אם ההרצאה מוקלטת, ההערה שלכם תיכנס לשם לטובת הצופים. אתם גם יכולים לתפוס את הדובר לשיחה קצרה אחר כך.
- יש הרבה אנשים מעניינים שלא מרצים בכנס אבל מגיעים אליו. לפעמים תמצאו את עצמכם מדברים במשך שעה או שעתיים עם מישהו שרק פגשתם על נושא שמעניין את שניכם. או שתפגשו מישהו שמומחה בתחום בו אתם מסתבכים קצת (ועכשיו, כשיצרתם קשר, אפשר לשלוח לו דוא”ל עם שאלה קצרה או שתיים, או אפילו לשכור אותו כיועץ אם הוא עושה כאלה דברים).
- בכנס יש גם סדנאות – היתרון של סדנאות הוא בכך שאפשר גם לתרגל את הרעיונות החדשים. הסדנאות בדרך כלל לא יוקלטו, וגם אם כן – השתתפות בסדנה זה הרבה יותר מועיל מאשר לצפות בה. לא באמת לומדים הרבה מצפייה בלבד.
- לומדים מה קורה במקומות עבודה אחרים. יש לנו (או לפחות לי) מעין תחושה שאנחנו יודעים הכל, ומה שאנחנו רואים מסביבנו זה מה שכולם עושים. אבל המציאות די רחוקה מזה – חלק מהאנשים עושים דברים דומים, חלק נמצאים הרחק מעבר למקום אליו חשבנו שאנחנו רוצים להגיע, ואחרים נמצאים במקום בו היינו לפני חמש שנים. זו הזדמנות ללמוד מה קורה אצלם, ומה הם עשו כדי להגיע לאותו מקום (ואם מדובר בכנס מקומי, אולי גם נרצה לדעת אם מדובר במקום בו תרצו לעבוד). אולי סתם תשמעו במקרה על איזה כלי שמשתמשים בו ומוצא חן בעיניכם
- זו זריקת מרץ נהדרת – לפעמים העבודה היומיומית יכולה להיות שוחקת, ואם אתם היחידים במקום העבודה שמפגינים עניין בתחום מסויים (האחרים אולי מתעניינים בשקט בלי שאתם שמים לב) זה יכול להיות מעייף. בכנס תמצאו אנשים שאכפת להם מנושא הכנס. להיות בחברת אנשים אחרים שאכפת להם מוסיף המון אנרגיה.
- זה גם לא מזיק לצניעות – אם אתם אלו שמתעניינים בתחום באופן הכי קולני בסביבתכם, קל מאוד להתבלבל ולחשוב ש”אני הכי טוב בזה”. בכנס יש לכם הזדמנות לראות אנשים טובים לא פחות (חלקם יהיו טובים יותר), וללמוד מהם, או לפחות להפנים שיעור זריז בצניעות.
- זו הזדמנות לקדם את עצמך – לא כולם מרצים בכנס. למעשה, הרוב אינם מרצים. ועדיין, כנסים מספקים מקום להציג את עצמכם בפני המשתתפים האחרים – בחלק מהכנסים מספקים במה להרצאות ספונטניות מהקהל: אלו יכולות להיות שיחות בזק (lightning talks), או שוק פתוח (שמתקרא בלע”ז open space), או אותה פעילות שאין לי מושג איך לתרגם בשם lean coffee. המון הזדמנויות לדבר. אפשר גם סתם לשאול שאלות מוצלחות בהרצאות, או לגשת למישהו בארוחת צהריים ולהציג את עצמכם.
- זה כיף – עדיף לא לשכוח גם את זה. בדרך כלל יהיו אחרי הכנס מפגשים עצמאיים (או מאורגנים) של משתתפי הכנס, או טיול משותף ביום שלאחר מכן, ואפילו במהלך הכנס – אנשים מסביבכם נהנים, וזה מדבק.
- יש מה לספר אחר כך בבית – הייתם בכנס? מצויין. אם זה היה כנס טוב, אז שמעתם לפחות רעיון אחד חדש שאפשר לספר עליו בעבודה. זה יכול לשפר את הדרך בה עובדים אצלכם, או לכל הפחות לבנות קצת את המוניטין בעבודה, שגם זה חשוב.
First of all, I want to state the obvious – not all conferences are alike, and you don’t want to attend all of them (Also, by “you” I mean my intended audience – software development practitioners, testers or otherwise. If you sell something, you might prefer the conferences I would tag as “don’t bother”). One way I’ve seen and liked to identify conferences and decide whether you want to go can be seen here. For those of you that want only the short version, The division is between a practitioners-community and almost-a-sales-pitch, and the compensation received by speakers is a good hint).
So, assuming you go to the right type of conference, what do you get out of it?
- A chance to hear about a variety of interesting subjects– Yes, There are even more interesting subjects out there online, some of them are high-definition videos, and you can watch them at your own time, rewind, skip and see only things that actually interest you.
But! when was the last time you actually sat to watch something on a computer uninterrupted? or without doing three other things at the same time? With real face-to-face encounters you have less of these distractions. Another advantage in conferences is that you might go to a talk that didn’t consider to be in your field of interest, just because it’s there, or that everyone else are going. This talk might end up opening your eyes to something, or “only” be interesting. This happened to me in the CAST2nd day’s opening keynote.
- A chance to ask questions – Attended a talk by an expert in something you’re struggling with? You didn’t understand something said in the talk because you’re new to the field? If you are there you can ask. If the talk is recorded, your question will be there for future viewers. You can also catch the speaker for a longer chat later, maybe over lunch.
- There are a lot of interesting people that get to conferences and don’t speak in fact, at any given conference, chances are that most of the participants are not speakers. So you might find yourself spending an hour or two talking with someone you just met about a common interest you have, or you might meet an expert in a field you are struggling with (and now that you’ve met, you have a communication channel open and you can ask that expert for help later, or even ask them for some consulting work if they do that sort of thing).
- There are workshops – The cool thing about workshops is that you get to actually try out what you are learning. The workshops won’t usually be recorded, and even if they will, participating in one is much more useful than watching it.
- You get to learn what is happening in other places – It is very tempting (at least for me) to think that we know everything, and that everyone are doing the same things we do, but the reality is quite different. Part of the people are doing similar things, others may be far behind us, or far ahead of us while the rest simply have different conditions and need other things. Hearing that such things exist is quite different than actually meeting someone who is facing a different kind of challenge.
- A great energy boost – chances are that if you’re reading this you care about testing. In that case, you can probably use one hand to count others around you that visibly show the same enthusiasm. Add to this a smidgen of daily routine, and you get that sort of wear and tear that tags along. Attending a conference where almost everyone shares your enthusiasm is very energizing.
- A humbling lesson – If you happen to be the only one who seems to care (see previous bullet), it is quite easy to fall into the fallacy of “I’m the best around here”, which isn’t such a great motivation to keep learning. In conferences you will meet people who are at least as good as you perceive yourself to be (some are better). Seeing them in action, say during a workshop, can remind you that there’s still a lot to aspire towards, and you might get some pointers as well.
- A chance to promote yourself – Not everyone present at a conference. Yet, conferences are a great place to present yourself and make yourself known to other professionals and build yourself a reputation. Conferences today enable a wide variety of opportunities to make your voice heard – lean coffees, open spaces, lightning talks and so on. Even if there’s no formal place for you to get some spotlight, just chatting with some people makes your voice heard a bit.
- It’s fun – Usually there will be a plethora of events after the formal conference. Some of it will be pre-organized, some will be spontaneous, or you might just find yourself in a pub with a small group of people you met at the conference. And even just attending the conference is really fun – people around you will be having a great time, and it’s contagious.
So, how do you find a good conference? You start to get involved in the community (or actually, in a community). You read some content in blogs, maybe even in twitter. Attend a meetup or two (The benefit of meetups, besides being great by themselves, is that the entry cost is very low – most of them will cost you only the time you invest in attending, which will be a couple of hours or so), and you open your ears and eyes. Eventually you’ll hear about someone going to a conference, or wanting to go to one, or sharing an experience of having been to one (in which case you’ll have to wait for the next conference). Another option is to see some videos from previous events.
There’s something fun about web development. Something fun with trying to build a website from the ground up or tinkering with a template with it until it fits my needs (like this site), building a Jekyll site from the ground up to display a list of software testing conferences or even a Rails app (I want to build more of […]
Testing isn’t dead but it doesn’t mean we can’t dig into it to better understand it. I attended the Testopsies – Dissecting Your Testing tutorial by Michael Bolton at CAST 2016. Lets open up the experience and take a deeper look. What is Testing We broke up into groups to define / draw out what … [Read more…]
TL;DR I traveled to Vancouver, Canada, in order to attend TestRetreat and CAST 2016. Here is the experience from the tester’s point of view. First issue I found was at Zagreb Airport. Boarding card reader is only used just before you enter the Gate. Boarding card reader failed, and just in front of me, it was restarted. Scan … Continue reading Tester on a journey →
I had a conversation today that many of you have probably had a t some time. Not necessarily this conversation but one that is a parallel experience. I overheard a discussion that had a Tester talking to a new Developer in our company. The conversation included “we work with fixed scope projects”. That statement made […]
CAST is over, and I really enjoyed it. While I was there, I kept comparing it to the European testing conference I attended last February. Much of what I saw and experienced was similar, but there were a couple of differences that set the tone sli…
(Conference report, No Hebrew)
So, it is a recurring theme this conference that Neil manages to get a post written on the same day, despite getting terribly late to his hotel room. I think he deserves a round of applause.
this day I managed not being late to the extremely early lean coffee. Going to a such an event three times in a row, after TestRetreat’s open space made me wonder “can I come up with interesting topics?” It has really surprised me that the answer to this is “apparently yes”. My mind was blank up until the point where the event started, and then some ideas surfaced to mind. But, even if this wasn’t the case, the discussion would not have been hindered, as we had an abundance of interesting topics from other people.
Wobbles in continuous integration – It is sometimes nice to hear about problems that other people are experiencing, especially if they seem to be in a more advanced phase than I am – It helps both to avoid the unrealistic despair that comes from “Why can’t I be as perfect as they are”, as it exposes the hard work that was and is done in order to be in that more advanced state. The other reason I like such discussions is that it gives me some insight to problems I have not yet encountered, and will have to consider as I slowly reach towards my desired goal. The problem raised by Katrina was about how to deal with CI breaking due to changes done by multiple teams. Each team’s branch works fine, but it happens sometime that two teams are working on closely related areas of the code, and once both changes are merged into the master branch, some tests fail because the code checked in by team A might fail on a test created by team B. I can’t really say that anyone around had a definite solution for that, but I liked some of the questions asked and I hope we helped by providing an idea or two that can be used.
Testing infrastructure – should we test a change to the infrastructure of the code? After being presented with the question and a bit of context we tried to get of grip around “what is infrastructure in this context”, as this word can mean a whole lot of different things. We ended up with a conclusion that was not new to anyone participating in the discussion – If it matters, test around what matters to you – but I feel that the way we got there did help for the person who asked that question to find the suitable answer for them.
Training new testers – that’s kind of the eternal question, isn’t it? out of the many comments for doing that, I took three that I particularly liked, and want to try and remember:
- Help tester develop the courage to ask stupid questions – this can be done in a multitude of ways, from setting an example to having 1×1 talks with the new testers and assure them it’s OK to ask question even if it seems stupid.
- Remember that every tester is different – some might lack courage, while others should be scolded to deal with their overconfidence.
- Tell them they are in training. Setting the frame in such a way removes much of the unnecessary stress that are involved in learning to function in a new place.
The next talk was dubbed “Lessons Learned in implementing exploratory testing”, which was quite as the title promised – some stories where implementing those cool ideas we hear about in conferences simply fails. Nancy spoke about the importance of having an actual, actionable plan before trying to push for a large scale change, and about not overloading people with too many new ideas (such as the entire RST course for those who are used to work in the “old” way of running test cases.
I also liked her idea of what should a test manager do – which is to create visibility of the testing process and status to the forces that be, so that everybody will know what are the testers doing, and what takes them so long (this one is to fend of the “testing is our bottleneck” where this is not actually the case).
One thing I didn’t like is that in some parts of the talk, Nancy sounded a bit like someone who saw the light – no longer shall we do test cases, but rather use mind-maps, and all those cool RST tricks for testing. It sounded a bit like one can do whatever they want, as long as we throw “those old ways” out of the window. This lead to one of the main concerns in the talk, which to me sounds like a concern that shouldn’t exist – how to make the sort of testing that was now adopted in the test department to remain even if Nancy will leave her position and go elsewhere? The way I see it – as long as they are good testers, and that good testing is done, it really does not matter if people revert to the ways they are more comfortable with.
Next I attended a group discussion about “engaging people back home”, with the question of should we actually make some effort in order to foster professional development in testers (the global feeling was “yes”, as we do see the value in it, but that’s really preaching to the choir), and how to actually make that happen. The main theme was “give people time on the job to learn”, with one case where one of the participants told about having a designated time each week (4 hours, if I recall correctly) where no meetings are scheduled, and the whole time is used for learning. This sounds to me much better than the “we say we give you 10% to learn, but then we overload you with so many pressing tasks that you don’t actually get to use those 10%” that I see in some places, including my own.
After this interesting, yet frustrating, discussion, I moved on to the lightning talks session.
The subjects were quite diverse, and each speaker got a doll of Tina the test Toucan (which means I now have two of those – the first I got when I registered to AST at the European testing conference).
- Can’t we all get along – was a short talk about being less toxic and violent in online discussions – should we actively reprimand those who express in ways we don’t accept? or should we stay out of such muck and don’t feed them with more attention? Should we defend those we see unjustly attacked?
- Check list for test readiness – a list of things that are worth fleshing out before actually starting to test – be it a test plan or simply having all of the requirements in one place. While not everything was 100% applicable to my environment, just going over it did a little to open my eyes.
- Precognition in work – This talk put me at a certain level of discomfort, the speaker shared with us a “trick” to gain credibility and reputation – write down each time you predict something about a problem that might arise when taking some sort of an action (e.g.: “If we’ll start by building the dev environment before building the test environments, our testers will have no environment to work on for at least a month”). Then, when this prediction comes true – make sure to remind people by telling them “I think I found something in my notes about this…”. What really bothered me in this was that there is a very strong incentive to do that only in cases where I was right, and leave aside the times where I was wrong – thus creating a false appearance of “the doom prophet who’s always right”. It seems to be quite effective, but very misleading.
- Three talks about automation
- constructive objection to UI automation – was a reminder that automating UI is quite expensive and we should try not to do too much of it (the message was to avoid it where possible, but that’s too harsh for me).
- Automation is dead (to me) – Richard Bradshaw did a quick talk about his signature subject – automation in testing. What I really liked about the way it was presented, besides demonstrating how a small shift in focus can mean a lot, is that when I see “test automation”, there’s almost an underlying (and incorrect) assumption that test automation is an inferior programming task (I even wrote about it not long ago), the way Richard presented automation in testing made it very clear that in order to achieve this goal, one should posses proper coding skills. It does not exclude writing a quick & dirty script to save time on a repetitive task, but the approach is “let see what tasks we can automate” assumes a much more capable programmer1 than trying to automate test cases which sometimes lead to many “testing tools” that help in automating a very limited set of actions (record & playback are the most obvious case, but even stronger tools such as SoapUI that is quite powerful still do that). When a capable programmer is tasked with “testing”, not only test cases are targets of automation, but also is setup and teardown of environments, monitoring and various tools that aid manual testing.
- Fully automated regression testing in scale – quite a big name for an important topic – we sometime face the expectation to “automate everything” (or, in a more common name “100% automation”), where what should we really do is to identify the needs and risk the automation is addressing. The comparison I really liked was food, water and air – a person can go without food for a few weeks and still live, about three days with no water, and maybe 20 minutes without breathing. Automation should address the most urgent needs,which will not always be the same thing as the task that was specifically requested.
- The advantages of being pushy – I spoke a bit about my experience in not accepting a “no” and nudging things to go my way in order to get some credibility (and I did have this in mind when I chose the title). In short, I found out that one of the things that make the test team important in the team I’m in is that we get involved in just about everything around us – we ask about design and offer suggestions when we feel it is appropriate, we ask to be included in meetings that we were not originally invited (would it surprise anyone that there are fewer of those than they were 4 years ago?) and we seek to contribute to the product in areas that are not strictly about testing.
I think that such behavior, where we get involved in a lot, and share the information we thus get, has a significant part in making the testers in the team visibly involved and relevant. Or, as one developer who has transferred to our team once told me – the testers are really strong in your team.
And suddenly, the conference was over. A very sharp change. I did my best to say goodbye to the people I’ve met during the conference (for those I didn’t catch, I do plan on sending an email, once I deal with that terrible jet-lag that is caused by flying over 10 time-zones) and went back to my hotel to have at least some sleep before my 17-hours flight back home.
So, that was my conference in very small details. I still need to think a bit about the general picture and process some of the takeaways I noted during the conference, but all in all – a very good experience.
1 Following this post I want to make some order in the terms I use – for me, a programmer is anyone who can code. I use “developer” to denote those that chose programming as their career path, and personally I identify as a tester. Since I’m a tester that also writes code, I’m a programmer despite not identifying myself as a developer. ↩
Thanks for asking. Still tired but I made some good progress on a project I’ve been working on for about 6 months. I actually slept better after finishing this draft. But that’s not today’s topic… Today I want to reflect on jam and systems. Jam systems. Jammed systems. Systemed jam. Systems of jam. I need […]
TL;DR Last week I learned from a developer very useful git feature, add to repository only part of file changes. This was part of unintentional pairing with a developer. I stopped by his desk in order to discuss one of his pull requests, and learning magic just happened. Here is screencast for git patch feature. by