Wikis are never going to be the next killer application, they can however be a powerful tool; especially for QA teams where lots of random bits of information need to be stored and shared. James Bach commented the other day on wikis saying they Wikis make his skin crawl. This post therefore serves two purposes. The first is to discuss the pros and cons of wikis from my perspective, and the second is to bait James into explaining why they induce the reaction they do.

Pros

  • Browser Based – By definition wikis are browser based. This suddenly removes a dependency on being able to read a document in a proprietary format. Test Plan written as a Work 2k3 document? You’re out of luck if you want to read it on HPUX. Okay, I suppose you could install OpenOffice or something similar but the conversions never are 100%. You also don’t have to worry about training on something like subversion if you stored your documents in version control.
  • Always up to date – When you have things stored as .doc or .xls files, you easily fall into version hell. Or locked-by hell come to think of it. By definition the version that is displayed on the wiki is the current version. The more mature wiki platforms even deal with the ‘someone has already saved a newer version than what you were using’ problem prompting you to deal with the diff. Points has had some pretty nasty document version storms in the past. If they adopt something like I propose here it would solve some of their issues.
  • Quick – Creating or updating an entry in a wiki is super fast. This can go a long way to eliminating the documentation debt that a lot of teams have towards the end of a release.
  • Instantly shared – Once something in on the wiki, it is instantly available to all team members. No need to resync with the version control system or whatnot.
  • Embed HTML – Since a wiki is just HTML anyways, you can embed simulator pages right in/from documents and not have to change applications. For example, a Test Plan might have as part of the Strategy for a Feature to access a page via an SSO simulator. The simulator would be linked from the page or even be built right into the current page. We used that with great success at Points for iFrame testing.
  • Restructurable – The QA/Test part of the wiki has gone through a couple iterations as far as layout and structure. None of them were disruptive though because all you do is just move a link around. If things were in CVS there would have to be branching and history issues to be tacked.
  • Auditing – wikis record who editing what page and when. This can be important or not depending on your company’s culture and climate.

Cons

  • Special Syntax – Creating pages on a wiki is not a trivial action. There is a whole new mini-language to learn. With a wiki, the more people that are creating and editing pages the better, but do we really expect an old-school analyst, sales droid or worse to learn the syntax? It’s not going to happen. Wikis therefore get relegated to the geeks. This isn’t necessarily a bad thing in the QA context as learning some little formatting rules should be easy for someone who has to learn an entire enterprise application. For marketing, sales, etc. the more appropriate collaboration tool is something like Sharepoint, but unfortunately it comes with a pretty steep pricetag.
  • Partner Availability – Ideally, you would want your partners to have access to the (parts) of the wiki. That means you have to make it available externally which means that it is yet another machine to harden. If it is not available externally you will inevitably end up emailing the partner a copy-paste from a page for their opinion and have negated one of the Pros of having it on the wiki.
  • Global Page Title Uniqueness – Since pages are referenced by their title, the title of pages needs to be globally unique within the wiki. This can be annoying if you really wanted to call a page something but someone already has. However, with a bit of planning however this can be worked around.

Right now I am starting to think of how I want to organize a QA section at Jonah. So far, its something like this:

QA
|-- Partner - <Partner 1 Name>
|   |-- Project - <Project 1 Name>
|   |   |-- <Project 1 Name> - Test Plan
|   |   |-- <Project 1 Name> - <Feature 1 Name> Test Cases
|   |   `-- <Project 1 Name> - <Feature N Name> Test Cases
|   `-- Project - <Project N Name>
`-- Partner - <Partner N Name>

The ‘Partner’ and ‘Project’ prefixes are to enforce/get around the global unique naming.