For each of the areas in my introductory “5000-foot view” post, I will take some time and dig deeper into them and provide a little closer look at each region. Warning, this may get messy as we continue.All successful podcasts tend to hang on a central…
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…
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? →
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…
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.