Sequence diagrams from text to SVG
Here’s a great sequence diagram creator; it turns a description of a sequence diagram in plain text into an SVG file. I’ve just tried importing one of the generated files into The Gimp at an enormous resolution, and it looks superb.
Here’s an example of a text description:
Title: Here is a title
A->B: Normal line
B-->C: Dashed line
C->>D: Open arrow
D-->>A: Dashed open arrow
This results in the following diagram, embedded here as a PNG graphic:
I like this kind of tool because it gets us back to the old Unix philosophy of small tools that do one thing well (…but this time around, we use JavaScript to wire them together.)
July 10, 2013
“Simply hold the ctrl key and double click on any non-button area of the window chrome - not the contents”
I work with software, a lot.
It’s probably safe to say I live software. So I’m comfortable with the idioms of software development and software use. The older I get the more I care about software usability. Excuse me while I just explode with apoplexy here at utterly insane software usability design.
My partner teaches courses on how to write for the web. Her background isn’t technical, so for her, a computer is just a toolkit to get stuff done. One of the tools in the toolkit is LibreOffice Impress, the software libre alternative to Microsoft Powerpoint. (Personally, I detest presentation software because it prioritises format over content and it’s so widely abused, but that’s a separate rant.)
Anyway, I noticed she’d accidentally pulled the “Slides” pane out of the UI into a separate window. I tried the usual stuff of dragging the window towards various nearly edges to get it to dock back into the main UI, to no avail. A bit of Googling turned up this solution: It’s necessary to hold the CTRL key while double-clicking on any non-interactive part of the undocked pane.
This is just beyond insane in so many ways I simply cannot find words to express my disgust at this user experience paradigm. It’s 2013. We’ve had graphical user interfaces since, I don’t know, 1985 on the Amiga and the mid-1990s on Windows PCs. There is no earthly reason, beyond utter contemptuous disdain for end users, to specify a user interface interaction that requires the user to hold down a meta key and perform an operation normally reserved for file icons. (When was the last time you double-clicked on a web app?) How am I supposed to figure this out? There is absolutely no cue provided by the interface to allow the user to discover this interaction by themselves. I can’t think of a single other user interface interaction convention which would lead me to try this warped combination of very specific actions all at the same time.
Is it the case now that interface designers are off the hook because no matter how obscure the steps required to perform an operation, Google will always serve up an answer provided to some other lost soul who previously found themselves in the same situation?
July 7, 2013
I’ve posted this link before, when this blog was on the late lamented Posterous, but when I went looking for it again, it had disappeared - so here it is again, for good measure. Hat tip to Kent Beck for originally tweeting about this article explaining Markov chains.
I’m reading some interesting follow-on papers, in particular, a pair by James A Whittaker (Yes, that James A Whittaker) “A Markov Chain Model for Statistical Software Testing” and “Markov Analysis of Software Specifications” as well as a graduate thesis by Ivan S. Zapreev entitled “Model Checking Markov Chains: Techniques and Tools”. I’m interested in the effect of a program’s cyclomatic complexity on the feasibility of using Markov chains for testing purposes.
Until now, I haven’t found formal proofs of anything other than trivial software systems to be convincing; they appear to rely on a perfect test oracle, namely a specification that’s so well specified that it may as well be the software system itself. Formal approaches such as Dijkstra’s tend to approach software systems in some idealised way, not as gloriously nonlinear entities executing on top of preemptively multi-tasking operating systems and making use of imperfect APIs over unreliable networks… and even if I concede that it’s possible to prove that a software system is internally perfectly consistent, that tells me nothing about how well that system actually solves the needs of the customer paying for it.
But in any case, I think Markov chains are worth exploring.
May 8, 2013
Stop using spreadsheets
If you use spreadsheet software, but you don’t use any mathematical functions, please stop right now. You’re inflicting pain on yourself and your readers.
Ugly presentation
By using a spreadsheet for purposes other than doing calculations, you’re choosing to skip the formatting that you would normally do for a document you expect to print out. Because you’re not thinking about formatting, you’re sacrificing legibility. For example, Excel doesn’t smoothly scroll horizontally across the page. The jarring cell-by-cell jumps are really unpleasant for your readers. Why are you presenting the data in a way that forces your readers to scroll?
A document has one author, but several readers. As the document author, the onus is on you to make your document as legible as possible. Wikipedia describes the message of Steve Krug’s book “Don’t Make Me Think” like this: “…a program or web site should let users accomplish their intended tasks as easily and directly as possible”. Exactly the same rule applies to documents as it does to programs.
The context is separate to the spreadsheet
I can’t remember the number of times I’ve received a spreadsheet whose explanatory text is in the accompanying email. Without the covering email, the spreadsheet loses important contextual information. What does all this stuff mean? Who is it important to? Where do I start? Is there any content on any of these other unlabeled worksheets? No? Why haven’t they been deleted?
No version control
By disseminating the spreadsheet by email, you’ve just created multiple competing copies of your document.
To your reader, the spreadsheet they have in front of them is the canonical version. Trouble is, they’re probably editing it right now to provide you with updated or corrected information. Let’s say they email their edits back to you (and the distribution list). Now you have the problem of manually merging their changes to produce the most up-to-date version. What did they change? Better check every row! Let’s assume you do the merge (without missing anything), and email the updated spreadsheet around to everyone again. Now there are 2 x (recipient list + you) copies out in the ether. Remember what I said about the canonical version of the spreadsheet being the one in front of your readers right now? Human fallibility being what it is, the chance that everyone is looking at the most up-to-date version is close to zero.
Microsoft Office does have reviewing and rudimentary version control built in, but these features don’t fix the problem of multiple stale copies of your document continuing to exist forever in email folders and saved in random places on other people’s desktop hard drives - or worse - network shares.
Tools like Sharepoint (primarily a web-based document repository which poorly emulates elements of wikis and version control systems) attempt to address this; instead of emailing the document, you save it to Sharepoint and email the link instead. However if your recipients open the link in any browser other than Internet Explorer, they lose the ability to use Sharepoint’s locking and versioning features. And you can’t control what browsers your recipients use.
Using a dedicated source-control system isn’t the answer either, because spreadsheets are binary blobs. Version control systems are designed to work with text, and only store the differences between successive versions, so that comparisons can be made between versions.
The solution
Use a wiki. This solves all of the problems I’ve described, quickly and easily. There are many wikis out there; some of them can be up and running in minutes. Many offer rich-text editors. Others support only Markdown, a simple text markup language.
Just enough presentation
Wiki pages can be as pretty as newspaper layouts; take a look at any Wikipedia page. You’ll see a table of contents, probably a boxout containing summary information, and the information on the page presented under headings. Tabular data is easily readable. Editing the tabular data in Markdown is straightforward too, though a little more complex than using Excel. Remember, as the document author, the onus is on you to make your content decipherable, not on your readers to decipher it. Wikis encourage you to format your data, but only to a certain extent. Enough formatting is enough.
In-line context
You’re back in the land of free-text; you no longer have to fight with cell formatting (merge cells, wrap text, text alignment…). You can simply provide an introductory paragraph for your readers, before proceeding to the meat of the data. You were going to write that in the covering email anyway, right?
Built-in version control
There’s only one version of a wiki page - the one at the link you provide. Your readers can edit the page in their browsers and hit “Save” - and everyone gets to see their updates immediately, or at least on the next page refresh. If two readers are simultaneously editing the current version, the second editor to save their changes will get a warning that there have been changes to the page since they started editing. The onus is now on your readers to manage merging, not you. If someone over-writes changes accidentally, it’s a simple matter to roll back to an earlier version.
If you really need to, you can enable role-based access control, so that every user has to be authenticated before they can make edits. (…but why would you want this? Presumably you’re trying to foster collaboration and information exchange. Why prevent stakeholders from contributing?)
Summary
It’s easy to reach for a spreadsheet in order to quickly knock out some tabular data - but please think again before doing it next time. Your quickly-assembled spreadsheet is likely to live a lot longer and have a broader readership than you anticipate. Do yourself and all of your readers a favour, install a wiki and use that instead. They’ll thank you for it.
March 13, 2013
What we’re actually doing when interacting with an ‘intuitive’ interface
I’ve become pretty cheesed off with the term ‘intuitive’, as in ‘this shiny touch interface is so intuitive’.
I get to observe my 87-year old intelligent-but-half-blind mother negotiating web pages and desktop applications. Her efforts to learn the conventions of modern GUI interaction have shown me that what us techies consider the application of intuition is, in fact, the application of a rich set of contradictory heuristics about visually subtle and temporally fleeting graphical cues.
There is absolutely no consistency at all to GUI design - that’s why, when we’re confronted with something that causes those heuristics to break, we’re lost. Right-click? Apple-click? Double-click? Pinch-to-zoom? Swipe-to-dismiss? I don’t think any of us figured those out for ourselves, much as we’d like to think we did.
August 16, 2012
Opinions change!
Reviewing some of the older posts on this blog, I’m surprised at some of the statements I’ve made in the past about the function and nature of testing; my approach to testing has evolved more than I think over the years!
First of those changes is my rebuttal of the term ‘Quality Assurance’, or ‘QA’, to define the role of the tester. I consider the term ‘QA Engineer’ equivalent to overblown titles like ‘Sanitation Engineer’ and ‘Social Media Evangelist’. On an Agile team, it’s not the responsibility of one person to ‘assure quality’, as though some sort of referee were needed to keep those wayward developers in line. This may sound heretical, but in fact it’s the whole team’s job to assure quality. In my experience, that’s best done by teams using Agile techniques. Not just some pick-and-mix Agile approach, but by adhering to the Agile principles in general and to methodologies like Scrum or XP in particular. I detest the term ‘best practice’, but I can tell you that the teams that I’ve worked on that got closest to a pure Agile approach also produced the best quality software.
I’m also in a period of evolution regarding automated testing; most of my early experience of it was so bad that I really doubted whether it could bring business value. Now, being more familiar with the tools of automated testing, and having a better appreciation of where automation provides most value, I’m a strong advocate, but perhaps I’ve swung too far and don’t practice enough exploratory testing. All my testing now is repeatable, but I wonder if my attention is as broad as it was when I was a purely manual tester. I’m with Michael Bolton and the other folks in the Context-driven school when they say it’s important to draw a distinction between automated checks and sapient manual tests. They are not equivalent.
Another area where my thinking is evolving is in the field of testing metrics. It’s easy to collect and collate data on testing, but it’s hard to do that in a way that actually gives a useful view of the state of the project, or the readiness of the software for production. Right now, I don’t believe that a few bald numbers can do that (especially not bug counts, even when graphed against historical statistics). I’m more of the view that a holistic, conversational story about the state of the project is more likely to provide stakeholders with the information that they need. (That’s some statement, coming from an arch-rationalist like me.)
And this brings us to the crux of it: testing is about providing relevant information to stakeholders so that they can make the decision about whether this release is fit for production. Just as customers are now expected to engage in the development cycle at periodic intervals, so project stakeholders must ensure that they are informed about the state of the project at every stage, not just in the weeks before the go-live date or during the hardening sprint. Us testers must engage with these stakeholders all the way along to ensure that we’re providing good information.
So, on my older posts, caveat lector - let the reader beware. If you see something in a new or old post that you agree or disagree with, let me know and we can have a conversation. I’m always interested in honing my thinking on testing and in hearing new ideas. Changing an opinion in the light of new evidence is not a weakness, it’s a foundation of science. As Jeff Atwood explains, to avoid confirmation bias, it’s best to have strong opinions, weakly held.
Finally, a big thank you to those people who care enough about testing to have challenged and engaged me over the years. Among my colleagues: Frank Somers, Chaminda Peiris, Sisira Kumara, Augusto Evangelisti and Cormac Redmond. Of the folks I know via the net and through books: James Bach, Cem Kaner, Michael Bolton, Jerry Weinberg, Robert Glass and Michael Nygard. Thanks to all of you, whether we agreed on things or not!
May 26, 2012