<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on 10  priorities for testing critical systems ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-267530/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-25T16:56:23-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[Thorough testing]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2565958]]></link>
        <description><![CDATA[Be very careful what you mean by this.Say it to a mangement type, and any surprise, no matter how trivial will introduce doubt.It's hard, sometimes impossible (well impractical) to predict all the impacts of a change. What you should try to do is verify critical functionality.An example might be two segments of network can still see each other, but one device which was bodged in had a weird and wonderful route which no longer works.Be clear about what you are and have tested for.Otherwise you'll get rolledback in an unnecessary panic and have to do it all again.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2565958]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Mon, 11 Aug 2008 04:34:29 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10  priorities for testing critical systems]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2565907]]></link>
        <description><![CDATA[I appreciate that to write an article about priorities for testing its hard to get everything in there, but I do feel that a very key area has been missed around the management of testing: visualisation.You need to be able to visualise the coverage of testing, and the clustering of defects, in order to track and predict problems.  very important for regression testing and for making key decisions during the testing cycle.The visualisation can be linked to requirements or to  the code itself, so that you can see what has and hasnt been tested.Very often teams engage in testing without really being able to define the target of completion or see the results of their work in terms of completion of target goals.  Setting these goals (such as 80% code coverage or 100% of mandatory requirements) is fundamental to a mature, efficient and effective testing effort.Stewart]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2565907]]></guid>
        <dc:creator><![CDATA[stewart.noakes@...]]></dc:creator>
        <pubDate>Mon, 11 Aug 2008 03:12:26 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Thank you robo_dev]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2537191]]></link>
        <description><![CDATA[You speaketh the truth!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2537191]]></guid>
        <dc:creator><![CDATA[b4real@...]]></dc:creator>
        <pubDate>Tue, 01 Jul 2008 20:02:44 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10  priorities for testing critical systems]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2534787]]></link>
        <description><![CDATA[This article comes just in time for me.  I am working on a large project with new QA tester that the QA Manager is pressed for time to train them adequately.  So, I am having to dig into more detail about what a great test plan should include.  Thanks!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2534787]]></guid>
        <dc:creator><![CDATA[ls2141@...]]></dc:creator>
        <pubDate>Sat, 28 Jun 2008 23:07:56 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10  priorities for testing critical systems]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2533562]]></link>
        <description><![CDATA[I think #5 sums it all. Usually during the testing phase people do everything else on the test machine. But when they go online, quite often you have problems maybe because of hardware/software difference on the production machine.#9 is always a nightmare, sometimes you see a bug and you cannot reproduce it anymore, not to mention that some testers pretend to not see bugs.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2533562]]></guid>
        <dc:creator><![CDATA[PM Hut]]></dc:creator>
        <pubDate>Fri, 27 Jun 2008 04:58:46 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Try VMs]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2533015]]></link>
        <description><![CDATA[I've a client that can't afford a physical dev server to test everything against before it goes too the production server. I use a VM duplicate of the production as my dev too test as much as I can though his eagerness has lead to production changes before I had a chance to confirm it first.The time isn't a cost, it's a necissary step before the next step. VMs help financial limitations and planning your changes ahead of time should account for testing of those time critical objectives.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2533015]]></guid>
        <dc:creator><![CDATA[Neon Samurai]]></dc:creator>
        <pubDate>Thu, 26 Jun 2008 11:13:48 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Mistakes: testing on production network, not doing network analysis]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2532871]]></link>
        <description><![CDATA[Thou shalt not test on a production networkI've seen 'simple painless testing' bring down a global SAP instance.You cannot test on a production network, period.Network Impairment Simulation:On the test network you need to create conditions similar to the real-world network  conditions. Simulating production network conditions can be tricky and costly, but devices like network impairment delay simulators and latency simulators are effective tools to create a real-world environment in the lab.Network Impact Analysis:(Or how to keep your telecom people from screaming at you).Performing a network impact analysis using a protocol analyzer can identify potential performance bottlenecks and also reveal security issues.A network impact analysis can identify both 'what your app does to the network' and 'what the network does to your app' (with apologies to John F Kennedy).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2532871]]></guid>
        <dc:creator><![CDATA[robo_dev]]></dc:creator>
        <pubDate>Thu, 26 Jun 2008 09:08:48 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[No concept of time?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2532837]]></link>
        <description><![CDATA[Always a good idea to put time-critical objectives in testing!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-267530-2532837]]></guid>
        <dc:creator><![CDATA[b4real@...]]></dc:creator>
        <pubDate>Thu, 26 Jun 2008 08:53:18 -0700</pubDate>
    </item>
    </channel>
</rss>

