On the test automation pyramid (again), opposing views and TestBash Manchester

Short blog post this time, since I’m smack in the middle of three projects while also preparing for my talk at TestBash Manchester, some training stuff and reviewing a book. It can’t always be long form!

With this blog post, I’d like to draw your attention to episode #31 of the Test and Code podcast, where Brian Okken (the host) replayed parts of the recordings of him being on another podcast, hosted by Paul Merrill. Paul’s a great guy and someone whose opinions and view I hold in high esteem, so I knew this was about to be good. In the interviel Paul and Brian did, they shared and discussed their opposing views on the test automation pyramid. By the way, more news about a collaboration (of sorts) between Paul and myself to follow soon!

It seems like Paul roughly shares my own views on the pyramid (read this recent blog post to see what I think of it and how I still use it, whereas Brian thinks the pyramid is falsely promoting the fact that unit tests are the most important tests you can write. Instead, in the recording, he advocates that there’s no value in software until it’s useful to an end user (be it a human being or another system) and that therefore UI tests are the most important and should be treated that way. I deliberately didn’t use the word ‘graphical’ here, by the way, since Brian talks mostly about writing tests for software where the GUI isn’t the interface that’s most extensively used.

You can listen to the podcast episode here. I thought it refreshing to listen to someone that has such an alternative view on a well-worn concept such as the test automation pyramid. Even though my own opinions on the model and its use remain unchanged (for now), I’ll try and make it a habit to listen to other voices and opposing views more often, rather than staying in my comfort zone and listening to podcasts and reading blogs on topics I’m already familiar with. Who knows I might learn a thing or two!

On another note, as I said before, I’m quite busy putting the finishing touches to my upcoming TestBash Manchester talk, and it’s both a talk and an event I’m very, very excited about. To those of you with Ministry of Testing Dojo Pro accounts, my talk will be available shortly after the event. For those of you that haven’t got such an account, you’ll have to wait for next week’s blog post, which will highly likely be a review of the event.

See you next week!

On writing and publishing my first ebook

Sometimes, some of the most interesting things in life happen when you least expect them. Just over half a year ago now (I looked it up, it was on May 11th of this year, to be exact) I received an email from Brian at O’Reilly Media, asking if I was interested in writing a short book on service virtualization. I didn’t have to think long about an answer and replied ‘yes’ the same day. After almost six months, lots of writing, reviewing and editing, many, many emails and a couple of video calls I am very proud to present to you my first ever ebook:

Service virtualization ebook

In this post, I’d like to tell you a little more about the book and about the process of writing and editing such a piece. Even though the book is relatively short (HPE, who’s sponsoring the book, set an upper limit of 25 pages of actual content), we went through much the same process as a full-length book would require, from proposal to production and everything in between.

The book
So, first, let’s take a look at the most important part: the end result. What we were aiming for was to give an overview of the current state of the service virtualization field and how this technique plays a role (or at least can play a role) in current and future IT trends. I won’t summarize the whole book here (it’s short enough so you can read it in about an hour) but if you want to know how service virtualization and Continuous Delivery can work together, or how you can leverage service virtualization when testing Internet of Things-applications, you’re cordially invited to read this book. It’s available free of charge from the HPE website, so why not take a look?

The writing process
After that initial email I received back in May, a lot has been taking place. Writing a piece like this starts with writing a proposal summarizing the prospective book outline, the reason why this book should be written, who is the target audience, and why the person writing the book proposal (i.e., me) thinks he or she is the right person for the job. This proposal is used to convince the sponsor (as I said, HPE, in this case) that they’re investing their money and effort wisely.

When the proposal is accepted, the actual writing starts. This is what takes up most of the time, but I think that goes without saying. We set two deadlines from the start: one date where a draft version of around 50% of the book should be delivered (to gauge whether the writer is on the right track and to keep things moving) and of course a deadline date for the first full draft.

As anybody who has ever written a book knows, once the first full draft is delivered, you’re not there yet. Not even close! An extensive reviewing and editing process has taken place to remove any spelling and grammatical errors, to improve the flow of the book and to make sure that all contents matched the expectations of HPE, of O’Reilly and last but not least of myself. This took a little longer than I initially thought it would, but then again, the end result is so much better than I could have produced on my own, so it has been very well worth the effort.

Thoughts
Would I do it again? You bet I would! I have thoroughly enjoyed the process of proposing, writing, reviewing and editing this book, even though at times it has been hard to review the same piece of text for the umpteenth time. Also, the guys and girls from O’Reilly, who have worked just as hard as I have myself (if not harder) to get this book out there, have been nothing less than fantastic to work with. So, Brian, Virginia, thanks so much, it was awesome working with you and I look forward to doing this again in some way, shape or form in the future. I also learned quite a few interesting things on the English language and editing standards. Since I’m a guy who’s always looking to improve his English skills, this has been quite invaluable too.

So if you’re ever in the position where you’re asked to write a book, or if you’ve ever thought about writing one yourself, I can wholeheartedly recommend going for it. Not only will you have something that you can be proud of once you’re finished, but you’ll learn so many things in the process.

Oh, and again, if you’re interested in a quick read on the current state of service virtualization, you can download the book for free from here. I’d love to hear your thoughts on it.

My article on service virtualization has been published on StickyMinds

On August 10th StickyMinds, a popular online community for software development professionals, published an article I wrote titled ‘Four ways to boost your testing process with service virtualization’. In this article, I describe a case study from a project I worked on recently, where service virtualization was used to significantly improve the testing process.

The article demonstrates (as you can probably guess from the title) how you too can employ service virtualization to remove some of the bottlenecks associated with testing and test data and test environment management for distributed systems and development processes.

You can read the article by visiting the StickyMinds homepage now. The article will be right there on the front page.

StickyMinds

Please let me know what you think in the comments! Also, feel free to share the article with your connections on social media.

Again, the article can be read here.