Posts Tagged ‘agile’

Agile Frameworks and the lack of test expertise Martin Jansson 6 Comments

I am a tester and these are my perceptions and reflections on agile concepts. There are several agile frameworks available for implementation to guide the agile transformation. I have not experienced many frameworks myself, but I have experienced several implementations in an agile organisations. One core theme in the agile movement is that everyone should […]

Working with the testing debt – part 3 Martin Jansson 3 Comments

This is a follow-up from Working with the testing debt – part 1 [1] and part 2 [2]. The reason for the clarification is that you so easily come up with a tip without a context or example. Tip 3: Grow into a jelled team (read Peopleware [3] by Timothy Lister and Tom deMarco for […]

The automotive industry is not the role model Henrik Emilsson 5 Comments

This began as an answer to Rikard’s post http://thetesteye.com/blog/2011/06/a-word-of-caution/ where the discussion on “traditional testing” came up. I often hear comparisons with our “industry” and the Automotive industry. In that context, you could say that “traditional testing” corresponds to the methods and practices that are applied in line production of large car companies. And the […]

Agile vs. agile Henrik Emilsson 3 Comments

This was originally meant as an answer to the (ironic) thread http://thetesteye.com/blog/2009/06/long-live-the-waterfall/ where a new thread was forked when Ola Janson launched a couple of questions regarding agile development. My answers and thoughts on those questions are listed here. In one reply to Ola, Rikard says that he has “…never worked in a truly Agile project…” […]

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. […]