Last Tuesday I went to XPWestMichigan, where we talked about craft in software development
. One of points raised was that developers don't spend enough time reading code, or working in pairs with someone else to gain experience.
I would argue that the same problem occurs in testing - how many times have you seen a given piece of software, along with a discussion of the strategy used to test it?
"Not often enough" is the first thing that comes to my mind.
So how about a testing challenge?
No, not the Triangle problem
. A real test challenge that you might experience on a real web 2.0 application, like, say, Socialtext
Now I'm going to describe a relatively complex problem, which you could answer in several ways. The simplest way would be overall strategy, that you might do in two paragraphs, on down to a detailed test plan - which you might want to do as your own blog post. (or not; long comments here are okay too.)
Take a web 2.0 application, something like twitter or myspace or facebook. The basic application is a wiki; a series of editable web pages. These wikis are organized in Workspaces. Workspaces are distinct and independent; I have can have a 'hello' page in one workspace, and a 'hello' page in another, and the two could never meet. If two users overlap by a workspace, they can see each other's activity.
Likewise, Workspaces can belong a Network, which generally line up with companies. (A big company, say GE, might have a GE account and then workspaces for each line of business, a general HR workspace, an executive workspace, and so on.) Belonging to a workspace in another Network implies you are a member of that Network.
Users can edit pages, comment on pages, tag a page, search by text, name or tag. They also have a profile, which they can save or tag, and can search the profiles. The software also has a digital dashboard that allows the user to see summaries, metrics, and other data at a glance. One of those widgets is the activities widget, which summarizes what the users (that you can see
) have done in the software:
[caption id="attachment_546" align="alignnone" width="583" caption="Activities Widget"]
The widget has drop-downs to filter what activities you want to see; in the picture, I've displayed all of them at the same time. Now let me explain a little more about these activities:
A user can also send a signal, which is a 140-character or smaller message. You send signals by filling out the empty space at the top of the widget. The signal can be replied to or have a name mentioned - reply is the enter-like signal at right. If you
are mentioned in the signal, the message appears highlighted. Messages can also be private (the envelope like symbol at right); private messages will only be seen by you and the recipient, and will appear with a great background.
Contributions can be page edits or comments. Each person also has a profile. Profiles can edited (by the user themself, only) or tagged (by anyone). Or tags can be deleted; all three of those create a 'people event.'
You can also choose to follow people, though who you follow or stop following is not listed as a people event.
If someone edits a page that you have previously edited, that creates a 'conversation' event. Likewise, you can watch a page (which is not displayed as an event) and if someone edits or comments on that page, it is also a conversation.
I think that's enough about the activities widget for now.
The Five minute challenge
* Describe your 'test strategy' at a high level. What kind of activities would you do? How long would those take you? What would your goals be? How long do you think it would take you?
The professional challenge
* What would be the kinds of things you would test for (your 'test cases'). I don't need every single test case; some of them can be generated with simple multiplication. Some can not. (You can always do a blog post and link back in a comment.)
And, of course -
* What else do you need to know to answer those questions? (I will answer these, in italics, in the comments)
Keep in mind, this is an agile shop that delivers working software every two weeks. The developers coded four pieces of functionality like this in this two weeks, and they will deliver four more in two more weeks. Your test team is three people, one of whom is a manager.
I'll post the winning entry later, along with my comments.
In the mean time, Batter up ...