Unity3D and BBST

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

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

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 »

The Bad of Event Sourcing – The Pains of Wrongly Designed Aggregates (The Continuous Improver)

On March 23, 2017, in Syndicated, by Association for Software Testing

Event Sourcing is a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don’t tell you about. In June, I already blogged about the things I would do differently next time. But after attending another introduction to Event Sourcing recently, I realized it is time to talk about some real experiences. So in this multi-part post, I will share the good, the bad and the ugliness to prepare you for the road ahead. After having dedicated the two last posts on the good of event sourcing, let’s talk about some some of the pains we went through.

Designing your domain based on ownership

When I started practicing domain driven design almost 9 years ago, I thought I knew all about aggregates, value objects, repositories, domain services and bounded contexts. I read Eric Evans’ blue book, Jimmy Nilsson’s white book and various papers such as InfoQ’s DDD Quickly. Our main driver for designing our aggregates was based on who owns what property or relationship. We designed for optimistic concurrency, which meant that we needed to use the version of the aggregate to detect concurrent updates. The same applied to relationships (or association properties on a technical level). If it was important to protect the number of children a parent has, you needed to add the child through the parent. Since we were using an OR/M, we could use its built-in versioning mechanism to detect such violations. Surely I had not heard of eventual consistency or consistency boundaries yet, and Vaughn Vernon had not published his brilliant three-parts series yet. In short, I was approaching DDD as a bunch of technical design patterns rather than the business development experience it is supposed to be.

Relying on eventual consistent projections

Because we didn’t consider the business rules (or invariants) enough while designing our aggregates, we often needed to use projections to verify certain functional scenarios. We knew that those projections were not transactional consistent with the transactions, and that other web requests could affect those projections while we were using it. But the functional requirements allowed us to work around this for the most part. Until the point that we wanted to make a projection run asynchronously of course. That’s the point were we either had to stick to an (expensive) synchronous projector, or accept the fact that we couldn’t entirely protect a business rule. Next time, I’ll make sure to consider the consistency of a business rule. In other words, if the system must protect a rule at all costs, design the aggregates for it. If not, assume the rule is not consistent and provide functional compensation for it.

Bad choice in aggregate keys

As many information management systems do, we had an aggregate to represent users. Each user was uniquely identified by his or her username and all was fine and dandy. All the other aggregates would refer to those users by their username. Then, at a later point of time, we introduced support for importing users from Active Directory. That sounded pretty trivial, until we discovered that Active Directory allows you to change somebody’s username. So we based our aggregate key on something that can change (and may not even be unique), including the domain events that such an aggregate emits. And since a big part of the system is using users to determine authorization policies, this affected the system in many painful ways. We managed to apply some magic to convert the usernames to a deterministic Guid (ping me for the algorithm), but it still was a lot of work. Next time, I will just need to accept that no functional key is stable enough to be the aggregate key and start from a Guid instead.

Using domain events as a way to externalize business rules

The system that I worked on is highly customizable and has a domain with many extension points to influence the functional behavior. At that time, before we converted the system to Event Sourcing, we used Udi Dahan’s domain event implementation to have the domain raise events from inside the aggregates. We could then introduce domain event handlers that hook into these and which provide the customized behavior without altering the core domain. This worked pretty well for a while, in particular because those events were essentially well-defined contracts. With some specialized plumbing we made sure all that code would run under the same unit of work and therefor behaved transactionally.

But when we switched to event sourcing, this mechanism became a whole lot less useful. We had to make decisions on many aspects. Are the events the aggregates emit the same as domain events? Should we still raise them from inside the aggregate? Or wait until the aggregate changes have been persisted to the event store? It took a while until we completely embraced the notion that an event is something that has already happened and should never be used to protect other invariants. Those cases that did misuse them have been converted into domain services or by redesigning the aggregate boundaries. You can still use the events as a way to communicate from one aggregate to another, but then you either need to keep the changes into the same database transaction, or use sagas or process managers to handle compensation or retries.

Domain-specific value types in events

Remember the story about how we choose the wrong functional key for a user and had to touch a large part of the code base to fix that? As with any bad situation, people will try to come up with measures that will prevent this in the first place. Consequently, we decided to not directly use primitive types in our code-base anymore, and introduce domain-specific types for almost everything. For instance, a user was now identified by a UserId object with value semantics. So whether it contained a Guid or a simple string was no longer of concern for anything but that type itself.

But as often happens with a lot of new ‘practices’, we applied it way too dogmatic. We used them everywhere; in commands, aggregates, projections and even events. Naïve as we were, we didn’t realize that this would cause a tremendous amount of coupling between the entire code-base. And I didn’t even mention the horror of somebody changing the internal constraints of a value type causing crashes caused by an old event that couldn’t be deserialized because its old value didn’t meet the new constraints. Having learned our lessons, nowadays we make sure we consider the boundaries of such value types. You may still use them in the aggregates, domain services and value objects within the same bounded contexts, but never in commands, projections and events.

Event Granularity

Consider a permit-to-work process in which the risk assessment level can be determined to be 1 or 2. If the level is 2, the process requires a risk assessment team to be formed that will identify the real-world risks involved in the work. However, if the risk level is reduced to 1, then the team can be disbanded. To model the intent of this event, we have two options. Either we capture this situation by first emitting a couple of fine-grained MemberRemovedFromRiskAssessmentTeam domain events, followed by a RiskAssessmentLevelChanged domain event. Or we decide to capture this as a single RiskAssessmentLevelDemoted event. So which is better?

Considering the fact that we’re practicing Domain-Driven Design, I guess most people will go for the coarse-grained RiskAssessmentLevelDemoted event. And indeed, it does properly capture the actual thing that happened. But it has a drawback as well. Both the domain as well as the projection logic must know to interpret that event as a demotion in the actual level and the disbandment of the risk assessment team. But what happens if the expected behavior changes in a later version of the software? Maybe the rules change in such a way that team will need to be kept intact, even if the level changes. If you take the coarse-grained event path, you will need to duplicate that logic. We don’t share code between the command and query sides in a CQRS architecture style. And what happens when you rebuild domain aggregates form the event store that existed before the software update was completed? There’s no ultimate answer here, but considering the relatively high rate of change and configurability in our system’s business rules, we choose for fine-grained events.

Event Versioning

Much has been written about event versioning and there are plenty of examples how to convert one or more older events into a couple of new events. We use NEventStore, which provides a simple event upconversion hook out of the box. That library uses Newtonsoft’s Json.NET to serialize the events into its underlying storage, which, by default, includes the .NET runtime type of the event in the JSON payload. This has caused us some pain. What if the .NET namespace of the event type changes because somebody refactored some of the code? Or what if the event is moved from one DLL to another because we decide two split one project in two or two projects in one? We had to tweak the JSON serializer considerably to ensure it would ignore most of the run-time type info and find a reasonably stable mechanism to match a JSON-serialized event with its run-time .NET type. Maybe there’s an event store implementation that solves this for you, but we have not come across one yet.


Great developers don’t write bugs I often hear some of my colleagues say, but somehow I keep running into apparent less-than-great-developers. So bugs are inevitable. We didn’t have too many problems with bugs affecting the domain. Either we could handle them by changing the way the existing events were used to rebuild the domain, or by repairing flawed events using smart upconverters. However, I do remember a particular painful bug that was really hard to fix. One of our background processes was responsible for importing information about a back office system into the domain. It would collect the changes from that system and translate them into a couple of commands that were handled by the domain. All was well for a while, until we got some reports about some weird timeouts in the system. After some investigation we discovered that a particular single aggregate had more than a million events associated with it. Considering the average of a handful of events per aggregate instance, this was a serious problem. Apparently the aggregate root contained a bug that caused it to be not so idempotent as it should be, injecting new events for things that didn’t even change. We finally managed to fix this by marking the stream as archivable, a concept we build ourselves. But it most definitely wasn’t fun….

What about you?

So what do you think? Do you recognize the challenges of designing your aggregates correctly? If not, what is your primary source for guidance on this complicated topic? I’d love to know what you think about this by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better aggregates.

Continue Reading »

Can You Afford Me? (Hiccupps)

On March 22, 2017, in Syndicated, by Association for Software Testing

I’m reading The Design of Everyday Things by Donald Norman on the recommendation of the Dev manager, and borrowed from our UX specialist. (I have great team mates.)There’s much to like in this book, includinga taxonomy of error types: at the top level …

Continue Reading »

מפגש בודקים – סיכום testing meetup (אשרי אדם מפחד תמיד Happy is the man who always fears)

On March 22, 2017, in Syndicated, by Association for Software Testing
התחלה טובה למפגש

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

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

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


Last Thursday there was a testing meetup in Tel Aviv, the first one in a series of meetups that are dedicated to testing – not automation only (though it does not exclude automation), not a specific technology, simply testing. After quite a while without a JeST (Jerusalem software testing), it was nice to see a new meetup coming to life. I want to thank Nitzan and Igor for organizing this series, Avivit who invited us to ClickTale office and was a great hostess and Anna who presented the first talk in the meetup. 
The evening started with a very interesting topic – risk based testing. Anna gave a thorough overview of the subject, touching on why it is important to incorporate risk into our testing, and we had some great discussions about who decides to ship, how to treat risk and how to report on risks identified during testing. All in all – it was a very good intro to the subject. One point to keep in mind for the future, though, is that the talk was very theoretical and was deeply rooted in a reality that was foreign to most attendees  – a reality in which there is a place for quite heavy documentation and the release cycle is quite long. This made the talk more valuable to the more experienced people in the room who were already familiar with the concept of risk and could extrapolate from what was said to their day-to-day work.And indeed, some of the attendees seemed to doze off a bit. Despite that we had some interesting discussions during the talk and I found the entire experience interesting. 
After the talk, during the break, people did the right thing and split up to small groups for some chatting, which is exactly what I did: I spotted someone who was sitting alone in a corner and went to introduce myself and start a conversation. suddenly, the break was over and we had to cut our conversation short. 
Once the turmoil from the break broke off, Nitzan presented a question to the audience: What is required in order to transform from a good tester to a great one? Personally, I would be satisfied to simply be a good tester, but I can see the value of aiming high. At this moment, of course, it was already clear (from the mini-discussions we had) who were more likely to join the conversation and who would probably be silent for the entire meeting. To mitigate this, at least a little, I used something I encountered during lean coffee sessions (and some scrum retrospective) and distributed some post-it notes to each participant and asked each person to write down at least two ideas (why two? Because asking for one would have probably ended in each person writing down one note, with the shy ones skipping it altogether, and because trying to think of two distinct ideas is where other ideas come from). I then used the moderator position I appropriated to get people up and stick their post-its to the whiteboard, just to see how many ideas we had (If you can read Hebrew, you can find the subjects here thanks to Kobi who collected them), and then to facilitate the discussion around some topics and make sure that the silent ones at least got to choose a topic.

By the end of the meetup, the convention spirit took care of us, and we found out that down at the building entrance there was some music and free beer (something related to the fact that it was the night before St. Patrick’s day, I think) and so some of us stayed and talked a bit more for a couple of hours. Funny as it may be, it doesn’t matter how good was an event, it’s the unofficial parts which are the most memorable and enjoyable.

This meetup was a chance to get a wide variety of people together (how wide? if we limit ourselves to experience years only, we had people with over 20 years of experience together with some who are looking for their first testing job), and although it’s only my estimate, I think that everyone who were at this meetup will want to be in the next one as well.
Personally, I can’t wait to the next meetup to happen – I really liked the combination of a talk and an open discussion, and the vast array of different experiences contributed a lot to the interesting discussions – during the talk and after it. 

Continue Reading »

It is TestBash Brighton time! (zagorski software tester)

On March 18, 2017, in Syndicated, by Association for Software Testing

Reading Time: 3 minutesTL;DR This is my personal cheat sheet for TestBash Brighton 2017 testing gathering. Based on my previous conference experiences, I realized that I need a one stop shop reminder for conference activities. I will print out this blog post. Here it goes. Wednesday Pre-TestBash Meetup, 29-30 Surrey street, Brighton, BN1 3PA Starts at 7.00PM but it … Continue reading It is TestBash Brighton time!

Continue Reading »

A Field of My Stone (Hiccupps)

On March 18, 2017, in Syndicated, by Association for Software Testing

The Fieldstone Method is Jerry Weinberg’s way of gathering material to write about, using that material effectively, and using the time spent working the material efficiently. Although I’ve read much of Weinberg’s work I’d never got round to Weinberg on Writing until last month, and after several prompts from one of my colleagues.

In the book, Weinberg describes his process in terms of an extended analogy between writing and building dry stone walls which – to do it no justice at all – goes something like this:

  • Do not wait until you start writing to start thinking about writing.
  • Gather your stones (interesting thoughts, suggestions, stories, pictures, quotes, connections, ideas) as you come across them. 
  • Always have multiple projects on the go at once. 
  • Maintain a pile of stones (a list of your gathered ideas) that you think will suit each project.
  • As you gather a stone, drop it onto the most suitable pile.
  • Also maintain a pile for stones you find attractive but have no project for at the moment.
  • When you come to write on a project, cast your eyes over the stones you have selected for it.
  • Be inspired by the stones, by their variety and their similarities.
  • Handle the stones, play with them, organise them, reorganise them.
  • Really feel the stones.
  • Use stones (and in a second metaphor they are also periods of time) opportunistically.
  • When you get stuck on one part of a project move to another part.
  • When you get stuck on one project move to another project.

The approach felt extremely familiar to me. Here’s the start of an email I sent just over a year ago, spawned out of a Twitter conversation about organising work:

I like to have text files around [for each topic] so that as soon as I have a thought I can drop it into the file and get it out of my head. When I have time to work on whatever the thing is, I have the collected material in one place. Often I find that getting material together is a hard part of writing, so having a bunch of stuff that I can play with, re-order etc helps to spur the writing process.

For my blogging I have a ton of open text files:

You can see this one, Fieldstoning_notes.txt and, to the right of it, another called notes.txt which is collected thoughts about how I take notes (duh!) that came out of a recent workshop on note-taking (DUH!) at our local meetup.

I’ve got enough in that file now to write about it next, but first here’s a few of the stones I took from Weinberg on Writing itself:

Never attempt to write what you don’t care about.

Real professional writers seldom write one thing at a time.

The broader the audience, the more difficult the writer’s job.

Most often [people] stop writing because they do not understand the essential randomness involved in the creative process.

… it’s not the number of ideas that blocks you, it’s your reaction to the number of ideas.

Fieldstoning is about always doing something that’s advancing your writing projects.

The key to effective writing is the human emotional response to the stone.

If I’ve been looking for snug fits while gathering, I have much less mortaring to do when I’m finishing

Don’t get it right; get it written.

“Sloppy work” is not the opposite of “perfection.” Sloppy work is the opposite of the best you can do at the time.

Continue Reading »

So You Want To Produce a Podcast? Part Five: Write Down all the Things (TESTHEAD)

On March 15, 2017, in Syndicated, by Association for Software Testing

I’m guessing some people have noticed it’s been awhile since my previous post. You may be asking what I’ve been doing between posts. If guessed editing a podcast for a deadline, you’d be correct. If you also guessed writing up a transcript and sho…

Continue Reading »

Teaching Testing to High School Girls (The Pain and Gain of Edward Bear)

On March 12, 2017, in Syndicated, by Association for Software Testing

This Saturday I participated at a Digigirls event where I taught a testing workshop. Digigirls is an event series in Estonia founded by Tech Sisters – a non-profit organization – to provide girls (9th to 12th grade) encouraging practical experience with roles in software development. Tech Sisters is a community that aims to inspire, educate […]

Continue Reading »

איך לעבור את ראיון העבודה שלי How to pass my technical interview (אשרי אדם מפחד תמיד Happy is the man who always fears)

On March 11, 2017, in Syndicated, by Association for Software Testing
מזה זמן מה, לפחות כמה חודשים, אנחנו מחפשים מישהו שיצטרף אלינו לצוות, מה שאומר שאנחנו מקבלים לא מעט קורות חיים של מועמדים, ויוצא לי(יחד עם ראש הצוות שלי) לראיין כמה וכמה מהם. מה אגיד ומה אומר? זה מאוד מתסכל לראיין אנשים שנכשלים – אנחנו רוצים למצוא עובד, המועמדים רוצים למצוא עבודה (ובתקווה, רוצים לעבוד אצלנו), אבל עד כמה שאנחנו מסוגלים לקבוע – אין התאמה בין היכולות שלהם למה שאנחנו מחפשים. כמובן, ראיון הוא מעמד מלחיץ, ולפעמים הלחץ הזה יכול לגרום לרושם מוטעה. 
בשבוע הקרוב, כמו שהדברים נראים כרגע, אני הולך לבלות את רוב השבוע בראיונות. לכן, כשירות לקהילה (וגם מתוך תקווה שאחד הראיונות יעבור בהצלחה), חשבתי להעלות על הכתב כמה עצות שצריך כדי לעבור ראיון טכני איתי
הדבר הראשון שצריך לעשות ,לפני שמגיעים לראיון, הוא לדעת אם יש התאמה בין הכישורים והרצונות שלכם למה שאנחנו מחפשים: זה לא משנה כמה תתכוננו לראיון, אם אין לכם את הכישורים שמקום מחפש, לא תתקבלו לעבודה שם, או שתתקבלו אבל לא תרצו לקבל את ההצעה. אם אתם רוצים לשפר את הכישורים שלכם בבדיקות מובייל, מקום עבודה שבונה מערכות למהנדסי תעופה הוא כנראה לא המקום המתאים בשבילכם. מצד שני, אם אין לכם שום ידע על בדיקות עומסים וביצועים, אף אחד (שהנושא חשוב לו) לא יקבל אתכם למשרת הובלה של בדיקות כאלה. לפני שאתם מגיעים לראיון – שבו עם עצמכם. נסו להבין מה אתם יודעים לעשות ומה אתם רוצים לעשות. זה בסדר לגשת למשרה אם אין לכם את כל הכישורים הדרושים – כששוכרים עובדים חדשים לוקחים בחשבון את העובדה שצריך ללמד אותם. אבל יש כמה דברים שאין למקום העבודה את הזמן או היכולת ללמד אתכם, ונחשו מה? אלו בדיוק הדברים עליהם ישאלו אתכם בראיון.  אצלנו, למשל, יש שלושה כישורים בסיסיים שאנחנו מחפשים – כל החבילה שנהוג לכלול תחת “גישה של בדיקות”, יכולת תכנות (ברמה של בוגר תואר ראשון) וכישורים תקשורתיים.  אם תשאלו אותנו (לפני שהגעתם לראיון) – נאמר לכם פחות או יותר את זה. 
הגעתם לראיון איתי? זכרו שזה אומר שאני מאמין שיש לכם סיכוי להתקבל. זכרו גם שאני רוצה שתעברו את הראיון. הנה כמה דברים שכדאי לכם לעשות.
  •  שאלתי אתכם שאלה שאתם לא בטוחים לגביה? יש מעט מאוד דברים שיגרמו לי להעריך אתכם יותר מאשר האמירה “אני לא יודע\ת”. אם שאלתי אתכם שאלה על איך מנוהל הזיכרון בג’אווה וזה משהו שלא למדתם אף פעם, אני ככל הנראה שואל כי אני רוצה לדעת מה אתם יודעים ומה לא, או כי אני מנסה להוביל את הראיון לנקודה מסויימת. אם אתם לא יודעים, אני אספר לכם את מה שצריך לדעת ונמשיך הלאה. אם תנסו לנחש ולזרוק מונחים חצי קשורים, אני אאבד את ההערכה שיש לי אליכם. 
  • גם אם אתם בטוחים – שאלו שאלות. לדעת לשאול את השאלות הנכונות ולהתאים את עצמכם בהתאם לתשובות הוא כישור חשוב לבודקי תוכנה (ולכל מי שעובד עם הראש). ביקשתי מכם לבדוק עיפרון ואתם מתחילים לפלוט מקרי בדיקה בלי ששאלתם אותי אם, במקרה, מדובר בעיפרון איפור? חבל.  בעולם בו יש כל כך הרבה מה לבדוק, אני רוצה לראות איך אתם מתעדפים את הבדיקות שלכם, ואתם לא יכולים לעשות את זה בלי לשאול שאלות. למעשה, אני מנסה להבין עד כמה אתם טובים בשאילת שאלות וחלק מההנחיות שלי מעורפלות בכוונה.  
  • אם אתם מגיעים לראיון איתי, אל תטרחו להתאמן על “איך לבדוק עיפרון”, אני מראיין אתכם למשרת בודק תוכנה, לא למשהו בעיצוב תעשייתי. אם אבקש מכם לבדוק משהו, הוא יזכיר קצת יותר את הדברים שאפשר למצוא ביום עבודה סטנדרטי. 
  • בתחילת הראיון אני אבקש מכם לספר לי על המקום האחרון בו עבדתם, או על פרוייקט שעשיתם בלימודים, או על קורס שמצא חן בעיניכם – אני מנסה להבין עד כמה אתם מבינים פרוייקטים טכנולוגיים ועד כמה אתם מסוגלים להפריד בין עיקר לטפל. אני אבקש מכם לתאר את המערכת בכללותה, או לצלול לפרטים – אני מצפה שתדעו להסביר מה עושה המערכת ומי משתמש בה, איך מידע עובר ואילו רכיבים גדולים נמצאים במערכת. כשאני מבקש לרדת לפרטים הקטנים, זה לא כי אני מנסה להשיג מידע על המערכת, אלא כי אני מנסה לדעת כמה לעומק אתם מכירים אותה. רוצים להתכונן לשאלה הזו? ודאו שאתם מסוגלים לצייר תרשים כללי של המערכת ואז לבחור באקראי חלק של הציור ולהרחיב אותו עוד רמה או שתיים פנימה. שימו לב שאתם לא מספרים לי על פרטי פרטים כשביקשתי מבט כללי, ושאתם לא עונים תשובה כללית על בקשה שלי לפרטים טכניים.
  • דעו להגן על העמדות שלכם – לפעמים אני אשאל “למה?”. בחלק מהמקרים, זה כי אני חושב שעשיתם בחירה לא נכונה. בחלק אחר, כי אני רוצה לדעת האם אתם פועלים מתוך הרגל או שאתם יודעים להסביר את הסיבות לפעולות שלכם. לפעמים אני רוצה לראות איך אתם מגיבים כשמקור סמכות (המראיין, במקרה הזה) מפעיל עליכם לחץ.
  • אם עשיתם טעות, זה לא אומר שנכשלתם. כמו “לא ידעתי”, גם “נכון, טעיתי” קונה לכם נקודות זכות. אני מודע היטב לכך שהראיון מלחיץ, ושאתם רק אנושיים. מותר לטעות. 
  • קורות החיים שלכם יוצרים ציפיות. כתבתם שיש לכם “הסמכת ISTQB”? אם אתם לא יודעים מה הן מחלקות שקילות אני אזקוף את זה לחובתכם. לא כתבתם? אני פשוט אניח שמעולם לא נתקלתם במונח. 
  • אין כזה דבר “להיכשל בשאלה”. אם כבר הגעתם לראיון ואני משקיע בכם זמן, שאלה אחת לא תפיל אתכם. שאלה נותנת לי מידע. אם נדמה לי שיש פער ביכולת שלכם בנושא מסויים – אני אשאל שאלה נוספת כדי לקבל מידע נוסף ולהבין כמה גדול הפער. 
  • כשאתם מספרים על עצמכם, ספרו לי מה המטרות שלכם ומה אתם מחפשים – אם אתם מחפשים משרה ממנה אפשר לעבור למשרה ניהולית ואני יודע שאין לנו תקני ניהול פנויים באופק, אתם תעדיפו שאספר לכם וניפגש בהזדמנות אחרת. אם לא סיפרתם לי וקיבלתי את הרושם שאתם מחפשים משהו שונה ממה שאני מציע – כנראה שלא תעברו לראיון הבא. אם לא סיפרתם וגם עברתם לראיון הבא – אתם מבזבזים את זמנכם על משהו שלא תרצו.
  • יש כמה דברים שכדאי לדעת על שאלות תכנות:
    • אני מבקש מכם לפתור תרגיל תכנותי בלי לתת לכם מחשב – זה אומר שלא אכפת לי מתחביר או מתוכנית שמסוגלת לעבור הידור (קומפילציה בלע”ז). אילו הייתי רוצה לבחון את הכישורים שלכם בשפה ספציפית הייתי נותן לכם גישה למחשב וIDE. אני לא אפיל אתכם כי לא כתבתם נקודה-פסיק, או כי השתמשתם במתודה לא קיימת. אם אתם לא בטוחים אם יש פונקציה שעושה משהו שאתם צריכים (נניח, חזקה), כתבו שם של פונקציה שיאפשר לי להבין מה אתם מנסים לעשות, וציינו שאתם לא בטוחים אם יש משהו כזה.
    • אם זה ממש קריטי בשבילכם, כתבו את התרגיל על דף. אם זה לא קריטי עד כדי כך, לכו ללוח. אני לומד הרבה יותר כשאני רואה את הקוד שאתם כותבים, ומוחקים. בכתיבה על דף אני בעיקר מנחש לפי הפרצופים שאתם עושים – וזה לא משחק לטובתכם. 
    • אל תשתקו. ספרו לי מה אתם מתכננים לעשות. אם נתקעתם, ספרו מה מפריע לכם. אתם צריכים חמש דקות של שקט כדי לעבוד? אמרו לי במפורש שאתם תשמחו לכמה רגעים של שקט כדי לחשוב. אולי אפילו אצא מהחדר כדי לאפשר לכם קצת שקט.
    • עבדו עם דוגמאות, ובדקו שהאלגוריתם שלכם עובד עבור הדוגמה שבחרתם.
    • אני רואה את הקוד שלכם – תוך כדי כתיבה או בסופה. בחרו שמות שקל לעקוב אחריהם. זה מעיד על הרגלי תכנות טובים, אבל גם מאפשר לי להבין תוך כדי כתיבה את הכיוון בו אתם הולכים. אם כתבתם פונקציה בשם flipNextBit אני יודע מה אתם מנסים לעשות. 
    • אתם לא יכולים לחפש בגוגל תוך כדי הראיון, אבל אתם יכולים לשאול אותי. 
    • חפשו באינטרנט שאלות תכנות, ותרגלו כתיבה של התשובות על לוח, או על דף נייר. רוב השאלות שתמצאו יהיו קשות יותר ממה שאני שואל, ויש שני דפוסים של כישלון בשאלה הזו – הסוג הראשון הוא אלה שלא מצליחים לחשוב על דרך לפתור את הבעיה ובוהים בלוח במשך עשר דקות עד שהם מאלתרים איזה פתרון. הסוג השני יודע לומר מהר מאוד מה צריך לעשות, אבל כשמגיע החלק בו צריך להעביר את האלגוריתם לקוד – משהו נתקע. תרגול של כתיבת קוד על נייר בבית יעזור עם שני סוגי הכשלונות: מצד אחד, חשיפה לתרגילים מלמדת אתכם לחשוב מהר על אלגוריתם לפתרון בעיות (וכמו שאמרתי, השאלות שאני שואל קלות מאוד), מצד שני – תרגול כתיבה על נייר ישחרר אתכם מהתלות בIDE. 
    • בהסתברות לא רעה, יהיו לכם טעויות בקוד בפעם הראשונה בה תכתבו אותו. כשאני מצביע על כישלון כזה אני בעצם בודק איך אתם מתמודדים עם “כישלון” – האם אתם קופאים? האם אתם מנסים להמעיט בחומרת הטעות כדי לא להיראות רע (אל תעשו את זה, זה די נורא)? האם אתם מושכים בכתפיים ומתקנים את האזור הבעייתי?
    • אל תטרחו לבזבז זמן על שינון פקודות סלניום (או כל ספרייה אופנתית אחרת). אני לא שואל שאלות שהדרך הנכונה לענות עליהן היא על ידי חיפוש בגוגל. 
    • כל ההכשרה התכנותית שלכם היא איזה “קורס אוטומציה” שעשיתם? קחו כוס מים, נשמו עמוק, ולכו ללמוד לתכנת. אין שום בעייה שתלמדו לבד, אני לא מחפש תעודה מסודרת, אבל כדאי מאוד שתשלטו היטב בדברים כמו פולימורפיזם, רקורסיה ומבני נתונים. לא כל דבר יעלה במהלך ראיון, אבל כל אחד מהנושאים האלה הוא יעד לגיטימי לשאלה. 
  • ולסיום – בקשו משוב. אני עדיין צריך ללמוד איך עושים את זה, אבל סיימתם ראיון ואתם חושבים שלא עברתם? אני אשמח לעזור לכם ללמוד מהראיון ולשים לב לנקודות החלשות יותר שהיו לכם בראיון. גם אם לא התאמתם לצוות בו אני עובד, נצלו את ההזדמנות כדי ללמוד משהו לראיון הבא שלכם. 
* כמובן – אם אתם מחפשים עבודה ורוצים לשמוע פרטים, שלחו לי הודעה. 
For quite a while now, we are looking for someone who will join our team, which means we get a whole bunch of CVs, and some of the people I get to interview (alongside my manager). What can I say? It’s really frustrating to interview a candidate that fails. We want to find a new team-member, the candidate wants a job offer (hopefully, they want a job offer in our team), but as far as we can determine – there isn’t a match in the skill-set the candidate has and that which we need. Of course, an interview is a stressful situation, which can lead to wrong impression. 
The way things are set now, it seems that next week I will do very little other than interviewing candidates. So, as a service to the community (and also in hope that the interviews I have scheduled will go better), I thought to write about how to pass my technical interview.
First of all, before you even get to the interview, do your best to determine that the position matches your skills and desires. It almost doesn’t matter how well prepared you will be – if there’s a mismatch here you either won’t pass the interview, or you’ll get a job offer you don’t want. If you want to improve your mobile testing skills, a place that builds software for aviation engineers is probably not the right place for you, and if you don’t have any performance testing background, no (decent) place will hire you to lead the performance testing efforts of the entire company. Before you get to any interview, sit with yourself and be honest – what do you want to do? what skills do you have? what skills you need to acquire? It’s ok to apply for a position if you don’t have all of the required skills: It is always assumed that a new employee will have to learn some stuff before actually being productive. However, there are some skills that the workplace will not have the time, ability or will to teach you – and guess what? Those are the very skills you’ll be interviewed for. For us, for example, there are three basic things we look for in a candidate: Communication skills, Programming (at least at the level of a university graduate) and the package that is sometimes referred to as “Tester’s mindset” (Including stuff like System-view, Question-asking and context awareness). If you’ll ask us before the interview – that’s probably what we’ll tell you. 
You got to an interview with me? congratulations. This means that I think that you have a good chance to pass the interview. Also remember that I want you to pass. So, here are some things you should keep in mind. 
  • I asked something you are not familiar with? There isn’t much that you can say and will impress me more than “I don’t know”. If I asked you about how memory is managed in Java and you have never learned it – I am probably trying to map what you know, not to trick you and disqualify you based on an easy to learn subject. I might also be trying to direct the interview to a certain direction, in which case saying “I don’t know” will save us both time and I can tell you what I need you to know to continue.  If you’ll throw around some half-related terms to try and make me think you know what you are talking about I’ll notice and will lose my appreciation for you.
  • Even if you do know how to respond – ask a question or two to make sure. Knowing to ask good questions is important for testers (and any other knowledge workers). I’ve asked you to test a pencil? If you’ll start throwing test cases without asking if it’s a make-up pencil, it will be disappointing. In a world where the possible test options are infinite, I want to learn about the way you prioritize your tests. I also pose challenges that are meant to make you ask questions so that I’ll see how good are they. 
  • Also, don’t bother practicing testing pencils, I don’t ask this sort of things. I interview people for software testing positions, not for industrial designer ones. If I’ll ask you to test something, it will resemble more something that you can expect to find in your day to day work. 
  • At the beginning, I will ask you to describe your last workplace, or a project or course from your studies – I’m trying to understand how well do you understand technological projects, and how well can you communicate them and separate between what’s important and what isn’t. I will ask for a high level overview, I might ask to deep dive on a random part of the system. I expect you to know to explain what is the system used for (and by whom), how data is passing through it and what are the main components in it. When I ask about the fine details of your system it is not because I try to uncover trade secrets, but because I want to assess how deep is your understanding of the system you were working on previously. 
    If you want to prepare for this question – make sure you can draw a high-level diagram of the system, and can dive in a level or two on every part chosen at random. Also make sure to notice which level of detail am I asking for. I expect you to be comfortable in  both high-level overview and low-level fine details scope, so don’t run to the overview when asked for details, and don’t hide behind details when asked for an overview. 
  • Defend your opinions. sometimes, during the interview I will ask you “why?” I might have noticed something I think is a mistake, or I might want to make sure you know why you are doing something. I might even check how do you respond when an authority figure (me, in this case) is putting pressure on you. 
  • Your CV sets expectations. If you write “ISTQB certified” and you don’t know what boundary values are, I will hold it against you. If you did not write such thing, I will just assume that you have not heard of the term and explain it quickly. 
  • There’s no such thing such as “failing a question”. First of all – if you’re here and I’m investing my time in you, I won’t let a single question to be a single point of failure. Second – a question is giving me information. You might have a knowledge gap that I have to consider, and I will ask some follow-up questions to better understand that gap and see if I can live with it or easily fix it. 
  • Tell me what are you looking for – if you do not do so, and I will get the impression that you are looking for something different than what I have to offer, I will not pass you to the next phase. If you don’t tell me and I will pass you through – I will be wasting your time on something you don’t want. 
  • Now, some stuff about coding questions: 
    • I ask you to solve a programming problem without giving you a computer. This means that I don’t care about the code compiling and couldn’t care less about syntax issues. Had I cared, I would have provided you with an IDE. I won’t care if you miss out a semi-colon, or have a typo in your function name. In fact, if you’re not sure if there’s a function that does what you want, just pretend to invoke a function with a clear name and say that you’re not sure that there is a function by that name. 
    • If it’s critical for you – you can write down your answer on a piece of paper. In any other case, it’s better to answer on the whiteboard, so that I could see what you are writing and how does your thought process goes. I learn from the code you erase as much as from the code you don’t. When you are writing on paper I can learn mostly by looking at your expressions, and usually this doesn’t work in your favor. 
    • Don’t be silent. Tell me what you are about to do. Tell me about the problem that is preventing you from progressing. If you need to think quietly for a couple of minutes, tell me that you are taking a pause to think – I might even get out of the room for five minutes to provide you with some comfort. 
    • Work with examples, and make sure that your algorithm works for the examples you chose. 
    • I can see the code you’re writing. Either as you write it or shortly after. Use meaningful names. On top of demonstrating good coding habits, it helps me understand faster where are you going and what are you trying to do. If you write a function named “flipNextBit” I can tell what it should do even if I don’t see the implementation (or if it has a bug).
    • You cannot google during the interview, but you can ask me. 
    • Before the interview, google some coding interview questions and practice answering them on a whiteboard. Most will be much harder than what I usually ask. There are two types of difficulties in the coding question – not being able to find an algorithm that will solve the problem, and finding an algorithm but failing to transfer it to “code”. Practicing will help you with both types. Just getting accustomed to this type of question will increase the chance of you finding an algorithm quickly, and practicing on a whiteboard will free you from depending too much on an IDE. 
    • Most probably, you’ll have some mistake in your code on the first attempt. maybe an edge case you didn’t deal with, or something you overlooked. Don’t freak out once I lead you to such a failpoint. I don’t care if your code is working, I want to see how do you deal with your own mistakes. Do you freeze? Do you try to minimize the importance of the mistake (I had once heard a candidate refer to an off-by-one-bug that was applicable to every input as an “edge case” – don’t do that)? do you shrug your shoulders and fix it?
    • Yes, it’s a testing job. Yes, we use selenium sometimes. Don’t bother memorizing the selenium API – I don’t ask questions if the correct answer for them is “Google it”. 
    • If all of your programming education is some “automation course” you took, do yourself a favor and learn how to code properly. You don’t have to get a fancy diploma to prove that you can code, but you should have a solid understanding of data structures, polymorphism and recursion. Not all of those will come up during an interview, but all are fair game. 
  • Finally – ask for feedback. It’s still something I need to learn how to do, but I asked you to invest your time in coming to an interview with me – I will be happy to help you gain some benefit from it by pointing out what flaws I saw, so even if you don’t pass my interview, at least you can get a pointer or two and improve. 
* Also – if you happen to be looking for a new job (and are located in Israel) and want to hear some details, drop me a note. 
Continue Reading »

How to get latest nginx version for docker proxy image (zagorski software tester)

On March 11, 2017, in Syndicated, by Association for Software Testing

Reading Time: 1 minuteTL;DR In this blog post I will provide practice how to get latest nginx version aligned with docker documentation. You have web application, and you need proxy server. You decided to go with nginx using docker. Also, you need to modify original image, so you have your own Dockerfile that is based on official docker nginx … Continue reading How to get latest nginx version for docker proxy image

Continue Reading »

Well, That was a Bad Idea (Hiccupps)

On March 10, 2017, in Syndicated, by Association for Software Testing

I was listening to Giselle Aldridge and Paul Merrill on the Reflection as a Service podcast one morning this week as I walked to work. They were talking about ideas in entrepreneurship, assessing their value, when and how and with who they should be di…

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