Archives
Generalising Specifications vs. Specification by Example - Verification vs. Validation
Submitted by Antony Marcano on Sun, 02/03/2008 - 10:49. test driven developmentSpecification by example is the concept underlying TDD (in all its forms). In essence, each test is an expression of an example of how a system (in the case of acceptance tests) or component (in the case of unit tests) will be used.
If you want to know why TDD is often described as a form of "specification by example" one of the best analogies is Jason Gorman's Kitchen (I know - strange that he has deviated from golf for a change).
Something I've noticed in the TDD discussions on the web is that the phrase "formal specification" is used to label other more typical techniques of specification. Formal specification has a specific meaning of course, but I'm not sure it is a fair term as I consider the application of "specification by example" in the form of TDD and Acceptance-Test-Driven Development as being very formal.
Python - Palindrome Checker
Submitted by Corey Goldberg on Sun, 02/03/2008 - 16:15.A palindrome is a sequence that reads the same in either direction.
Here is function I wrote to check if a phrase is a palindrome:
import re def is_palindrome(txt): txt = re.sub('\W+',
'', txt).lower() return txt == txt[::-1]
phrase = "Go hang a salami, I'm a lasagna hog" print
is_palindrome(phrTest Driven Development in .NET
Submitted by webmaster@testdriven.com (News) on Sun, 02/03/2008 - 17:15.A few days ago I had a session at a .NET conference in Germany (BASTA Spring 2008). I talked about software quality assurance and especially test driven development. Because of many people asking me about the details and the source code of my talk I wrote an article about TDD (including TDD of Web-UIs) with Visual Studio 2008 and WatiN: Bug Busters - Test Driven Development in .NET.
Making the rounds in veterinary circles
Submitted by Brian Marick on Sun, 02/03/2008 - 17:24.Two patients limp into two different American medical clinics with the same complaint. Both have trouble walking and appear to require a hip replacement.The first patient is examined within the hour, is x-rayed the same day, has a time booked for surgery the next day and within two days, is home recuperating.The second sees the [...]
Workshop on technical debt
Submitted by Brian Marick on Sun, 02/03/2008 - 17:36.From Matt Heusser:Personally, I believe that the “technical debt” metaphor is compelling. It explains the tradeoffs involved in taking shortcuts in terms that management can understand, and can take the vague and undefined and turn it into something more concrete.At the same time, it is not a perfect metaphor, it has weaknesses, and we [...]
Evolving an API
Submitted by Brian Marick on Sun, 02/03/2008 - 19:13.Nat Pryce wrote a nice little summary of what he’s learned about evolving an API.An API is a user interface for programmers. That means you have to develop it like a user-interface: iteratively, adapting to how the users actually use and misuse the interface in real life […] But… programmers focus on solutions, not goals, [...]
Rights to Run LoadRunner
Submitted by Alexander Podelko on Sun, 02/03/2008 - 21:35. Mercury LoadRunner | performance testing | performance testing toolsWhere the myth that you can use LoadRunner with a regular user came from? I got a client who refused to give me admin rights and I should research this question again. I did it before – but, in my practice, I usually return to the same question after such period of time that the only thing I remember about it is that I researched it before.
Well, it took some time. Doesn't look like the new Mercury knowledgebase is a major search improvement.
Well, it took some time. Doesn't look like the new Mercury knowledgebase is a major search improvement.
Multi-User Functional Testing
Submitted by Alexander Podelko on Sun, 02/03/2008 - 22:11. functional test patterns | functional testing | non-functional testing | performance testingIn the February issue of Software Test & Performance read Karen Johnson's article about multi-user testing (pp. 20-23). Karen writes about a very rare subject – functional multi-user testing. Should admit that I started to read with a thought "one more article about performance testing" – but soon realized that it is about quite different subject. And yes, indeed, without functional multi-user testing, most of errors mentioned in article will slip through (won't re-tell the article – it is available on-line, you can read it yourself). Some may be found during performance testing (probably the most severe like deadlocks – if they are in the typical scenarios you included in performance testing) – and you will need to trace them down to the source, and probably it will be much later down the cycle.
CMG'08 Call for Papers
Submitted by Alexander Podelko on Sun, 02/03/2008 - 22:21.See the message from the CMG Program Chair below. And yes: load and stress testing, benchmarking, performance optimization, software performance engineering, resource management, capacity analysis are among the major topics for the conference.
The CMG'08 conference committee is delighted to announce that they are now accepting abstracts for papers and workshops for the 2008 conference to be held in Las Vegas in December 2008.
The CMG'08 conference committee is delighted to announce that they are now accepting abstracts for papers and workshops for the 2008 conference to be held in Las Vegas in December 2008.
Test Axioms - second attempt
Submitted by Paul Gerrard's Blog on Sun, 02/03/2008 - 23:19.Here's my second attempt at a set of testing axioms. I've tried to name and define each with a 'one-liner'. The "Narrative/Action" makes a suggestion, and the "If you don't" suggests what might happen if you ignore the axiom. There are no recommendation as to the practice, process or heuristic you might want to deploy. Most axioms simply suggest you identify/agree/define an approach or appreciate/recognise a situation.
Advice for Simon: How good Dev teams fix bugs
Submitted by Erik Petersen on Sun, 02/03/2008 - 23:43. general software testingSimon posted to a software testing discussion list:
I’m working on a project at the moment which is slipping day on day and one issue we’re seeing is that the development team refuse to believe they can estimate how many defects they can fix in a certain time frame. I’m trying to influence them to do so (as is my manager) but having not been a developer (apart form creating the odd web site) I don’t know how true this claim is. Personally, I think by breaking a task down, or using a gut-feel based on experience you can estimate anything but they disagree stating that until they investigate they don’t know how long a defect will take to fix. Does anyone have any experience or ideas which could help?