tag:blogger.com,1999:blog-87552922930381785182024-02-07T06:28:45.558+01:00My 2Cents on AgileTesting // Architecture // Software Engineering // CoachingDaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-8755292293038178518.post-7412633348907290562016-10-12T21:45:00.000+02:002016-10-12T21:45:56.397+02:00Product Owners don't cut WoodDoes this sound familiar to you? There is this backlog grooming session every week. The product owner would present his user stories. They have title no one in the room understands. They follow the Connextra template of as-a I-want-to so-that. When reading this you sometimes feel like you get a notion of what the title of the whole thing may have meant to mean, but it doesn't grab a hold with youDaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-39018286586532656742016-09-28T21:09:00.001+02:002016-10-12T21:40:47.711+02:00There Are No Agile Testers - Balancing the power
This is a follow-up on my posts regarding developer testing versus tester testing which came to the conclusion that rather than having a QA department or a micro QA embedded in an agile team in form of a number of testers I'd prefer to have developers taking on a QA and QC perspective in their day-to-day work. All of the posts negated the need for a QA department.
I intend to change my mind. ADaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-68679957972616522642016-06-23T10:46:00.000+02:002016-06-23T10:46:00.327+02:00Do experienced developers have to learn?
Just recently I’ve had the not so nice experience of
ignorance presented publicly. There has been a session on software engineering
a colleague and I compiled for our department. The narrative was around
extensible architecture a topic that would need some promotion round here as we
are faced with a bunch of legacy code.
Virtually no-one showed up. Afterwards I figured that they
were too busyDaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-43370233215298745252016-04-07T20:31:00.004+02:002016-04-07T20:31:52.821+02:00Approaches to Distributed Development of a Software ProductNote: This article will be published as a series of installments. See the installment history at the end of the article to track changes.
Introduction
Just recently I came to think about a proper setup for a product developed by distributed teams. As it happens the use of git was a prerequisite. When working with Distributed Version Control Systems (DVCS) like git teams see themselves faced Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-57298241294974642462015-11-11T23:08:00.003+01:002016-09-28T21:06:50.006+02:00Agile Testing Days 2015: There Are No Agile Testers - There Are Testing Facilitators
I had the opportunity to attend Agile Testing Days 2015 in Potsdam. It's been the second time. And again, there haven been great sessions, inspiring talks, eye-opening chats. But still there is something that bothers me. If you following my blog post you might have noticed the "There Are no Agile Testers" blog posts:
Agile Testing Days 2014: There are no Agile Testers and
Agile Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-20917181895443851262015-09-24T14:52:00.002+02:002015-09-24T14:52:40.789+02:00On Coaching Agile: A Matter of Gray - Don't let prejudice guide youJust recently I was receiving a mail containing a quote which went like this:
"I get paid for features not for tests"
It has been put in a context where we were discussing something like code coverage or test coverage issues. That's the setting. What happened next?
To me this quote in this very moment and this very context has been proof that there something was totally wrong. Based on this Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-8529775151459226762015-08-11T20:01:00.000+02:002015-08-11T20:01:35.123+02:00Agile Methodology Breast Feeding
How come that many of us developers are struggling with agile methodologies like test-driven development or componentization/modularization of a software?
I was asking myself this for a long time now. Being an agile coach I frequently see developers fail applying these techniques in their daily work. Intelligent people that are able to write code to take care of the most complex problems Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-21743084720171844812014-12-19T23:01:00.001+01:002015-06-21T08:09:38.500+02:00Agile Testing Days 2014: There are no agile testers - and no agile developers either
Just recently I wrote a blog post in response to the Agile Testing Days 2014 I was glad to have attended. This post was received controversially, to say the least. There have been many in favor for what I was saying, and there were many that didn't like it at all. For several reasons. I've got involved with interesting discussions with many of my readers., most of which led to the conclusion Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-58963473412405624112014-12-06T13:20:00.000+01:002014-12-06T13:20:11.375+01:00On Coaching Agile: Techniques - Show and tellWhen coaching agile methodology as well as with any other coaching you are supposed to make your point in a way that coachees are not only able to repeat what you have said but to get the idea of it. They are supposed to be able to adopt the principles to their own daily work. This will only work if you get their attention and to make them listen instead of just hearing. If you do not manage to Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-48516561909074871412014-11-17T21:27:00.000+01:002014-11-29T15:02:32.250+01:00Agile Testing Days 2014: There are no Agile TestersFortunately I had the opportunity to attend the Agile Testing Days 2014 in Potsdam, Germany. It has been a great conference. I got so many new ideas out of it. It was very well organized and there were passionate and well chosen speakers around. I regret to only have booked the first and third day, especially for they built a car in the hotel lobby on day two. And I missed that one.
To give you Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-9582735825680031932014-11-14T22:33:00.000+01:002014-11-14T22:33:11.265+01:00On Coaching Agile: Techniques - Make a Bold StatementIn coaching agile methodology or coaching in general making people to leave their comfort zone or pushing them out of it would be key to get your message across, to bring about a change. You want to make them think, open up their minds to the new concepts and ideas. There are several techniques to achieve this. Last time I was talking about the power of a simple question: What do you want to testDaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-65955542033954058572014-10-27T22:08:00.002+01:002014-10-28T07:26:51.057+01:00On Coaching Agile: Killer Questions - What do you want to test?
When coaching teams or individuals in agile techniques like TDD, Refactoring, Clean Code, CI, you name it then I've found out that certain questions yield interesting effects. My absolute favorite would be this one here:
What do you want to test?
In the meaning of: What feature or behavior do you want to test?
One of the key take aways in trainings on agile techniques would be the Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-57425059769964054852014-10-23T14:00:00.000+02:002014-10-23T14:00:32.032+02:00Interlude: A practical experience with quarantineSometimes one develops nice ideas or puts down some thoughts and then reality kicks in and what has been a nice theory gets under pressure by the events of daily life. Same for me. Recently I was talking about Sporadics and the attitude of shrugging them off. I was talking about people and the need to put them first and processes second. And I was talking about a quarantine to give people a Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-62182820759176285662014-09-28T20:50:00.001+02:002014-09-28T20:50:51.748+02:00To Quarantine or Not To Quarantine Contagious Tests
Something is rotten in (the state of) your code base and spreads like a disease. Where there was only one soon enough there will be many. They are contagious as hell - Sporadic failing tests in already secured code. Regressions that is.
In my last post I extended the Green Mainline Policy by a human factor which might help to bring the Green Mainline Policy forward in environments that are Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-78477868296128743602014-09-14T20:07:00.001+02:002014-09-14T20:07:49.784+02:00Process vs people – Or: Processes won't fix you bugs
In the last post I proposed a technical solution, a process to raise the urgency of failing tests in mainline production. By closing mainline for changes when the build is broken the “Green Mainline Policy” is able to put so much pressure on developers that
“There are no excuses for not fixing the issue anymore. But does this change the attitude we talked about earlier? Probably not.“ Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-84228170619452474272014-09-06T10:21:00.000+02:002014-09-07T19:58:44.034+02:00Tune up the Speakers – Let Sporadics Scream at youIn my last post on this topic I pointed out that the main reason for Sporadics to creep into your test base would be the lack of urgency to prevent them from doing so. These days’ developers find themselves confronted with concurring requirements and fixing Sporadics is one of the least pressing ones. Thus making them more pressing would be required to move them up the queue. And we’ve talked Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-22482025824437565762014-08-28T16:00:00.000+02:002014-08-28T16:00:38.398+02:00Where do these Sporadics come from?
In part2 of this series I concluded that automating the
detection of intermittent, random or non-deterministic tests (aka Sporadics)
comes with unforeseeable extra costs. It may serve as a monitoring of Sporadics and might yield information to rank the Sporadics to decide which should be solved first. But if the efforts stop there then one has basically invested in managing status quo
Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-7018287183124343992014-08-22T17:11:00.004+02:002014-08-24T10:14:38.665+02:00Let the CI server take care of these SporadicsIn my last post on Sporadics (http://bit.ly/sporadics-1) I came to the conclusion that Sporadics do matter. Sporadics litter your test suites with failures. Any test suite with failures requires attention. Someone needs to have a closer look to figure out what went wrong.
If test suites usually succeed, any test failure would signal an issue that was just introduced by the very change or in caseDaniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0tag:blogger.com,1999:blog-8755292293038178518.post-22554092392602474432014-08-15T09:59:00.000+02:002014-08-24T10:13:50.377+02:00Sporadics don't matter
In my daily
work I quite frequently stumble over the phenomenon of - as we call it - Sporadics.
Sporadics are tests that fail every now and then for a bunch of reasons. Other
great blog posts call them intermittent test failures (http://spin.atomicobject.com/2012/04/27/intermittent-test-failures/)
or non-deterministic failing tests (http://martinfowler.com/articles/nonDeterminism.html).
Daniel Kirmsehttp://www.blogger.com/profile/16401820737954096059noreply@blogger.com0