‘Ideas’ Archive

Decisions around the product release – part 3 Martin Jansson 2 Comments

What is essence of the discussion on release team/showstopper meetings? I am assuming that there is a meeting. I’ve been to many different kinds of showstopper meetings and most companies handle them differently. One important item on the agenda for the meeting is usually the bugs that are found late in the project, thus at […]

Multi-Dimensional Software Testing Rikard Edgren 5 Comments

Thare are many ways to look at the problem of testing software, and it is rarely wise to use only one; that’s why there are so many mnemonics, e.g. SFDPOT, CRUSSPIC STMPL, HICCUPPS, FCC CUTS VIDS (http://www.satisfice.com/tools/htsm.pdf, http://www.developsense.com/articles/2005-01-TestingWithoutAMap.pdf, http://www.testingreflections.com/node/view/2823) Here are some questions for your confusion: 1) What? a) The functionality, what the software does […]

The Baker & The Tester Rikard Edgren 2 Comments

I’ve recently become addicted to baking bread. I don’t know why, but it has the same kind of magic as music and software testing; so I’ll try to make some analogies. Results – The best bread results come when there is long fermentation time, just as when a tester can spend a long time with […]

A Software Testing Dystopia Rikard Edgren No Comments

At EuroSTAR 2008 in Haag I will present “Testing is an Island – A Software Testing Dystopia”. The paper can be downloaded at http://www.thetesteye.com/papers/redgren_testingisanisland.doc The inspiration was the theme of the conference: “the future of software testing”; and I couldn’t stop seeing a very boring profession, where numbers and so-called objectivity is more important than people […]

Public test patterns and test data Martin Jansson 3 Comments

Test patterns, quality patterns, Q-patterns or whatever we wish to call it. I am referring to test ideas that can be reused in similar contexts. This could for instance be File Handling, Data Types, Installation, Upgrades etc. There is nearly an infinite list of areas that could test patterns could be available for. When you […]

Imperial life in the emerald city Henrik Emilsson No Comments

I need to recommend a great book by Rajiv Chandrasekaran: Imperial Life in the Emerald City. The reason I recommend this book on this blog is that the more I think of it, the more I think it resembles the way how certain processes or methods are implemented in the sofware industry without taking the […]

I like Adhocracy, therefore I am an Adhocrat Henrik Emilsson 4 Comments

I stumbled on a Wikipedia-article about Adhocracy today, and it made me think about software development methods and software development organizations. Here are my thoughts… Heavy-weight development processes strive for being more and more formal and thereby (intentionally or unintentionally) turning the organization into a bureaucracy. Whereas light-weight development methods seem to strive for the […]

How do you go about testing? Martin Jansson 1 Comment

A project manager, that had no knowledge about testing whatsoever, asked me how he should go about testing? The question was vague since he did not know where to start. I wrote him a quick email listing a few things to consider: Create a list of all use cases. For each use case consider possible […]

Risks in Agile projects Henrik Emilsson 3 Comments

Agile development methods are becoming a more popular way of producing software in contrast to traditional project processes. This has affected the testing profession in many ways, which has given us both benefits and new challenges. In a way, agile development methods can be seen as a reaction to a couple of traditional project risks. […]

Persuading about Exploratory Testing: The provocative-analogy way Henrik Emilsson 1 Comment

This is my reply to the thread “Persuading about Exploratory Methods” in software-testing@yahoogroups.com. This starts out with the problem that it is sometimes hard to persuade a manager about Exploratory Testing, when all that matters to the manager is that tests ought to be documented (in order to know what should be tested, how many […]