For a conventional software tester, an Extreme Programming project may be an intimidating challenge. Testers often find that they’re not welcome on XP projects, but Jonathan Kohl shares how skilled testing can overcome such difficulties. Jonathan discusses lessons he learned from working on two different XP project teams, only one of which initially welcomed his testing and feedback.Second Testing Article: FIT for Developing Software
You will often want to test that calculations are being carried out correctly, according to some business rule. Tables of concrete examples can help you to understand business needs and communicate what’s required. This chapter will focus on how to read such Fit tests, and why it is important to do so.
If anybody has read the whole article – is there any valuable information in it? It seems to be his life story at first look…
Yeah it is kind of long. However, it’s an interesting look at how good QA and XP can work together.
However it’s very telling that this subject gets only two responses. It’s clear that OS News viewers are more absorbed in MS bashing, desktop flamewars and general antagonism than articles about software quality.
I did read the entire thing, and if absolutely nothing else of value was derived from it, it clearly demonstrates that neither conventional testing or unit testing alone will catch the bugs/defects/misunderstood portions of an application. I’ve seen that demonstrated at my current employer with their main product, where it is mostly tested via a built-in scripting recording/playback facility that’s quite powerful, combined with some more traditional human testers, but currently the test coverage isn’t nearly as good as it could be, if only because the human testers are too close to the developers in knowing what to expect, and thus not doing the typical “oops” that comes with new users or those that make mistakes.
In fact, right before the most recent major release, I found a crash bug that was 100% repeatable whenever something invalid was entered into a field, but it hadn’t been reported before, simply because those testing it knew “Don’t do that!” and also used a slightly different way of telling the application to accept the input than I did via the GUI. This is a flaw that wasn’t visible with the built-in scripting language tests, because it doesn’t utilize the same GUI elements a user does. As long as the user used the edit control in exactly the way expected, even with incorrect values, it was fine, but as soon as a user stepped outside of those expectations, it did things in a different manner than expected, and BOOM!
My current task is improving the testing tools and the tests that are possible to do on the application
D’Oh! I’m not accustomed to replying to myself, but right after I wrote that post, I got an email from headquarters (I’m in an office on the other side of the US from them) stating there has been a an organization change, and I’ve been switched from an R & D developer to being a QA developer!!!!