Syndicated

So You Want To Produce a Podcast? Part One: The 5,000 Foot View (TESTHEAD)

On February 27, 2017, in Syndicated, by Association for Software Testing
0

I need to thank Saron Yitbarek. She posted a tweet that had me laughing last night, as she was talking about how she needed to edit a podcast, but that she was procrastinating the editing, and she wanted to write a blog post about podcasting instead.Pl…

Scrum testing heuristic: Is feature usable? (zagorski software tester)

On February 25, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 1 minuteTL;DR This post will describe how I test in project that uses scrum. Tool is Jira and context is early development phase. We have in JIRA workflow QA phase. Frontend has code reviews and developers are able to test (there is no automation) what they code using browser. Here is how I test in described context. Feature … Continue reading Scrum testing heuristic: Is feature usable?

The Testing Kraftwerk (Hiccupps)

On February 24, 2017, in Syndicated, by Association for Software Testing
0

If you’re around testers or reading about testing it won’t be long before someone mentions models. (Probably after context but some time before tacit knowledge.)As a new tester in particular, you may find yourself asking what they are exactly, these mo…

A Recent Encounter with Dark Patterns (Nicky Tests Software)

On February 21, 2017, in Syndicated, by Association for Software Testing
0

I first came across the term of “dark patterns” when I saw Emma Keaveny’s talk about it on The Dojo. While watching it, then later looking more into it, I realised how many companies are out there purposely trying to get the user to do something, the u…

It’s official – I will speak at Romanian testing conference 2017 (Mr.Slavchev())

On February 21, 2017, in Syndicated, by Association for Software Testing
0

It is already official my talk about “Test automation – the bitter truth” was approved for this year’s edition of RTC – Romanian testing conference which will be held May 10-12, 2017 in Cluj-Napoca, Romania You can find more information about the talk here: http://www.romaniatesting.ro/sessions/test-automation-the-bitter-truth/ And you can find the full program of the event here: http://www.romaniatesting.ro/program/ I […]

The post It’s official – I will speak at Romanian testing conference 2017 appeared first on Mr.Slavchev().

SoapUI: Configuring Rest Services Without WADL (Assert.This)

On February 20, 2017, in Syndicated, by Association for Software Testing
0

I originally wrote this post for the TestHuddle How To… SoapUI Series. You can check out the original here, at their site. While you’re there, have a look at the posts by some of the other authors.. Despite the name, SoapUI can be used for testing Restful as well as SOAP based apis. There are … [Read more…]

Help Linnea (Magnifiant: exploring software testing)

On February 20, 2017, in Syndicated, by Association for Software Testing
0

“There is a saying that it takes a whole village to raise a child. Now we need a whole village to save our Linnea” Linnea, Kristoffer Nordströms daughter, is five and a half years and comes from Karlskrona in Sweden. Her world revolved up until recently around My Little Ponies, riding her bicycle and popcorn… […]

Before Testing (Hiccupps)

On February 20, 2017, in Syndicated, by Association for Software Testing
0

I happened across Why testers? by Joel Spolsky at the weekend. Written back in 2010, and – if we’re being sceptical – perhaps a kind of honeytrap for Fog Creek’s tester recruitment process, it has some memorable lines, including:

what testers are supposed to do … is evaluate new code, find the good things, find the bad things, and give positive and negative reinforcement to the developers.

Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares.

you really need very smart people as testers, even if they don’t have relevant experience. Many of the best testers I’ve worked with didn’t even realize they wanted to be testers until someone offered them the job.

The job advert that the post points at is still there and reinforces the focus on testing as a service to developers and the sentiments about feedback, although it looks like, these days, they do require test experience.

It’s common to hear testers say that they “fell into testing” and I’ve offered jobs to, and actually managed to recruit from, non-tester roles. On the back of reading Spolsky’s blog I tweeted this:

#Testers, one tweet please. What did you do before testing? What’s the most significant difference (in any respect) between that and now?

— James Thomas (@qahiccupps) February 18, 2017

And, while it’s a biased and also self-selected sample (to those who happen to be close enough to me in the Twitter network, and those who happened to see it in their timeline, and those who cared to respond) which has no statistical validity, I enjoyed reading the responses and wondering about patterns.

Please feel free to add your own story about the years BT (Before Testing) to either the thread or the comments here.
Image: https://flic.kr/p/rgXeNz

The Good of Event Sourcing – Conflict Handling, Replication and Domain Evolution (The Continuous Improver)

On February 19, 2017, in Syndicated, by Association for Software Testing
0

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 introductionary presentation about 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 talking about the awesomeness of projections last time, let’s talk about some more goodness.

Conflict handling becomes a business concern

Many modern systems are build with optimistic concurrency as underlying concurrency principle. So as long as two or more people are not doing things on the same domain object, everything is fine. But if they do, then the first one that manages to get its changes handled by the domain wins. When the number of concurrent users is low this is usually fine, but in a highly concurrent website such as an online bookstore like Amazon, this is going to fall apart very quickly. At Domain-Driven Design Europe, Udi Dahan mentioned a strategy in which completing an order for a book would never fail, even if you’re out of books. Instead, he would hold the order for a certain period of time to see if new stock could be used to fulfil the order after all. Only after this time expires, he would send an email to the customer and reimburse the money. Most systems don’t need this kind of sophistication, but event sourcing does offer a strategy that allows you to have more control on how conflicts should be handled; event merging. Consider the below diagram.

clip_image001

The red line denotes the state of the domain entity user with ID User-Dedo as seen by two concurrent people working on this system. First, the user was created, then a role was granted and finally his or her phone number was added. Considering there were three events at the time the this all started, the revision was 3. Now consider those two people doing administrative work and thereby causing changes without knowing about that. The left side of the diagram depicts one of them changing the password and revoking a role, whereas the right side shows another person granting a role and changing the password as well.

When the time comes to commit the changes of the right side into the left side, the system should be able to detect that the left side already has two events since revision 3 and is now at revision 5. It then needs to cross-reference each of these with the two events from the right side to see if there are conflicts. Is the GrantedRoleEvent from the right side in conflict with the PasswordChangedEvent on the left? Probably not, so we append that event to the left side. But who are we to decide? Can we take decisions like these? No, and that’s a good thing. It’s the job of the business to decide that. Who else is better at understanding the domain?

Continuing with our event merging process, let’s compare that GrantedRoleEvent with the RoleRevokedEvent on the left. If these events were acting on the same role, we would have to consult the business again. But since we know that in this case they dealt different roles, we can safely merge the event into the left side and give it revision 6. Now what about those attempts to change the passwords at almost the same time? Well, after talking to our product owner, we learned that taking the last password was fine. The only caveat is that the clock of different machines can vary up to five minutes, but the business decided to ignore that for now. Just imagine if you would let the developers make that decision. They would probably introduce a very complicated protocol to ensure consistency whatever the cost….

Distributed Event Sourcing

As you know, an event store contains an immutable history of everything that ever happened in the domain. Also most (if not all) event store implementations allow you to enumerate the store in order of occurrence starting at a specific point in time. Usually, those events are grouped in functional transactions that represent the events that were applied on the same entity at the same point in time. NEventStore for example, calls these commits and uses a checkpoint number to identify such a transaction. With that knowledge, you could imagine that an event store is a great vehicle for application-level replication. You replicate one transaction at the time and use the checkpoint of that transaction as a way to continue in case the replication process gets interrupted somehow. The diagram below illustrates this process.

clip_image002

As you can see, the receiving side only has to append the incoming transactions on its local event store and ask the projection code to update its projections. Pretty neat, isn’t it. If you want, you can even optimize the replication process by amending the transactions in the event store with metadata such as a partitioning key. The replication code can use that information to limit the amount of the data that needs to be replicated. And what if your event store has the notion of archivability? In that case, you can even exclude certain transactions entirely from the replication process. The options you have are countless.

But if the replication process involves many nodes, a common problem is that you need to make sure that the code used by all these nodes is in sync. However, using the event store as the vehicle for this enables another trick: staggered roll-outs. Since events are immutable, any change in the event schema requires the code to keep supporting every possible past version of a certain event. Most implementations use some kind of automatic event up-conversion mechanism that enables the domain to only need to support the latest version. But because of that, it becomes completely feasible for a node that is running a newer version of the code to keep receiving events from an older node. It will just convert those older events in whatever it expects and continue the projection process. It will be a bit more challenging, but with some extra work you could event support the opposite. The older node would still store the newer events, but hold off the projection work until it has been upgraded to the correct version. Nonetheless, upgrading individual nodes probably already provides sufficient flexibility.

Keeping your domain and the business aligned

So you’ve been doing Event Storming, domain modeling, brain storming and all other techniques that promise you a chance to peek into the brains of those business people. Then you and your team go off to build an awesome domain model from one of the identified bounded contexts and everybody is happy. Then, after a certain period of production happiness, a new release is being build and you and the developers discover that you got the aggregate boundaries all wrong. You simply can’t accommodate the new invariants in your existing aggregate roots. Now what? Build a new system? Make everything eventual consistent and introduce process managers and sagas to handle those edge cases? You could, but remember, your aggregates are dehydrated from the event store using the events. So why not just redesign or refactor your domain instead? Just split that big aggregate into two or more, convert that entity into a value object, or merge that weird value object into an existing entity. Sure, you would need more sophisticated event converter that know how to combine or split one or more event streams, but it surely cheaper than completely rebuilding your system…..

clip_image003

Now if you were not convinced yet after reading my last post, are you now? Do you see other cool things you could do? Or do you have any concerns to share? I’d love to hear about that by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for a better architecture style.

Anything you can do, can I do better? (אשרי אדם מפחד תמיד Happy is the man who always fears)

On February 19, 2017, in Syndicated, by Association for Software Testing
0

Another ETC post. There are others:
Tutorial days
Conference days
My retrospective

Up until recently, I was assuming something very simple: There’s nothing an average developer can do that I can’t (and vice versa) – Yes, there are some differences in the experience we have,  but overall we have the same basic training, speak the same language and discuss software design with each other. So, with the exception of those superstars you see here and there that are clearly better programmers than their peers, I considered myself equal.

Then I went to ETC, where I heard Liz Keogh speaking on Cynefin, and creating safe-to-fail experiments. One of the basic assumptions she has there is that testers are good at finding problems, and developers are good at coming up with ideas to solving problems (even ideas that don’t work). What does it mean “testers are not good at coming up with solutions”? Surely I can do that, I solve problems all the time at work. Don’t I?
There were two things that happened and pretty much convinced me there is a point in this. The first, is the talk I had with Liz after the tutorial day where I was bombarded with a series of questions that led to that “oh…” moment, and the second is Liz talking about how people have tend to respond to new ideas with the phrase “That won’t work because…”, which I realized that I do a lot.
So, are testers less efficient in find solutions? Are testers so constricted by spotting possible fail points that they can’t act?
The more I think about it, I tend to say yes. As a general rule of thumb, I can see how this can be true. Of course, this is not a yes\no question, but rather a scale – and the exact position on which a person stands had some other factors that affect it (such as the experience in doing similar things, knowledge of the field in which an action takes place, etc.), but in general, it makes a lot of sense – Testers are tasked, on a day to day basis, to find potential problems, to poke at the perfect model someone has built and find weak spots in it. Developers, on the other hand, start almost every really new task by “creating a proof-of-concept”, something that will sort-of work and teach them how to approach the problem in full scale. I take it for granted that I test better than most developers with equivalent experience because I have invested a lot of time in becoming better at it, and that they are probably better at coding since this is what they practice. But practicing a skill does not only mean getting better at it, it means tuning your mind and habits to it, and if some other skill is opposed to that, it will be that much harder to acquire.
Also, one other thing that is important to keep in mind – This mindset is not the permanent. People can, and do function successfully in both roles, though probably not simultaneously (I think I recall someone saying it takes them about a week to do this mental shift).

I took three things out of Liz’s talk –

  1. There is an important place for asking the difficult questions when setting out to try and solve something. It part of what makes an experiment “safe to fail” (which was the title of the talk). Putting this kind of lens gives me another tool that will help presenting questions at the context they are relevant to (e.g. – not going into “where should we put this bit” during a high level description)
  2. I, too, have my limitations. Now that I’m aware of one of them, I can act to make sure it’s used properly (for instance, when I spoke with one of the developers in the team about the architecture of a new piece of software we’re planning, I wrote down my questions instead of interrupting. By the end of his explanation, half of the questions were answered, and I could provide feedback that was more relevant. And how is litening relevant to Liz’s talk? Knowing that what I’m about to hear is an imperfect solution that “generally works”, the small problems were no longer blockers, and so writing them down is more useful than stopping the whole train of thought). 
  3. I need to practice my “let’s do it” mindset – It’s true that I’m a tester, but I still need to solve some problems, and there’s more to me than just work. As long as I keep tabs on my “professional pessimism”, being able to flow with an idea is useful.


זה פוסט נוסף על כנס הבדיקות האירופאי. כתבתי עליו קצת קודם (באנגלית בלבד):
יום הסדנאות
ימי הכנס
משוב קצר

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

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

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

שלושה דברים שנשארו איתי בעקבות ההרצאה של ליז:

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

Page 1 of 39712345...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!