This article is about a talk I gave on 9/15/2011 to the Kansas City Endpoint User Group. The slides I used are attached to this article but they aren't much help without the talk notes.
My talk was originally regarding some things I've been working on lately to do automated acceptance testing of Workflow applications using a tool called Watir. Although the talk and this article cover Watir, I started to realize that automated testing was just one aspect of building better workflows. So that's the direction I took it and this is the result.
There are three main talking points, they are:
- Talking to your users
- Automated testing
- Opinions/Thoughts
Why Should I Do This?
There's a slide that addresses this in a joking manner but in all seriousness, it really pays off when you're working on a non trivial project that's long lived and may require extra work 6 months to a year down the road. A little pragmatism goes a long way.
Talking To Your Users
Communication Is Paramount
You know that thing called talking that you don't like doing because you feel like everyone is a moron? They might be, but the good news it that you don't need to talk as much as you need to listen. It may sound like you need to take orders, you don't. Listen to an idea from a user and if you agree that's great, if not try iterating on the idea until the two of you both like it or you can come to a suitable compromise. Also, don't be a afraid to say no, I'll talk more about this a little later on.
Gathering Requirements
User Stories
There are 2 different ways I approach doing a Workflow project and it's usually depending on the size and complexity of the project that determines which method I'll use. The first an approach similar to story carding where I collect what is called a "User Story". A user story is just a short sentence or two about how a particular feature should work. Here are two examples:
"When I visit the homepage, after signing in, I should be able to see all my tasks"
"When I click on a task, I should be able to reassign it to John."
The two examples above are luckily already handled if you're integrating your process into the process manager that ships with workflow but if not, it becomes pretty clear about what functionality you need to create in order to satisfy the needs of the stakeholders. I've included a bit of a blueprint below that I find works well.
As a:
I want to:
So that:
And then maybe attach an estimation time to it, estimating is tough so if you don't feel comfortable giving an estimate right away, say so.
Documentation or README Driven Development
The other method I've found to work particularly well on small projects is to do documentation driven development. Let's take something simple for example such as a server request workflow. The server group wants to have users visit a singular location to request server resources. Fire up word or google docs and either write a full document on how to use the new service or just a steps 1-10 quickstart guide. Have the server group look at this and ask them if this is what they would like to see. Once you both have a document you agree on, build it.
If #2 on your quickstart guide says to enter the name of the new server in the "Server Name:" textbox, make sure you have a Server Name textbox. If #5 says to select a data by which the server needs to be operational, make sure you are supporting that as well. There are 2 benefits to this:
- It's hard to mess up when you're following a document that explains in detail how a system should work
- When you're done building there's no need to write your documentation or user guide, it's already done. This avoids the need to come back around and document the system, this is especially bad if you put it off for weeks or months, having to come back to the system and remember how things work in order to document them.
Your Greatest Asset Is "No"
It's human nature to say "yes". It's easier for us, it avoids friction. Saying "yes" makes you feel valuable. "Hey Jim, on this project we've got going, I know it's not on the schedule or documented but do you think we could change the box on that first form and have it email Susan when they enter a number?" This may not feel like a big request and you might knock it out in an hour or two but there are some long term negative consequences for always saying "yes" to these type of requests.
You may:
- Handle a bunch of undocumented, not agreed on changes instead of using that time towards larger requirements (stories)
- Maybe you put in some extra time to add these things outside of regular hours.
- This is fine once in a while but you're losing personal time that might be spent resting, exercising, or spending time with family
- You're also giving up time that could be spent on personal goals (i.e -> learning rock climbing)
- Begin outputting late or lower-quality work
Besides the personal things you may end up sacrificing by working on such requests if you get enough of them it could lead to both scope creep and missing a project deadline. One personal example I can give is I had a request to add in reporting to a project for an internal group to be able to run metrics within the interface we built. We said no and they now use the company standard reporting tools and the reporting group built it out using the data I gathered. The reporting tools that they use are much better and they were able to setup reporting much more quickly and non stakeholders are able to consume the data without needing to be familiar with another system.
Automated Testing
The next thing I think you can do to help you build a better application is to use automated testing. Computers are great at automation so let them do the work. This probably only pays off on bigger projects since there is some work involved in getting it setup and learning the syntax of the test framework if you don't already know it.
I've worked on several projects with Workflow and only 2 of them have been big enough that I would say you gain something by doing some type of automatic acceptance testing. Your simple every day "vacation request" or monitoring project for "send an email when drive C: has less than 2GB free space" are probably not going to be complex enough since you can test them by hand rather quickly.
You might be asking "What does he mean by automated testing?" Well, it's simple really, I'm referring to using some extra tools to connect to your forms or webservices and either input or retrieve some data (or both) and verify that what happens is what you expect. In one of the bigger workflow projects I have, I have some tests written that open the homepage, fill out the form, submit it and verify that the highest ID # in my database incremented (this verifies a DB entry was written).
You can also do something such as login to the process manager and open a task and verify it contains information submitted via your form, if you're utilizing the process manager. This is some work up front but once you have the tests written out you can run them after you add some functionality to verify that you haven't broken anything, this is called regression testing.
Tools
There are 2 tools that I've tried, mostly because I was already familiar with them. They are:
- Watir + Test Unit (what I'll show shortly)
- Selenium + Test Framework (frameworks such as JUnit, NUnit, RSpec, Test Unit)
Watir and Selenium can both support multiple browsers and frameworks although Watir is going to be limited to those frameworks which are common to the Ruby language (Rspec, Cucumber, Test Unit). I run this setup on mac but it will work just as well in Linux or Windows. On mac you should already have Ruby version 1.8.2 or 1.8.7 installed along with RubyGems being setup already. For windows users, please see here to download the rubyinstaller for windows and then here to setup RubyGems (after you run the RubyInstaller). RubyGems lets you easily install libraries (called gems) that we will need a little later on.
Watir stands for Web Application Testing In Ruby. It is a browser automation library where you write tests in your framework of choice, Test Unit in this example. You basically instruct firefox or IE to connect to your application and run some checks and then test what it did to make sure things match up. Selenium is a little more automated, it records what you do with a mouse and keyboard while you're in the browser and then will automatically generate that code for you. You still need to wrap assertions around the instructions but it does save you some work.
I've chosen Watir because it's what I started with before I ever tried Selenium. If you want to do testing in a language other than Ruby then you might give Selenium a try. Also if you think spending a few hours or days learning the syntax needed to do the tests in Ruby you might want to look at Selenium since it will at least give you the code needed to control the browser.
One of the other drivers in me experimenting with testing with that I have no QA group to test for me. I can't build something out and send it over for them to take a look at.
Example
Here's an example of a very simple Watir + Test Unit test that visits the connect homepage and verifies the Title is "All of Connect | Symantec Connect Community". This may look greek at first, let's step through it.
The top 2 lines are just requiring firewatir and test unit itself. Firewatir is the driver for Firefox and we can't use Test Unit without telling our script we intend on using it. The 3rd line just creates a test class, you can name it whatever you want, that isn't important. What is important is that it inherits ( the < symbol ) from a Test::Unit::TestCase, this makes Test Unit able to run any test in the script where the method name (the text after the "def" keyword) starts with test_.
Line #6 sets up a constant that is the URL of your application, adjust it accordingly. We set it up here so that if we need to change it we don't have to change it in multiple locations in a more robust set of tests.
Lines 8-15 define the setup and teardown methods, these are executed at the beginning and end of each test respectively. The setup method creates a variable called @browser that enables us to interact with Firefox and then tells the browser to open. The teardown method just closes the browser so we start fresh on each test.
Finally on line 17 is our only test, it helps to give the name of the test something meaningful so if it fails later in the terminal you have some idea of where it messed up. We're just checking that the browser successfully made it to the page in this test and we do that by checking the value of the browser title against what we expect it to be. If you unplug your ethernet or shut off wifi and run this test you will see a failure in the terminal that says it expected "All of Connect | Symantec Connect Community" but got "Page could not be displayed" instead.
Once you write a few tests you can just copy and paste code around, I find that I run pretty much the same tests on both my projects where I currently have it setup but just change around what you expect in place of what you copied over. I've included a version of the above example with comments in the screenshot below:
Thoughts
Worthwhile? I think if you have a simple workflow that consists of a simple one page form with an approval email probably doesn't need tested. Once a project grows to multiple forms and makes use of something like the process manager it's nice to have a suite of tests you can just run after you send out a new development version of a project.
What's Needed?
This currently seems limited to doing mostly regression testing which is a shame, I think it has potential. I think in order for Workflow Testing to be viable something needs integrated directly into workflow that you can create alongside your components that make it simple to verify error handling, proper form limitations, database entries written, etc.
I hope this has opened your eyes to the possiblity of testing your workflow projects, whether they're webforms or web services or anything in between (I've tested a monitoring project). I may include another article in the future that outlines setting up Ruby/RubyGems/Selenium more completely but I didn't want to bloat this article with that since there are some things I think you can take away from the article without going down the testing avenue.