Recently in Testing Category
What I did.
1 - Installed Office 2010 x86 as a side-by-side install with 2007 (on Windows 7 x86).
2 - Ignored the "reboot now" prompt as I needed to open and print a word document
3 - Opened the document in Word 2007
4 - Waited whilst Office 2007 setup did *something*
5 - Printed document and closed word.
6 - Rebooted
7 - Loaded Outlook 2010
This is where my problems began. I received an error message about "Default Programs" over the top of the splash screen, the "backstage" screen was perpetually telling me that my files were being upgraded and that I needed to update the "Connector". Also, when clicking "Send/Receive" I received a "Not Implemented" modal dialog. It's also worth mentioning that Outlook was absent from the Default Programs control panel applet.
How I solved it.
1 - Uninstalled Office 2010
2 - Rebooted
3 - Re-installed Office 2010
4 - Rebooted
5 - Loaded Outlook 2010
Et Voila, problem solved.
How very, very, very useful! Certainly looks better than the one I've been using. Time will tell!
TestDriven.Net 2.19: Release Notes
Nothing more to say really, there's a new version to upgrade to. Time to upgrade.
And finally, someone complaining (albeit mildly and constructively!) that the IE8 installer progress bar doesn't render in a useful fashion when youn use a non-Microsoft provided theme on Windows XP. Given that using a non-MS theme involves patching DLLs and generally putting your O/S into an unsupported state, a non-useful render of a progress bar is pretty good going. Given that "fixing" this would involve Microsoft putting in a code path in their installer, along with UI components, to cater for their O/S being in an unsupported configuration - I don't see it happening any time soon..
Create an attribute called CoverageExcludeAttribute:
A good place to put it is in a shared assembly, or in your AssemblyInfo.cs if your class/project is somewhat monolithic. Now, every class or method that you decorate with this attribute will be ignored by NCover (when run via TestDriven.net). You can also make any nant build tasks you have running in CruiseControl do the same:
using System;
[AttributeUsage(AttributeTargets.All)]
public class CoverageExcludeAttribute: Attribute {}
<ncover program="NCover.Console.exe" commandLineExe="nunit-console.exe" commandLineArgs="My.Test.dll /xml=Coverage.xml /labels /nologo" coverageFile="Coverage.xml" logLevel="Verbose"
logFile="My.log"
excludeAttributes="CoverageExcludeAttribute;System.CodeDom.Compiler.GeneratedCodeAttribute" registerProfiler="false">
</ncover>
Note the second attribute that's in there - "System.CodeDom.Compiler.GeneratedCodeAttribute", that's the one that automatically excludes any code that Visual Studio / other MS tools automatically generates, leaving the "CoverageExcludeAttribute" for when you need to (judiciously!!) apply it.
The isFiltered() method of the Ext.data.Store class returns "undefined" when no filter is set or one has been set and cleared, rather than False. Either a duff copy in the Coolite assembly, or what smells like a bug in the implementation. Unless of course a return type of Boolean is now a tri-state of true, false and undefined?
Joel of Joel on Software posted an interesting entry a while ago that makes a point about time vs developer resource.
The part I'm interested in starts about a third of the way down the page. (by the picture of a skyline) A former lecturer of Joel's began gathering statistics regarding the amount of time his students were taking for various pieces of coursework. The statistics and analysis make fascinating reading, especially when you see that the logical conclusion is that "The quality of the work and the amount of time spent are simply uncorrelated". This quite nicely reinforces the fact that throwing additional resource at a project will not help the situation. To quote, "the man month is mythical".
Maybe you could throw more resource at the QA/Testing side of the project? Maybe with contractors. However, every product has a learning curve. For someone to be able to test something, even with the most comprehensive of test scripts, the most controlled of environments, some knowledge of the system being tested is inherently required. Without it you won't get much, if any, value out of additional resource. Obviously this can be alleviated by only hiring the best of the best, maybe by choosing Testers who are:
- Self-motivated
- Quick on the uptake
- Independent and self-sufficient
But, If you don't have people that fit those criteria, adding more resource will just make the situation worse. Your current people will spend more and more time working with the new team members and overall productivity will plummet. Something that has to be watched for, and managed, very very carefully. Anyone (theoretically) could execute a test script. But a tester who knows and is familiar with the system, can then investigate a defect encountered, diagnose the problem and provide the maximum ammount of information to the development team possible. This has the benefit of providing development with as much information to reproduce the defect as is available. Possibly with additional test cases that came to light from the testers research. Maybe even a proposed fix if the tester is technically minded.
Compare and contrast that to the value of a tester who lacks experience with the system being tested and is merely following a test script. If they don't know the system they're likely to log the defect and then carry on with further scripts, possibly resulting in them wasting time as a defect could impact multiple areas of the system.
Are contractors really adding value to a project? Yes -- if the project is right and you can get sign-off 125% of the contractor resource you need to do the job.
I'm fairly certain I haven't linked to this before, but, Incessant Ramblings: The anatomy of a bug makesfor a fantastic explanation of something that I deal with day-in, day-out at work. Yes, it might be a bug, but we know about it. There's a work-around. The cost of fixing it is too high. Sometimes I wish it was easier to get people to appreciate that.
What makes it even better is that the example used in that article is one of a problem I encountered this month when mucking around when mucking around with deploying to a mobile device! Fluke or,.. ?
Spurred by: The Perfect Bug
Having read this blog entry and found it really rather interesting, it's got me thinking about Severity and Priority of defects/bug reports. What's the difference between these two mythical beasts? Two pages that google hunted out for me seem to agree that Priority is business and Severity is technical. However, the latter (the one from StickyMinds.com) argues that Severity and Priority should be abolished, which would make me happy indeed! Say, for example, you have a piece of functionality which can cause the application to crap out and save nothing done since the last save, but you know that very, very few customers use this functionality, does that make it a High Severity but a Low Priority? It seems logic that the importance of the problem to the customer is defined as "Priority" and the impact of the defect on the system is "Severity" but still, surely a unified defect classification model would make far more sense.
Which is more important to resolve? (Scale runs 1 to 3 for both Severity and Priority)
Severity 1, Priority 3 defect [ Big Technical Flaw - Low Customer Impact ]
See Above!
Severity 3, Priority 1 defect [ Small Technical Flaw - High Customer Impact ]
Maybe there's a work-around that is a massive inconvenience for the customer to use, or it slows down their use of the software, maybe making it a nightmare to use? How-about, if you navigate backwards and forwards in a wizard it doesn't persist any data, except if you navigate from start to finish....
Related Links:
