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 […]
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 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().
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…]
“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… […]
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.
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.
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.
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…..
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.
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 –
- 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)
- 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).
- 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, ועל איך ליצור ניסויים שבטוח להיכשל בהם. אחת מההנחות שהיו לה שם היא שבודקי תוכנה טובים במציאת בעיות, ואילו מפתחי תוכנה טובים במציאת מגוון פתרונות (כולל כאלה שלא לגמרי עובדים).
רק רגע, מה זאת אומרת “בודקי תוכנה לא טובים בלמצוא פתרונות”? בטח שאני יכול לעשות את זה. אני פותר בעיות בעבודה כל הזמן. לא ככה?
היו שני דברים שגרמו לי לבחון מחדש את ההנחה הזו שלי. הדבר הראשון היה שיחה שהייתה לי עם ליז בערב שלאחר יום הסדנאות, בה בקשת הדגמה הובילה לרצף מהיר של שאלות שבסופו נותרתי עם תחושת “אה, כזה…”, והשני היה רגע קצר במהלך ההרצאה שם היא הזכירה את הנטייה האנושית להגיב לכל רעיון חדש ב”זה לא יעבוד כי…”, בו שמתי לב שזו פחות או יותר התגובה האוטומטית שלי להרבה מאוד דברים.
אז, האם בודקי תוכנה פחות יעילים במציאת פתרונות? האם בודקי תוכנה כל כך מוגבלים על ידי איתור הבעיות האפשריות עד שהם לא מסוגלים לפעול?
ככל שאני חושב על זה יותר, הנטייה שלי היא לומר “כן”. ככלל אצבע, אני בהחלט יכול לראות איך האמירה הזו נכונה. כמובן, לא מדובר כאן בשאלה בינארית של כן ולא, אלא בסקאלה – והנקודה המדוייקת בה אדם נמצא על סקאלה מושפעת מגורמים נוספים (כמו ניסיון עבר בבעיות דומות, כמו מידת הידע על תחום הבעיה, וכד’). עם זאת, באופן כללי זה מאוד הגיוני. בודקים נדרשים מדי יום למצוא בעיות אפשריות בפתרונות, למצוא חורים במודלים המושלמים של אחרים ולאתר את נקודות החולשה שלהם. מפתחי תוכנה, מצד שני, מתחילים כמעט כל משימה חדשה באמת ב”הוכחת היתכנות”, פיתרון חלקי שנכתב במהירות ולא מקיים את כל הדרישות מהמוצר המוגמר, אבל הכנה שלו מאפשרת למתכנת ולצוות ללמוד איך צריך לעשות את הדברים. אני מניח באופן אוטומטי שאני מסוגל לבדוק תוכנה טוב יותר מאשר מפתחים עם ניסיון מקביל לשלי, ושהם מתכנתים טוב יותר ממני, כי כל אחד מאיתנו השקיע מאמצים בפיתוח היכולת המרכזית שלו. אני “גם מתכנת”, ומפתח טוב “גם בודק”, אבל תחומי העניין והמיקוד שונים. אלא שתרגול של יכולת מסויימת לא מוביל רק לשיפור של היכולת הזו, אלא גם לשינוי דפוסי המחשבה וההרגלים בהתאם. ואם יש יכולת אחרת שבמקרה מנוגדת ליכולת שאני משקיע בה מאמץ, יהיה קשה יותר לרכוש אותה.
ועוד משהו אחד שכדאי לזכור – ההבדל הזה הוא עניין של הרגל (ושל נטייה טבעית ראשונית), לא גזירה משמיים. יש אנשים שמסוגלים להחליף בין התפקידים השונים ובין צורות המחשבה השונות (נדמה לי ששמעתי מישהי מספרת על כך שלוקח לה בערך שבוע לעשות את המעבר המחשבתי הזה).
שלושה דברים שנשארו איתי בעקבות ההרצאה של ליז:
- יש מקום חשוב לגישה ה”פסימית”ולשאילת השאלות הקשות בתחילת הדרך. זה חלק ממה שמאפשר לנו לערוך ניסויים שבטוח להיכשל בהם (וזה, כזכור, היה נושא ההרצאה).
- גם לי יש את המגבלות שלי. זה נחמד לאגו שלי כשאני מתעלם מהן, אבל אם אני מודע לנקודות החולשה שלי אני יכול לעשות משהו כדי לפצות עליהן, או כדי לוודא שהן מתבטאות במקום הנכון (למשל – כשישבתי עם אחד המפתחים אצלנו על ארכיטקטורה של רכיב חדש, החלטתי להקשיב עד הסוף ולכתוב את השאלות שלי – עד שהוא סיים, חצי מהן כבר קיבלו תשובה, והשאלות שנותרו קיבלו יותר תשומת לב והיו רלוונטיות יותר. איך זה קשור? כי כשניגשתי למשימה עם מודעות לכך שזה לא חייב להיות פיתרון מושלם מייד בהתחלה, הבעיות הקטנות שראיתי לא חסמו אותי מלבחון את המכלול השלם).
- אני צריך לתרגל קצת את הגישה של “בואו נעשה את זה ונראה מה יצא” – נכון, אני בודק תוכנה, אבל לכולם יש בעיות שצריך לפתור, ולפעמים צריך לדעת לשים בצד את כל הפחדים והחסמים כדי לעשות משהו. אני יודע לעשות את זה עד רמה מסויימת, כדאי להשתפר בזה קצת. כל עוד אני לא מזניח את הפסימיות המקצועית שלי, זה כלי שכדאי שיהיה בארגז הכלים שלי.
TL;DR In this post I will describe my heuristic for web page cache testing that failed and why it failed. Web page cache is mechanism that stores parts of web page that does not change a lot in browser local storage. Hard part is to figure which part of page is not changing very often. … Continue reading Web page cache heuristic that failed →
(No Hebrew for this, it’s quite long as it is, and the main audience for this post are the Organizers of ETC, none of whom speaks Hebrew to the best of my knowledge)At first, I thought of naming this post “ETC – the good, the bad and the ugly”, only th…
Managers. They’re the light in the fridge: when the door is open their value can be seen. But when the door is closed … well, who knows?
Johanna Rothman and Esther Derby reckon they have a good idea. And they aim to show, in the form of an extended story following one manager as he takes over an existing team with problems, the kinds of things that managers can do and do do and – if they’re after a decent default starting point – should consider doing.
What their book, Behind Closed Doors, isn’t – and doesn’t claim to be – is the answer to every management problem. The cast of characters in the story represent some of the kinds of personalities you’ll find yourself dealing with as a manager, but the depth of the scenarios covered is limited, the set of outcomes covered is generally positive, and the timescales covered are reasonably short.
Michael Lopp, in Managing Humans, implores managers to remember that their staff are chaotic beautiful snowflakes. Unique. Individual. Special. Jim Morrison just says, simply, brusquely, that people are strange. (And don’t forget that managers are people, despite evidence to the contrary.)
Either way, it’s on the manager to care to look and listen carefully and find ways to help those they manage to be the best that they can be in ways that suit them. Management books necessarily use archetypes as a practical way to give suggestions and share experiences, but those new to management especially should be wary of misinterpreting the stories as a how-to guide to be naively applied without consideration of the context.
What Behind Closed Doors also isn’t, unlike so much writing on management, is dry, or full of heroistic aphorisms, or preachy. In fact, I found it an extremely easy read for several reasons: it’s well-written; it’s short; the story format helps the reader along; following a consistent story gives context to situations as the book progresses; sidebars and an appendix keep detail aside for later consumption; I’m familiar with work by both of these authors already; I’m a fan of Jerry Weinberg’s writing on management and interpersonal relationships and this book owes much to his insights (he wrote the foreword here); I agree with much of the advice.
What I found myself wanting – and I’d buy Rothman and Derby’s version of this like a shot – is more detailed versions of some of the dialogues in this book with commentary in the form of the internal monologues of the participants. I’d like to hear Sam, the manager, thinking though the options he has when trying to help Kevin to learn to delegate and understand how he chose the approach that he took. I’d like to hear Keven trying to work out what he thinks Sam’s motives are and perhaps rejecting some of Sam’s premises. I’d also like to see a deeper focus on a specific relationship over an extended period of time, with failures, and techniques for rebuilding trust in the face of them.
But while I wait for that, here’s a few quotes that I enjoyed, loosely grouped.
On the contexts in which management takes place:
Generally speaking, you can observe only the public behaviors of managers and how your managers interact with you.
Sometimes people who have never been in a management role believe that managers can simply tell other people what to do and that’s that.
The higher you are in the organization, the more other people magnify your reactions.
Because managers amplify the work of others, the human costs of bad management can be even higher than the economic costs.
Chaos hides problems—both with people and projects. When chaos recedes, problems emerge.
The moral of this fable is: Focus on the funded work.
On making a technical contribution as a manager:
Some first-level managers still do some technical work, but they cannot assign themselves to the critical path.
It’s easier to know when technical work is complete than to know when management work is complete.
The more people you have in your group, the harder it is to make a technical contribution.
The payoff for delegation isn’t always immediate.
It takes courage to delegate.
You always have the option not to coach. You can choose to give your team member feedback (information about the past), without providing advice on options for future behavior.
Coaching doesn’t mean you rush in to solve the problem. Coaching helps the other person see more options and choose from them.
Coaching helps another person develop new capability with support.
And it goes without saying, but if you offer help, you need to follow through and provide the help requested, or people will be disinclined to ask again.
Helping someone think through the implications is the meat of coaching.
Jelled teams don’t happen by accident; teams jell when someone pays attention to building trust and commitment
Over time they build trust by exchanging and honoring commitments to each other.
Evaluations are different from feedback.
A one-on-one meeting is a great place to give appreciations.
[people] care whether the sincere appreciation is public or private … It’s always appropriate to give appreciation for their contribution in a private meeting.
Each person on your team is unique. Some will need feedback on personal behaviors. Some will need help defining career development goals. Some will need coaching on how to influence across the organization.
Make sure the career development plans are integrated into the person’s day-to-day work. Otherwise, career development won’t happen.
“Career development” that happens only once a year is a sham.
On problem solving:
Our rule of thumb is to generate at least three reasonable options for solving any problem.
Even if you do choose the first option, you’ll understand the issue better after considering several options.
If you’re in a position to know a problem exists, consider this guideline for problem solving: the people who perform the work need to be part of the solution.
We often assume that deadlines are immutable, that a process is unchangeable, or that we have to solve something alone. Use thought experiments to remove artificial constraints,
It’s tempting to stop with the first reasonable option that pops into your head. But with any messy problem, generating multiple options leads to a richer understanding of the problem and potential solutions
Before you jump to solutions, collect some data. Data collection doesn’t have to be formal. Look for quantitative and qualitative data.
If you hear yourself saying, “We’ll just do blah, blah, blah,” Stop! “Just” is a keyword that lets you know it just won’t work.
When the root cause points to the original issue, it’s likely a system problem.
Some people think management is all about the people, and some people think management is all about the tasks. But great management is about leading and developing people and managing tasks.
When managers are self-aware, they can respond to events rather than react in emotional outbursts.
And consider how your language affects your perspective and your ability to do your job.
Spending time with people is management work.
Part of being good at [Managing By Walking Around and Listening] is cultivating a curious mind, always observing, and questioning the meaning of what you see.
Great managers actively learn the craft of management.