<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Digging my own Ditch &#187; testing</title>
	<atom:link href="http://www.aroxo.com/blog/mattr/category/testing/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.aroxo.com/blog/mattr</link>
	<description>Matt from Aroxo blogs about stuff</description>
	<lastBuildDate>Sun, 20 Dec 2009 20:46:44 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>What went wrong with Google Wave</title>
		<link>http://www.aroxo.com/blog/mattr/2009/11/04/what-went-wrong-with-google-wave/</link>
		<comments>http://www.aroxo.com/blog/mattr/2009/11/04/what-went-wrong-with-google-wave/#comments</comments>
		<pubDate>Wed, 04 Nov 2009 10:20:10 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Aroxo]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://www.aroxo.co.uk/blog/mattr/?p=101</guid>
		<description><![CDATA[Like thousands of people like me a few weeks ago I got my Google Wave invite, I logged in clicked about, played with a few Waves, had some conversations and signed out.
Overall I was a combination of slightly bermused, impressed by the technology bowled over by the real-time goodness and the slick UI, but fundamentally [...]]]></description>
			<content:encoded><![CDATA[<p>Like thousands of people like me a few weeks ago I got my <a href="http://wave.google.com/wave"><span style="text-decoration: none;"><strong>Google Wave</strong></span></a> invite, I logged in clicked about, played with a few Waves, had some conversations and signed out.</p>
<p>Overall I was a combination of slightly bermused, impressed by the technology bowled over by the real-time goodness and the slick UI, but fundamentally unsure of what I was supposed to use Google Wave for.</p>
<p>But what actually went wrong here? I&#8217;ve got a theory and it&#8217;s not <a href="http://scobleizer.com/2009/10/01/google-wave-crashes-on-beach-of-overhype/"><span style="text-decoration: none;"><strong>what you might expect</strong></span></a> &#8211; valid though those criticisms are. Google Wave went wrong, not because of what it is, but because it didn&#8217;t harness any viral power:</p>
<ol>
<li>Invites are not sent fast enough</li>
<li>Wave is closed</li>
<li>Wave has no pointers</li>
</ol>
<p>Google Wave is first first and foremost a communications technology, which means for people to really see the benefits they need to be communicating with people they know.</p>
<p>When you join Google Wave you receive 8 invites, when you&#8217;re through those you get another 12. But when you send the invite they don&#8217;t arrive for several days. Meaning you&#8217;ve got practically no-one of significance to communicate with when you&#8217;re first into it*.</p>
<p><em>So your first experience of Wave is with strangers.</em></p>
<p>The second problem with Wave is that you don&#8217;t know when you&#8217;ve got an unread Wave. You signed in first time around, played around a bit with a few people you vaguely know online, and sign out. If someone now communicates with you whilst you&#8217;re signed out you&#8217;re not informed.</p>
<p><em>No email, no RSS feed, no </em><a href="http://twitter.com/aroxo"><span style="text-decoration: none;"><em><strong>Tweet</strong></em></span></a><em>, nada.</em></p>
<p>So you don&#8217;t sign in and respond and you don&#8217;t slowly fall away from being a Wave user.</p>
<p>The final thing which they got wrong is that there are no easy to follow pointers to get your started, clues for intentional uses, a quick &#8220;first action&#8221;.</p>
<p>When people first use a technology they are in a state of mild stress, in short they don&#8217;t want to publicly demonstrate that they don&#8217;t know what they&#8217;re doing and therefore look stupid. So they want something easy to do, figuring out the complex stuff afterwards. This is as true of techie geeks as it is of our non-techie friends.</p>
<p><a href="http://www.google.com"><span style="text-decoration: none;"><strong>Google</strong></span></a> Wave doesn&#8217;t supply these pointers.</p>
<p>What&#8217;s important about what I&#8217;ve said here is that all of this is entirely fixable, and there are plenty more people who desperately want to try out Google Wave. With any luck the feedback from the 2nd and 3rd round of adopters will be a lot more positive!</p>
<p>* I totally acknowledge that there maybe good technical scalability reasons for this, but it doesn&#8217;t change the affect.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.aroxo.com/blog/mattr/2009/11/04/what-went-wrong-with-google-wave/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>How to test your system with real users</title>
		<link>http://www.aroxo.com/blog/mattr/2008/02/14/how-to-test-your-system-with-real-users/</link>
		<comments>http://www.aroxo.com/blog/mattr/2008/02/14/how-to-test-your-system-with-real-users/#comments</comments>
		<pubDate>Thu, 14 Feb 2008 11:25:59 +0000</pubDate>
		<dc:creator>Matt Rogers</dc:creator>
				<category><![CDATA[Aroxo]]></category>
		<category><![CDATA[development]]></category>
		<category><![CDATA[entrepreneur]]></category>
		<category><![CDATA[entrepreneurship]]></category>
		<category><![CDATA[how to start]]></category>
		<category><![CDATA[start-up]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[web 2.0]]></category>

		<guid isPermaLink="false">http://www.aroxo.com/blog/mattr/index.php/2008/02/14/how-to-test-your-system-with-real-users/</guid>
		<description><![CDATA[Aroxo recently turned a major corner in its development, we moved from closed functional testing to using real live alpha testers, people who&#8217;d never seen Aroxo before.
Without doubt, this is one of the most revealing, painful, and valuable stages in creating your start-up, so I thought I&#8217;d blog about it.
When launching anything you want ensure [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.aroxo.com">Aroxo</a> recently turned a major corner in its development, we moved from closed functional testing to using real live alpha testers, people who&#8217;d never seen Aroxo before.</p>
<p><em>Without doubt, this is one of the most revealing, painful, and valuable stages in creating your start-up, so I thought I&#8217;d blog about it.</em></p>
<p>When launching anything you want ensure that not only does it work, but people find it easy and natural to use. Your own functional testing should cover the first objective, your alpha testing should cover the UI.</p>
<p>At Aroxo we&#8217;ve employed four different techniques to get the system ready for launch:</p>
<table border="1" cellPadding="0" cellSpacing="0">
<tr>
<td vAlign="top">
<p align="center"><strong>Test type</strong></p>
</td>
<td vAlign="top">
<p align="center"><strong>Description</strong></p>
</td>
<td vAlign="top">
<p align="center"><strong>How many people</strong></p>
</td>
</tr>
<tr>
<td vAlign="top">Over-the-shoulder</td>
<td vAlign="top">The main sticking points in the system. Where the system confuses users.<br />
<strong>Start</strong> when functional testing at 80% readiness. Earlier with mock-ups also possible.</td>
<td vAlign="top">10-15</td>
</tr>
<tr>
<td vAlign="top">Task-driven testing</td>
<td vAlign="top">How well the system stands up on its own.<br />
<strong>Start</strong> when the major usability holes uncovered in OTS  testing have been fixed.</td>
<td vAlign="top">Start with 20-30 keep growing invites to 100 or so</td>
</tr>
<tr>
<td vAlign="top">Goal-driven testing</td>
<td vAlign="top">End-to-end flaws across the system.<br />
<strong>Start</strong> when functional testing at 95% system readiness with a slick UI.</td>
<td vAlign="top">150-200</td>
</tr>
<tr>
<td vAlign="top">Beta testing</td>
<td vAlign="top">The marketing points for the site, highlights future developments. If there are enough users it may also reveal performance issues<br />
<strong>Start</strong> when the system is 99% ready.</td>
<td vAlign="top">250+ including members of the public</td>
</tr>
</table>
<p>Not only is each stage different but you get different learnings from it. I discuss each stage below.</p>
<p><span id="more-37"></span></p>
<p><strong>Over-the-shoulder tests</strong></p>
<p>This test phase is the most fascinating for the founders, as you get to watch people actually interacting with your system. This test should be done independently, as those close to the system are inclined to guide the user towards positive responses, rather than getting genuine feedback.</p>
<p>But if you are bootstrapping or operating on a tight budget, you may well be doing it. So, here&#8217;s what you do:</p>
<ol type="1">
<li>Write out a list of scenarios or tasks which you are going to as people to do</li>
<li>Find 5-15 people who represent your expected customer base</li>
<li>Sit them in front of a machine and get going</li>
</ol>
<p>Your first task should be to get them to look at the homepage for a few seconds (no more than 30 seconds), then ask them what they think the site does. People should find it easy to understand the site from the homepage. If not, probe a little to find out what you can change to make it clearer. Then get started on the scenarios.</p>
<p>Your job is to generally keep quiet and take notes as they use the system. You are particularly looking for times when something confuses them, you may notice the person lean forward and start to look confused. At these points feel free to interrupt and probe, ask them what they are looking for and what&#8217;s missing.</p>
<p>When probing, be very careful to use words like &#8220;what&#8221; (open) rather than &#8220;why&#8221; (implies fault). Try not to reveal any emotion, you&#8217;re not asking people to tell you how great your system is, you&#8217;re after <strong>honest feedback</strong>. Therefore it is also important not to make people think they are stupid for not being able to use the system, frame it as &#8220;we want to get some open and honest feedback&#8221;.</p>
<p>Expect some excellent and easy improvements to come out of this to really make the system substantially easier to use.</p>
<p><strong>Task-driven testing</strong></p>
<p>Task-driven is quite different. For a start, you won&#8217;t actually be watching people, they&#8217;ll be running through tasks on their own. This is particularly interesting because for the first time people will be using the system without anyone to ask for help. This means you can get more people involved.</p>
<p>To perform this sort of testing there are a few things you need:</p>
<ol type="1">
<li>around 20 particpants to start with (expect about half to actually use it and 2-3 who give you really good feedback)</li>
<li>a well defined list of tasks for them to perform</li>
<li>a way to communicate the tasks to them and</li>
<li>a way for them to communicate their findings back to you.</li>
</ol>
<p>As you push these changes through to the alpha platform you should start adding more and more people onto the trial. You want fresh eyes to test your UI improvements, people who&#8217;ve already seen it, won&#8217;t test it as well, if at all.</p>
<p>Your objective here is the test how well the system performs with a small number of people performing defined tasks, so each task you ask people to do should come with some prompts to help them give you relevant feedback.</p>
<p><strong>Goal-driven testing</strong></p>
<p>Goal-driven testing differs from task-driven testing in two ways. Firstly there are a lot more people involved in the trial, and secondly instead of having tasks which people have to perform on the system (e.g Register on the site). You set wide goals for the participants. In context of Aroxo this is something like &#8220;buy something&#8221; or &#8220;sell something&#8221; the UI and the website itself should then guide the users through the system, rather than the tasks.</p>
<p>Start your goal-driven testing when you&#8217;ve reached the point that you believe the UI of the system is strong enough that people know what they should be doing and how to use the system.</p>
<p><strong>Beta testing</strong></p>
<p>Beta testing isn&#8217;t really testing in the same way as the alpha testing which you&#8217;ve already performed is. You want a large number of people get see the system and many of them will have registered on your site to do it, so you don&#8217;t know them.</p>
<p>This makes beta testing public. If it is public, it&#8217;s part of your marketing. Therefore it is essential that it shows your site running well and easy to use. What you may get is some useful learnings about how the system scales, or you may also be able to learn something from some clickstream work.</p>
<p>However, what is most important about beta testing is that it should not be part of your functional and UI testing, it is too late to make any significant changes to the system as you&#8217;ll be moving towards a full launch within weeks of starting your beta.</p>
<p><strong>Closing thoughts</strong></p>
<p>One thing which I&#8217;ve not discussed in this article is the emotional impact which testing has on the founders. If you&#8217;ve been careful with your IP whilst you&#8217;ve been building your system it&#8217;ll be the first time which you&#8217;ve had large numbers of people looking at your system. This means you are going to get a lot of feedback.</p>
<p><em>It is important not to take this feedback personally. It should help make the system stronger.</em></p>
<p>You need to remember that you are asking people to look at your system and tell you the flaws and problems with it. You are not asking them to look at it and tell you how clever it is! This means you are going to get a lot of (hopefully) constructive criticism. You need to take this on the nose and think of creative ways to improve the system.</p>
<p>Finally, in the case of Aroxo something which we learned is that it just isn&#8217;t possible to test the UI of your own stuff: you are way too close to it. So it is important to have lots of fresh eyes to test each new release.</p>
<p>Good luck!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.aroxo.com/blog/mattr/2008/02/14/how-to-test-your-system-with-real-users/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
