Blog

Unity3D and BBST

On June 6, 2016, in #engagedmembership, General, News, Newsletter, by eproegler
0

Unity Technologies are the creators of the multiplatform Unity Game Engine. We have more than 4.5 million registered users ranging from individual hobbyists to large professional game studios. And at Unity, we make all our internal software testers go through the BBST Courses from AST. You will not become a good tester by taking a course. […]

Continue Reading »

Tina the Test Toucan Visits the #CAST2016 Venue

On April 24, 2016, in #engagedmembership, CAST 2016, Tina_Toucan, by eproegler
0

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 […]

Continue Reading »

למה ללכת לכנס?So why attend a conference? (אשרי אדם מפחד תמיד Happy is the man who always fears)

On August 23, 2016, in Syndicated, by Association for Software Testing
0
לפני קצת יותר משבוע חזרתי מCAST, וחוץ מזה שהיה לי כיף חיים, אני גם חושב שהפקתי מהחוויה הזו תועלת. 
ובכל זאת, כנסים זה יקר, וממילא יש מלא הרצאות באינטרנט, אז למה בכלל לטרוח? אני רוצה לרכז ברשומה הזו כמה נקודות שאולי ישכנעו גם אתכם ללכת. אבל, קודם כל, חשוב לומר שלא כל הכנסים דומים, ולא לכולם אתם רוצים ללכת(“אתם”, במקרה זה, הם הקוראים המיועדים שלי – אלו העוסקים בפיתוח תוכנה. אם יש לכם משהו למכור, יכול בהחלט להיות שתעדיפו ללכת לאחד הכנסים שמבחינתי לא מצדיקים מבט שני). חלוקה אחת בה נתקלתי ונראית לי הגיונית אפשר למצוא כאן (לאלו שמתעצלים לקרוא, או מתעצלים לקרוא באנגלית, החלוקה היא לכנסים מכווני קהילת-מקצוענים, לעומת כאלו שמכוונים לשוק המסחרי וההרצאות בהם הן חצי פרסומת. ההטבות שמקבלים מרצים בכנס יכולות לשמש רמז משמעותי כדי לזהות את מיקום הכנס על הסקאלה). אבל, מתוך הנחה שאתם הולכים לכנס מהסוג הנכון, מה כבר יכול לצאת לכם מזה? 
  • הזדמנות לשמוע על מגוון נושאים מעניינים. כן, נכון. יש מלא נושאים מעניינים באינטרנט, עם וידאו באיכות נפלאה והיכולת לצפות בזה מתי שרק מתחשק לכם ולסנן את הנושאים שמעניינים אתכם בלבד. אבל מתי בפעם האחרונה ראיתם משהו במחשב בלי הסחות דעת באמצע? בלי הפיתוי לשים את השיחה ברקע ולעשות עוד שלושה דברים? זה קורה פחות עם אנשים אמיתיים.  יתרון נוסף שיש להרצאות בכנס הוא שלפעמים אתם נכנסים להרצאה רק כי אתם שם, או כי כולם נכנסים, או כי אתם רוצים לשמוע את הדובר (או הדוברת), ומגלים הרצאה מפתיעה. זה מה שקרה לי  בהרצאת הפתיחה של היום השני בCAST
  • הזדמנות לשאול שאלות – שמעתם הרצאה ממומחה שמתעסק בתחום שאתם מתקשים בו? לא הבנתם משהו בהרצאה בתחום חדש לכם? יש משהו שנראה לכם חשוב לומר? אם אתם נמצאים בכנס אתם יכולים לקום ולשאול. אם ההרצאה מוקלטת, ההערה שלכם תיכנס לשם לטובת הצופים. אתם גם יכולים לתפוס את הדובר לשיחה קצרה אחר כך. 
  • יש הרבה אנשים מעניינים שלא מרצים בכנס אבל מגיעים אליו. לפעמים תמצאו את עצמכם מדברים במשך שעה או שעתיים עם מישהו שרק פגשתם על נושא שמעניין את שניכם. או שתפגשו מישהו שמומחה בתחום בו אתם מסתבכים קצת (ועכשיו, כשיצרתם קשר, אפשר לשלוח לו דוא”ל עם שאלה קצרה או שתיים, או אפילו לשכור אותו כיועץ אם הוא עושה כאלה דברים). 
  • בכנס יש גם סדנאות – היתרון של סדנאות הוא בכך שאפשר גם לתרגל את הרעיונות החדשים. הסדנאות בדרך כלל לא יוקלטו, וגם אם כן – השתתפות בסדנה זה הרבה יותר מועיל מאשר לצפות בה. לא באמת לומדים הרבה מצפייה בלבד. 
  • לומדים מה קורה במקומות עבודה אחרים. יש לנו (או לפחות לי) מעין תחושה שאנחנו יודעים הכל, ומה שאנחנו רואים מסביבנו זה מה שכולם עושים. אבל המציאות די רחוקה מזה – חלק מהאנשים עושים דברים דומים, חלק נמצאים הרחק מעבר למקום אליו חשבנו שאנחנו רוצים להגיע, ואחרים נמצאים במקום בו היינו לפני חמש שנים. זו הזדמנות ללמוד מה קורה אצלם, ומה הם עשו כדי להגיע לאותו מקום (ואם מדובר בכנס מקומי, אולי גם נרצה לדעת אם מדובר במקום בו תרצו לעבוד). אולי סתם תשמעו במקרה על איזה כלי שמשתמשים בו ומוצא חן בעיניכם
  • זו זריקת מרץ נהדרת – לפעמים העבודה היומיומית יכולה להיות שוחקת, ואם אתם היחידים במקום העבודה שמפגינים עניין בתחום מסויים (האחרים אולי מתעניינים בשקט בלי שאתם שמים לב) זה יכול להיות מעייף. בכנס תמצאו אנשים שאכפת להם מנושא הכנס. להיות בחברת אנשים אחרים שאכפת להם מוסיף המון אנרגיה.
  • זה גם לא מזיק לצניעות – אם אתם אלו שמתעניינים בתחום באופן הכי קולני בסביבתכם, קל מאוד להתבלבל ולחשוב ש”אני הכי טוב בזה”. בכנס יש לכם הזדמנות לראות אנשים טובים לא פחות (חלקם יהיו טובים יותר), וללמוד מהם, או לפחות להפנים שיעור זריז בצניעות.
  • זו הזדמנות לקדם את עצמך – לא כולם מרצים בכנס. למעשה, הרוב אינם מרצים. ועדיין, כנסים מספקים מקום להציג את עצמכם בפני המשתתפים האחרים – בחלק מהכנסים מספקים במה להרצאות ספונטניות מהקהל: אלו יכולות להיות שיחות בזק (lightning talks), או שוק פתוח (שמתקרא בלע”ז open space), או אותה פעילות שאין לי מושג איך לתרגם בשם lean coffee. המון הזדמנויות לדבר. אפשר גם סתם לשאול שאלות מוצלחות בהרצאות, או לגשת למישהו בארוחת צהריים ולהציג את עצמכם.  
  • זה כיף – עדיף לא לשכוח גם את זה. בדרך כלל יהיו אחרי הכנס מפגשים עצמאיים (או מאורגנים) של משתתפי הכנס, או טיול משותף ביום שלאחר מכן, ואפילו במהלך הכנס – אנשים מסביבכם נהנים, וזה מדבק. 
  • יש מה לספר אחר כך בבית – הייתם בכנס? מצויין. אם זה היה כנס טוב, אז שמעתם לפחות רעיון אחד חדש שאפשר לספר עליו בעבודה. זה יכול לשפר את הדרך בה עובדים אצלכם, או לכל הפחות לבנות קצת את המוניטין בעבודה, שגם זה חשוב.
אז איך מוצאים כנס טוב? מתחילים להתערב בקהילה. קוראים קצת תוכן בבלוגים או אפילו בטוויטר, מגיעים למיטאפים (היתרון המשמעותי של מיטאפ הוא בעלות הנמוכה – בדרך כלל המפגש יהיה בחינם, וכל מה שנדרש הוא כמה שעות בערב) ומתחילים להתעניין. מתישהו תשמעו על מישהו שהלך לכנס, או מתכנן ללכת לאחד. או מארגן אחד. או שתראו הקלטות של הרצאות משנים קודמות.
————————————————————-
A bit over a week ago I got back from CAST, and had a great time. I also think I benefited from the experience quite a bit.  While a post that will summarize my general thoughts from this conference is still about to come, I want to dedicate this post to list a few reason for why everyone should go to a conference, because, to be honest – going to a conference is not a very obvious choice – it involves work-related stuff outside of work, getting to far places (unless a conference is in your city, you’ll probably have to get to a place which is farther than your office), and even for relatively cheap conferences that happen to be next-door, conferences are still a significant expense. Besides, there’s a ton a free material out in the internet, including talks from conferences. Moreover, unlike a course, conferences don’t usually come with a defined “what do I get out of it” list that can be used to sell the idea to either your manager (who might pay for the event) or even to yourself.
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.

Continue Reading »

Tinkerer, Testerer (Chris Kenst's Blog)

On August 20, 2016, in Syndicated, by Association for Software Testing
0

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 […]

Continue Reading »

Testopsies (Assert.This)

On August 19, 2016, in Syndicated, by Association for Software Testing
0

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…]

Continue Reading »

Fail Over (Hiccupps)

On August 18, 2016, in Syndicated, by Association for Software Testing
0

In another happy accident, I ended up with a bunch of podcasts on failure to listen to in the same week. (Success!) Here’s a few quotes I particularly enjoyed.In Failing Gracefully on the BBC World Service, David Mindell from MIT recalls the early days…

Continue Reading »

Tester on a journey (zagorski software tester)

On August 18, 2016, in Syndicated, by Association for Software Testing
0

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

Continue Reading »

It’s only words (@Beaglesays)

On August 17, 2016, in Syndicated, by Association for Software Testing
0

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 […]

Continue Reading »

CAST and ETC, a quick comparison (אשרי אדם מפחד תמיד Happy is the man who always fears)

On August 14, 2016, in Syndicated, by Association for Software Testing
0

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…

Continue Reading »

CAST day 2 (אשרי אדם מפחד תמיד Happy is the man who always fears)

On August 14, 2016, in Syndicated, by Association for Software Testing
0

(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:

  1. 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. 
  2. Remember that every tester is different – some might lack courage, while others should be scolded  to deal with their overconfidence. 
  3. 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. 
How to keep in touch with people we met at the conference? Yes, it was the last day of the conference, and having a way to keep in touch could be nice. There were some ideas, and some of them have already started to set in motion. 
Online lean coffee – Should we do this? how? We had a short discussion where we decided we definitely want to try that. 
Am I cheating the auditor? When working in a regulated environment, there is an audit from time to time. How much should we disclose to the auditor? Is it ethical to answer directly to questions asked but not to reveal what we know about the product? Where passes the line between legitimate politics and misleading on purpose? 
How to make AST more visible? We really njoyed CAST, and we appreciate what we recieved from the community around the AST – but it is not trivial to hear about it, and testers who are new to the profession might miss out simply because we do not do enough to be easy to find.  While we do leave that question to the AST board, and do recognize the significant work they are doing, maybe there’s something else that can be done. As it just happens, I wore my ETC shirt, that has the AST logo on its back, and that was one example for that effort. We hope that this is something that will resolve itself in time – since if hooking to AST is indeed helping testers improve, there will be more and more good testers around that could attest for it. 
That concluded a rather packed lean coffee session where we had covered multiple subjects in a very concise way. I was really impressed by how quickly some subjects reached a point where we felt we concluded the discussion, as well as by the first time I saw a subject that had all thumbs-up to resolve it. 
The opening keynote for the day was Neuro-diversity and  the software industry. This talk felt a bit like a bucket of ice – sudden, sharp to the point of pain, and eye-opening. In this talk, Sallyann Freudenberg shed some light on the situation of people with what is generally referred to as neurological disorders – problems such as autism, ADHD and even bi-polarity. She made a very compelling case for the benefit of employing the special skills that often come alongside with the difficulties we are more familiar with. What really surprised me was that at a rather early stage of the talk Sallyann told us about when she found out she was on the Autistic spectrum (according to some metrics she shared – quite well in that spectrum), which raised the possibility – If it is possible to be on the Autistic spectrum without even knowing that, and if I relate to some of the examples I’m shown – could it be that I am on the spectrum myself? One thing I can tell you – this is a very good way to keep your audience interested and involved. The talk revolved around points that can be considered if we want to be open to that sort of diversity in our workplace – from major changes that involve construction and environment changes, to simply making it very clear that it is fine to take a 15 minutes break every now and then to relax. 
I would be surprised if there was a single eye that remained dry during the entire talk, and it also lead me thinking – Am I sensitive enough to identify such situations? Can I act in such situation to help such individuals to better fit the team I’m in? I think this talk is the type of things that make going to a conference worth that much more – I would probably not watch any talk on this subject in my own free time (since it isn’t about testing or a subject that remotely resembles any of my interest fields), but I’m very glad I did get to hear this thought.

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. 
Following the lightning talks I had shortly considered joining the 2nd part of the workshop about “fostering healthy uncertainty in software projects”, but as i already missed the first part, and after glancing over the groups notes from the it I decided to go to When You’re Evil: Building Credibility-Based Relationship with Developers, which wasn’t about being evil at all. Instead it pointed out that when we as testers drive for a change, we actually rely on the credibility we have inside our team, or actually, how much credibility we have with the specific developer(s) that we will work with. This credibility has something to do with consistent good performance, but it has much more to do with being considered as “part of the team” and not as an external force to resist. Some of the tactics to get into the developers “good side” can sound a bit insidious at first, and a little bit manipulative, but after a while it sank to me that most of it really comes down to actually demonstrating that we are in the same team – It sound horrible when someone says “in order to be on someone good side, listen to them talking about things they care for”, but is it really different than “when you work with someone, show some respect and interest in their hobbies” ? The former is a bit manipulative, the latter is similar to those tips you might find in any “how to foster team collaboration” articles you can find online. Still, both of them are really the same – is it bad to acknowledge the fact that being part of the team does have some very immediate benefits?

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. 

Continue Reading »

How do you do, Head of Testing? Vol. 2 (The Pain and Gain of Edward Bear)

On August 13, 2016, in Syndicated, by Association for Software Testing
0

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 […]

Continue Reading »

Testers goodies: partial git add (zagorski software tester)

On August 12, 2016, in Syndicated, by Association for Software Testing
0

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

Continue Reading »
Page 1 of 40312345...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!