<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Illiteration - Jared's Testing Times - Software Testing Blog</title>
    <link>http://quinert.com/blog/</link>
    <description>Thoughts about software testing and software development</description>
    <language>en-us</language>           
    <generator>Nucleus CMS v3.24</generator>
    <copyright>Jared Quinert</copyright>             
    <category>Weblog</category>
    <docs>http://backend.userland.com/rss</docs>
    <image>
      <url>http://quinert.com/blog//nucleus/nucleus2.gif</url>
      <title>Illiteration - Jared's Testing Times - Software Testing Blog</title>
      <link>http://quinert.com/blog/</link>
    </image>
    <item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=78</guid>
 <title>It&apos;s a good thing I saved this in my Amazon wishlist...</title>
 <link>http://quinert.com/blog/index.php?itemid=78</link>
<description><![CDATA[Otherwise, I might not be able to remember to buy it later.<br />
<br />
<img src="http://www.quinert.com/images/wishlistbug.png">]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=78</comments>
 <pubDate>Thu, 21 Aug 2008 06:11:04 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=77</guid>
 <title>Test for Project Risk</title>
 <link>http://quinert.com/blog/index.php?itemid=77</link>
<description><![CDATA[An excellent quote from our development lead, <a href="http://www.jamesladdcode.com/">James Ladd</a>:<br />
<br />
How to test a project might be risky -<br />
<br />
- <i>It has people in it.</i><br />
<br />
Thanks to <a href="http://www.satisfice.com/blog/archives/26">James Bach</a> for inspring this!]]></description>
 <category>Software development</category>
<comments>http://quinert.com/blog/index.php?itemid=77</comments>
 <pubDate>Tue, 19 Aug 2008 08:52:10 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=76</guid>
 <title>A first step toward saying what we mean when we say &apos;Automated testing&apos;</title>
 <link>http://quinert.com/blog/index.php?itemid=76</link>
<description><![CDATA[<blockquote>"In the universe, nothing can be said to be automatic, as nothing can be said to be without design.  An imperfect parallel may be found in human inventions; springs may move springs, and wheels, indexes; but the motion and the regulation must be derived from the artist;"</blockquote><br />
<br />
<br />
From <a href="http://books.google.com/books?id=0JcAAAAAMAAJ&amp;dq=humphry+davy&amp;as_brr=1&amp;vq=automatic&amp;pg=PA100&amp;ci=166,1034,835,306&amp;source=bookclip">Elements of Chemical Philosophy Part 1, Vol.1 By Humphry Davy</a><br />
<br />
Of course, the second step will be taking my automation or testing tools course (plug, plug).]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=76</comments>
 <pubDate>Sun, 27 Jul 2008 13:00:30 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=75</guid>
 <title>&apos;Tools for testers&apos; course next month at STANZ</title>
 <link>http://quinert.com/blog/index.php?itemid=75</link>
<description><![CDATA[Paul Szymkowiak and I will be running a one-day workshop on tools for testers, as part of the STANZ conference.  The current run on August 13th is full, but you can register your interest for future courses via <a href="http://www.softed.com/">SoftEd</a>, or drop me a line.<br />
<br />
Details of the course are at <a href="http://www.softed.com/stanz/speakersandsessions.htm#tst">http://www.softed.com/stanz/speakersandsessions.htm#tst</a><br />
<br />
I'll have the presentation slides here on the website shortly!]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=75</comments>
 <pubDate>Sun, 27 Jul 2008 07:55:57 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=74</guid>
 <title>Answering a question...</title>
 <link>http://quinert.com/blog/index.php?itemid=74</link>
<description><![CDATA[A few weeks ago, Designer commented on <a href="http://quinert.com/blog/index.php?itemid=71">Software testing, art and productivity</a>.  The question got lost in amongst the comment spam, so I thought I'd give my answer a bit more prominently than usual.  The question was:<br />
<blockquote>...Many people who want to get a web-developed project don't even understand the details of work. They just want to have a result and not to make a lot of efforts.  How do you think - is there any solution?  I think it is wide-spread problem.</blockquote><br />
<br />
<br />
If you're talking about smaller web-based projects, I think you're right.  It can be really difficult to engage clients in the necessary up-front work to help reduce project uncertainty to a reasonable level.  It's a problem given that those with less money to spend have much more business risk in any project they undertake.<br />
<br />
I think the second aspect of this is that customers (both internal and external) often come to us with a solution, not a problem.  As we build the solution they asked for, the problem becomes clearer and dissatisfaction starts to creep in.<br />
<br />
The focus of my work is increasingly on trying to help people build the right thing in the first place.  I'm lucky.  In my current role, my employer has the conviction that it's important to make sure the project is heading in the right direction.  This means making sure the project team has a shared understanding of the product vision, stakholders, those stakeholders' goals, priorities and (in the case of a consumer product) the market and opportunities.  They also think that it's OK to bring development to a pause while we get our project bearings.<br />
<br />
If you can't choose the projects you undertake, then I don't see any easy answers to these problems.  And if you can't convince your customer to be involved appropriately, and to place *some* value on just talking about the problem, it's a hard road ahead for everyone.  I guess the desire to do things 'right' is what drives many of us to start our own companies and projects.  Without this option though, we can still focus on providing service - helping our customers better understand their problems and pointing out the benefits, costs and risks present in their solution(s).  But choose your moments well, and don't stop dreaming that things can be better than they are.]]></description>
 <category>Software development</category>
<comments>http://quinert.com/blog/index.php?itemid=74</comments>
 <pubDate>Wed, 16 Jul 2008 04:07:04 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=73</guid>
 <title>INVESTing in User Stories, revisited</title>
 <link>http://quinert.com/blog/index.php?itemid=73</link>
<description><![CDATA[<a href="http://www.mountaingoatsoftware.com/story_training">Mike Cohn's</a> "User Stories Applied" discusses using the INVEST mnemonic as a guide to writing better user stories.  I was recently asked to dig up a reference for it, and found this presentation <a href="http://files.meetup.com/169191/2007-10-01%20Mike%20Cohn%20-%20User%20Stories%20Applied.pdf">here</a>, with the section on the mnemonic on pages 47 and 48.<br />
<br />
As I read it, I noticed that there's been a change to one of the letters.  Whereas the book uses 'S' to denote 'Small', now it's become 'Sized appropriately'.<br />
<br />
I think this is a change for the better, as I noticed that every time I talked someone through the acronym, I would have a long-winded conversation qualifying 'Small' as 'Just small enough but no smaller'.  This would come about as I tried to explain the tradeoffs between a story being small enough to estimate with some reasonable certainty, small enough to fit within an iteration, and still ensuring that stories are 'V- Valuable to the customer', needing to ensure that user stories continue to express clearly a problem or need of a person.  <br />
<br />
Overly small stories push us further from the original context of the problem, and thus force us to compensate with an increasing heirarchy of 'super-stories' to help us focus on the bigger picture.  These become more noticable when working in shorter iterations than might be common on a Scrum project, so three cheers for Mike in spending the effort to come up with 'Sized appropriately'.]]></description>
 <category>Software development</category>
<comments>http://quinert.com/blog/index.php?itemid=73</comments>
 <pubDate>Tue, 15 Jul 2008 05:36:44 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=72</guid>
 <title>Request for Beta Testers...</title>
 <link>http://quinert.com/blog/index.php?itemid=72</link>
<description><![CDATA[This was passed on to me via Paul Szymkowiak.  Feel free to email me if you are interested in participating in this test for <a href="http://www.securityinnovation.com">Security Innovation</a> and I will pass on Pete's contact details.<br />
<br />
-------------------------<br />
<br />
Recruiting Beta Testers for Security Guidance System Usability Testing<br />
<br />
We're looking for 50 beta testers for our new application security development guidance system. The testing is focused on usability and asks that testers run through a series of scenarios to qualify the navigation and search mechanisms, and provide feedback on the experience. The duration of the test is two weeks starting 1-Jul-2008.<br />
<br />
Requirements for beta testers are that you are a) a software professional, b) comfortable reading & speaking English, c) interested in software application security and d) have a few hours to hammer our product on-line.<br />
<br />
As thanks, each tester will receive a free 1 year subscription to all of the content we publish, and a formal invitation to participate on our customer advisory board.<br />
<br />
Interested? Know anyone who might be interested? Please contact me.]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=72</comments>
 <pubDate>Tue, 24 Jun 2008 17:52:01 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=71</guid>
 <title>Software testing, art and productivity</title>
 <link>http://quinert.com/blog/index.php?itemid=71</link>
<description><![CDATA[In the Yahoo software-testing list, <a href="http://shrinik.blogspot.com/">Shrini Kulkarni</a> stated <blockquote>"...productvity as a term is "bad" for creative work like "testing" or "art". That makes me to feel that I am a low skilled labour on a manufacturing assembly line (not that - it is a bad profession but that does not represent the kind of job I do or I would to do or I am capable of doing)"</blockquote><br />
<br />
It triggered some thoughts from recent projects, and my reply follows.<br />
<br />
<blockquote><br />
What bad things happen when we apply the word 'productivity' to testing?<br />
<br />
Like it or not, unless we are on a fixed price contract with no deadline (and when is there *not* a deadline?), the person who pays is going to be evaluating the value that we provide relative to the money they spend.  This seems to be a productivity measurement, and things don't usually go well when we ignore it.  <br />
<br />
We are often forced to balance the artistic/creative part of our work with giving our employer the impression that we are being 'productive'.  My understanding of history is that most artists through history have also had to concern themselves with both productivity and art, especially if they want to make a living.  <br />
<br />
To me, productivity is the key to defensible testing.  It's the idea that I should be striving to get the best coverage that I can for the least cost.<br />
<br />
I think where we go wrong is when we define productivity as output or effort, not 'value'.  Unfortunately, the former definitions are common, and I think this is a huge problem in many places that I work.  That is, there is a focus on appearing busy and creating artifacts, and not on gathering the information that would most help the project right now.<br />
</blockquote><br />
<br />
There <i>are</i> negatives to the project in terms of our personal productivity if we are forced to ignore those parts of our work which give us the greatest satisfaction.  For me, this does include the aspects of testing that I consider creative and artistic, but it also includes other things, such as the satisfaction I get from face-to-face communication, developing relationships, working ethically, collaborating and helping the development of others.  <br />
<br />
It's not all about art, but we all have days when our inner artist is challenged.  Some days slamming the lid down on the piano and storming off the stage is what's called for.  But mostly, we respect the audience...and the show must go on.]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=71</comments>
 <pubDate>Wed, 11 Jun 2008 05:39:21 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=70</guid>
 <title>Another Australian context-driven blog</title>
 <link>http://quinert.com/blog/index.php?itemid=70</link>
<description><![CDATA[Alister Scott, an Australian tester located in Brisbane has started a blog.  There are a few Watir samples, and it's always nice when a test automator puts their code up for scrutiny.  I know my plans to do the same have taken far too long.<br />
<br />
Check his writing out at <a href="http://watirmelon.wordpress.com/">http://watirmelon.wordpress.com/</a>]]></description>
 <category>Testing</category>
<comments>http://quinert.com/blog/index.php?itemid=70</comments>
 <pubDate>Wed, 14 May 2008 17:11:21 +0600</pubDate>
</item><item>
 <guid>http://quinert.com/blog/xml-rss2.php?itemid=68</guid>
 <title>Not looking my usual self</title>
 <link>http://quinert.com/blog/index.php?itemid=68</link>
<description><![CDATA[Due to a persistent hacking attempt over the last few days, I've done an emergency upgrade.  Things will probably look ugly until the weekend, so apologies to anyone visiting!]]></description>
 <category>News</category>
<comments>http://quinert.com/blog/index.php?itemid=68</comments>
 <pubDate>Thu, 14 Feb 2008 15:40:58 +0500</pubDate>
</item>
  </channel>
</rss>