<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rss [<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">]>
<rss version="0.92" xml:base="http://www.testingreflections.com">
<channel>
 <title>testingReflections.com - testability</title>
 <link>http://www.testingreflections.com/taxonomy/view/or/87</link>
 <description></description>
 <language>en</language>
<item>
 <title>The conundrum of testability modifications</title>
 <link>http://www.testingreflections.com/node/view/4964</link>
 <description>In my current role I'm lucky enough to get a lot of support from development.  They really care about the performance of the application and want to help me test it.  So when I run into certain kinds of application related stumbling blocks -- a generated hash key that expires in 3 days as a security measure, after which that part of the app won't work with the old key by design, or a page with really  &lt;i&gt;a lot&lt;/i&gt; of IDs generated each time, that the server won't accept any that don't match upon submit, another security measure -- just to give two examples, developers often offer to take them out for me so I can test.  "We can take that out so you can test, and we'll just put it back in before we ship."  Woah.  Red flag here.  Wait.  Stop.</description>
<pubDate>Sun, 04 Feb 2007 15:51:02 -0600</pubDate></item>
<item>
 <title>First Look</title>
 <link>http://www.testingreflections.com/node/view/4343</link>
 <description>I recently started a new job. This new start has brought back a good memory and I've tried to reuse what I learned from that experience. &lt;br /&gt;
&lt;br /&gt;
On a new job, my boss wanted to capture my first reactions to the five different software products the company made. He didn't "allow" anyone to talk to me about the products for the first couple of days. He wanted me left alone and to make my way through one pass of each app with no direction, comments or information beyond the help files. He gave me his office and he sat in my cube. He wanted me to record my thoughts. We both knew I would never have that first look time again.</description>
<pubDate>Mon, 16 Oct 2006 00:45:16 -0500</pubDate></item>
<item>
 <title>Interesting.</title>
 <link>http://www.testingreflections.com/node/view/3612</link>
 <description>[textile]&lt;br /&gt;
&lt;br /&gt;
An interesting "press release":http://weblog.infoworld.com/techwatch/archives/005983.html found whilst in the "WOPR":http://www.performance-workshop.org/ lab on performance testing with "AJAX":http://en.wikipedia.org/wiki/AJAX&lt;br /&gt;
&lt;br /&gt;
Well it is kind of refreshing for this level of kind of honesty. &lt;br /&gt;
&lt;br /&gt;
So if the test tool does not work with the technology then let the test tool vendor dictate the technology you use.</description>
<pubDate>Wed, 19 Apr 2006 16:28:31 -0500</pubDate></item>
<item>
 <title>Testing web services locally - faster</title>
 <link>http://www.testingreflections.com/node/view/388</link>
 <description>I&amp;nbsp;really hate having to test my web services while still going through the whole TCP IP stack when testing them on the local machine. Luckily, &lt;A href="http://weblogs.asp.net/britchie/archive/2004/08/02/206427.aspx"&gt;Brian Ritchi has a nice and elegant solution&lt;/A&gt;. He created a proxy class that invokes the local object under the web service instead of the web service itself. That's pretty cool.</description>
<pubDate>Sun, 08 Aug 2004 07:33:56 -0500</pubDate></item>
<item>
 <title>Quantitative versus Qualitative software testing criteria? Aren't they complementary...</title>
 <link>http://www.testingreflections.com/node/view/309</link>
 <description>[textile]It seemed that my perspective on 'quantified' in &lt;a href="http://www.testingreflections.com/node/view/297"&gt;my SMART thinking post&lt;/a&gt; was interpreted as meaning that I was only interested in quantitative methods... when in-fact I see qualitative and quantitative as complementary methods of test-analysis.&lt;br /&gt;
&lt;br /&gt;
This became clear to me thanks to a discussion on the &lt;a href="http://groups.yahoo.com/group/agile-testing/"&gt;agile-testing mailing list&lt;/a&gt; involving Brian Marick and Michael Bolton... also following discussions with colleagues... So, I have revised my written definition of &lt;i&gt;measurable&lt;/i&gt; to clarify my point of view:</description>
<pubDate>Sun, 22 Aug 2004 03:48:48 -0500</pubDate></item>
<item>
 <title>SMART thinking.... agile testability analysis</title>
 <link>http://www.testingreflections.com/node/view/297</link>
 <description>[textile]When you have a basis for a test, such as a requirement, a story or a step in a use-case... how do you know it is 'testable'. You could adopt an approach that involves 20, 30 or more check-points, you could do it based on fuzzy feelings - or you can adopt a simple checklist that covers most of your needs with minimal effort and a degree of consistency.&lt;br /&gt;
&lt;br /&gt;
If your input isn't measurable, then you need to make your test measurable at the least... perhaps the test will become the written definition (test-first)... but you will still need a measurable input, even if it is the spoken-word of your customer.&lt;br /&gt;
&lt;br /&gt;
So, here is a simple, 5 point check-list to make sure that the input is testable...</description>
<pubDate>Mon, 26 Jul 2004 03:39:45 -0500</pubDate></item>
</channel>
</rss>
