EnterEsc2026-06-08T15:10:55+02:00Sebastianhttps://www.enteresc.netNews: See my appsSebastianhttps://www.enteresc.net/news-see-my-apps/2026-06-08T15:09:00+02:00
I going to make the apps I'm developing in my free time available here on my website.
]]>
Agile isn't always AgileSebastianhttps://www.enteresc.net/agile-isnt-always-agile/2026-05-25T10:18:22+02:00
Stefan Roock describes multiple process models in his article about hybrid project management forms (Link, German) with very specific details. The following is my approach to boil them down into one, Agile in Waterfall and compare them with Waterfall and Agile.
]]>
Stefan Roock describes multiple process models in his article about hybrid project management forms (Link, German) with very specific details. The following is my approach to boil them down into one, Agile in Waterfall and compare them with Waterfall and Agile.
Details of concrete implementations may vary. If you want this, take a look at Stefan's article.
Action
Waterfall
Agile
Agile in Waterfall
Scope defining a high-level definition of what to develop
Mostly upfront, without a bigger chance to incorporate feedback and changed context.
Just as much as needed for current the iteration* with good enough quality by the whole team.
The same as Waterfall.
Requirements defining concrete details of what to develop
Mostly upfront, without a bigger chance to incorporate feedback and changed context.
Just as much as needed for the current iteration* with good enough quality by the whole team.
Just as much as needed for current the iteration*, but limited to the fixed scope.
Development creating the product increment
Covering nearly all requirements in a single shot, without much feedback from testers or customers. Not always developers are invited to previous actions.
Just as much as needed for the current iteration* with good enough quality by the whole team.
Just as much as needed for the current iteration*, but without learning from customer feedback.
Testing investigating the actual state of the product and reporting it
Covering a big, so far untested, product with little chance to inform previous actions. Also testers are usually less often invited to Scope and Requirements.
Just as much as needed for the current iteration* with good enough quality by the whole team.
Just as much as needed for the current iteration*, but without learning from customer feedback.
Customer Feedback giving feedback how good the product solves customer needs
High potential for the product not matching the needs good enough. Scope and Requirements can usually only be adapted by higher costs.
Can influence the next cycle's scope and the team gets early feedback to incorporate.
The same as Waterfall.
To some degree it could also be withing the iteration, but then it is more about details and less about potentially changing the scope.
* iteration: could be a Scrum sprint as well as ticket in Kanban (working on multiples in parallel). Can include release work as well.
Any agile framework can be in Agile or Agile in Waterfall, depending on the context. Scrum, XP, Kanban, etc.
Method as Agile means: A team is allowed to learn from their work, especially by feedback from the customer. It adapts to the feedback and work. Iterations are about finding out what the customer needs.
Method as Agile in Waterfall mean: A team is not prohibit to do learn and the framework is mostly used by management for team control. Iterations are mostly about breaking one big Waterfall plan into smaller milestones and judge the team's effort on reaching them.
The difference between both can sometimes be tiny details and it is easy to fall from one into the other. This is at least a spectrum where teams can be more or less agile, incorporating feedback reasonable early. I made this separation is show the key differences more prominent, but it depends on details.
What do think is your team and company doing and why is it like that?
I choose the colors intentionally to make the graphic better readable for people with color vision deficiency.
]]>
Why a test column on boards is a problemSebastianhttps://www.enteresc.net/why-a-test-column-on-boards-is-a-problem/2026-05-17T10:01:00+02:00
I often see on boards columns like “Open”, “Dev” or "In Progress" (but still just being for developers) and next to them “Test” or “QA.”. And ticket moving through it and handovers happening between columns. Developers stop working once they are done (with a first version) and testers just start once they got the ticket handed over. Sequentially working on it instead of doing it in parallel where doable.
In this article, I explain why I see this structure as a problem, how it can cause issues if enforced, and what possible alternatives exist.
This is an updated version of an already existing article. Also available in German.
]]>
I often see on boards columns like “Open”, “Dev” or "In Progress" (but still just being for developers) and next to them “Test” or “QA.”. And ticket moving through it and handovers happening between columns. Developers stop working once they are done (with a first version) and testers just start once they got the ticket handed over. Sequentially working on it instead of doing it in parallel where doable.
In this article, I explain why I see this structure as a problem, how it can cause issues if enforced, and what possible alternatives exist.
This is an updated version of an already existing article. Also available in German.
You can use a test column on your ticket board when
… only one task can be carried out at a time at that ticket. Development XOR Testing.
The notion that testers can only begin after development has started is based on the misconception that testing is reduced to mere interaction with the product. Like an executable (of a very final version) to exist would a precondition for any testing work. As if no preparatory work were possible, or as if interaction with the product could not take place in parallel with development (e.g., at various intermediate stages).
A command-and-control mentality may be another root cause. This is not conducive to constructive collaboration and rapid feedback.
Some models of actual workload
This are some simplified models of what I observe regular. Reality is way more complex.
When is a ticket changing from the Dev to the Test column by this distribution of the work???
=> Test after Dev is a problem
Testing benefits from preparation
Gathering information, planning (e.g. coverage and approaches), preparing test data and tools and many other are tasks in testing which can be done/started without an actual product - before or while the code is written.
What are good reasons to postpone this until the development of the first version is done? Aside from a lack of time. It would be a waste of time and being a risk by extending the feedback time for the developers.
=> Test after Dev is a problem
Testing can be integrated into development
Here are two examples from my daily work where I’ve collaborated closely with developers, and we couldn’t even say for sure which column a ticket was currently in.
Pair / Ensemble testing with developers on their computers. They showed me the application, and I advised them on what to try. During these sessions, my colleagues made code changes and, when necessary, rebuilt the application so they could test it again immediately.
I can build and deploy the product locally myself. With this setup, developers send me code changes at short intervals (git push & pull), which I then test within minutes—often while we’re on the phone or chat.
=> Test after Dev is a problem
Testing can be done in parallel to development
It happens frequently that I interact with the product while in parallel developers still code by to basic scenarios:
They start fixing bugs while I continue testing.
I start testing not yet fully developed features where we agree on that I should just look at specific places. Early feedback. I test while the developers code.
=> Test after Dev is a problem
What about tickets?
All above is true no matter how your work is organized.
Bug tickets - Testing is here first (and also last)
Bug tickets in general about that someone found a problem, aka tested, and reported that. And often, especial when coming from the customer, they describe mostly symptom and don't give a good manual of how to reproduce and exact details.
A tester has to find out the scenario and causes, then developers (try to) fix it and finally it needs a test of the fix (and maybe some more loops). Would this ticket start in a test column and the switch back to dev? …
Test needs to act first.
=> Test after Dev is a problem
Single ticket for multiple people
Somehow you just a have single ticket, but multiple people (can) work at in parallel. Maybe you use sub tasks, but you use them per sub topic and not per task / craft. The people can be only developers, testers or a mixture of both. To which column would you put such ticket, especial at the mixed case? And e.g. in Jira a ticket can only have a 1 assignee
=> Test after Dev is a problem
Summary
Testing and development are tasks that can generally be carried out in parallel. Just because no code has been written yet doesn't mean that testers have nothing to do.
Also they both are a feedback loop:
Testing informs (at least) development and (at least) development gives testing something to interact with.
This loop can be run several times in a few minutes. Feedback is sooner better than later. If developers have already switched contexts, it takes them longer to get back on track.
Every ticket in a issue tracker is a (simplified) model of a more complex reality. Especial only one assignee possible is often far from reality of team work.
Alternatives
Here are some ideas what to do instead.
Task oriented:
Add a list of tasks in the ticket and add names to them. Here goes the same for state.
Use sub tasks and assign them. They have already a state field. I suggest to have a simple workflow here.
People oriented:
Note in the ticket all people who are working on it.
You can add a state by a word or icon to show who is still working and who is finished.
Some ideas what task you could add for testing:
Prepare X, Test Y, Review/Debrief Z
When testing covers multiple, separate topics and people you can add multiple test sub task.
When using Session-Based Test Management (Wiki, Article) you can create a sub task for every session
Need to prepare data ? Need to develop or enhance a tool? Need to learn the product? Need to … whatever? Add a task.
Others say the same - further articles
There are multiple people advocating the same goal.
A "testing" column represents testing as a monolithic black box. It says nothing of what the testing work is or offers any notion of how long it ought to take. I like the way session-based test management breaks testing into visible, easy to schedule activities. I prefer testing being a mix of either be an assumed part of doing the development work, or the testing sessions on the schedule as explicit activities with their own card moving across the status columns.
The test column often doesn't make much sense when the dev column isn't even the "dev" column, but "in progress", like testing doesn't mean the task in still in progress. It makes even less sense when you consider development still goes on in the "test" column due to bug fixes or further changes. If anything, the test column should be at least "testing and potentially some more development still". Removing work items from the board altogether and reducing status columns to just "Todo > WIP > Done" with sub-tasks for all activities related to the work item is so much better, and allows multiple different activities assigned to different people in a team that can be completed at the same time.
What would you add? Contact me how you want to. I would like to read any opinion.
]]>
News: Alternatives for a test columnSebastianhttps://www.enteresc.net/news-replacements-for-a-test-columns-added/2024-10-12T20:35:13+02:00
I added alternatives for a Test / QA column to the article.
]]>
Done is not just a documentSebastianhttps://www.enteresc.net/done-is-not-just-a-document/2024-02-24T19:18:47+01:00
I see Scrum's "Definition of Done" being off as Done is often treated as an artifact, but as not an agreement between people.
People agree on if something is done. Any document is just a tool for communication about this.
I'm shocked by reading the section of 'Commitment: Definition of Done'. It just talks about artifacts. 'Definition of Done is a formal description' I don't not see much of the first principal of the Agile Manifesto shining through.
I work since 10 years mostly in Scrum in different teams. By my experience we achieve the most satisfying results for the product owner and customers when the developers (including testers etc.) have constant exchange (at least) with product owner. "Fail fast, fail often", show it often and get feedback (while staying in the focus of the story). Short feedback loops are important! At least clarify unknowns and don't make arbitrary assumption when you have someone you can ask.
'Definition of Done is a formal description' No formal description can fit perfectly to every backlog item you work on. Sometimes you have to exclude things, sometimes you have to include story-specific criteria. And every general criteria is different for every story. e.g. 'create user documentation'. How much is enough? The DoD can't tell you, but your team mates and the stakeholders.
Surely you should not have feature-creep at a story and changing already defined details every minute should not happen. This is the extreme I also not endorse.
Finally only responsible people will create a good product. This includes to trust each other, communicate, and not just to rely on artifacts.
It is not 'Done', it is 'done'. Not a noun but an adjective. The same as it should not be 'Agile', but 'agile'.
Rewrite of the guide's Increment section
To make my point more clearly I rewrote the Increment section v2020 to fit more to the first Agile principal by my understanding.
My text
Original
(I'm fine with this part)
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless the team agrees it to be done by different criteria.
Commitment: Shared understanding of Done
For every Increment agrees the team on quality measures required for the product to be meet to consider it Done.
The moment the team agrees a Product Backlog item to be Done, an Increment is born.
Having a shared understanding of what work was completed as part of the Increment creates transparency. If a team does not agrees on a Product Backlog item to be Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
It may help to note most of this quality measures in a document, a so called Definition of Done. This document is just a starting point as the team may find necessary quality measures for an Increment later on. While there might be some shared quality measures for multiple Increments, for some Increments individual quality measures might be necessary.
If an understanding of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must agree on their understanding of Done appropriate for the product.
The Developers are required agree on a shared understanding of Done. If there are multiple Scrum Teams working together on a product, they must mutually agree on the same understanding of Done.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
What are your thoughts on this? How do you and your team decided about what you consider done?
]]>
Perception of GUIs - a human vs computer memeSebastianhttps://www.enteresc.net/perception-of-guis-a-human-vs-computer-meme/2023-07-26T07:30:00+02:00
I have create this comparison to visualize how different humans and computers process GUIs. Both are having their dis- and advantages.
]]>
News: A change to my RSS and Katja Obring about killing the test column and Sebastianhttps://www.enteresc.net/news-a-change-to-my-rss-and-katja-obring-about-killing-the-test-column-and/2023-05-27T23:32:01+02:00News to my RSS - shorter format
As reader by RSS you may now experience that you just see the beginning of the article and have to do more clicks (one?) to read it in your browser.
As a I update my articles every now and then, I intend this to have the full articles just available at my website.
I'm still working on the details like having a link in the text that you get. This is a matter I have to figure out at Publii.
By her perspective she adds some more useful details like how to implemented this change.
Give it a read and spread the idea!
]]>
News: I rewrote my test column articleSebastianhttps://www.enteresc.net/news-i-rewrote-my-test-column-article/2023-04-29T00:42:10+02:00
After some feedback I rewrote most parts of the article. It had some heavy bugs in it which I was not aware of so that my readers became my testers and told me. Would you give it a another try?
Like often in IT (by my experience), a early deliver was the more important quality than (finding) issues in the product. Would I have found them without the feedback, being ‘betriebsblind’? I do not know… I let test happen “in production” … which I like here, but have to communicate it more clearly, I guess. I'm having versioning of articles in my mind.
If you read this via RSS, depending on your app, you should be able to update the feed entry so you got the new content there.
]]>
Ambiguous phrases in testingSebastianhttps://www.enteresc.net/ambiguous-phrases-in-testing/2023-04-11T20:52:23+02:00
I see many people using at least one of these phrases …
test(s)
case(s)
test case(s)
scripted test(s)
scripted case(s)
scripted test case(s)
… and referring to one of this (at least) 2 concepts:
Code, as used in automation (aka checks) like
@Test checkSomething(){ … Assert.That(x,y) }
Manuals: instructions to describe what humans should execute
Step #
Action
Expected Result
Comment
1.
do something
x should happen
notes of deviations
…
… without giving more context which one they mean!
Here is a simplified example of typical discussions I observe:
A: "It is important to do <phrase> !"
B: "How? Code is not testing."
C: "How? Binding instructions are limiting the testers."
I'm sad about so much ambiguity, as it causes many misunderstandings and misguided discussions.
At the very last:
Would you kindly add always if you refer to code/automation or human executing instructions? Pweeeaaase 🙏
No. Its not clear when you use one of the phrases when you do not give context.
There is even a 3rd option
I saw this 3rd option never in relation to "scripted", therefor it applies only the first 3 cases:
General note-taking/planing/design in testing. In the from of lists or mind-maps in a more exploratory approach. This can be either standalone or second the other two. With limits it occurs in the comment section of manuals.
Sounds this like influences of Rapid Software Testing? Might be. I can not deny them.
What would you add? Contact me how you want to. I would like to read any opinion.
What others added:
Ben Fellows:
I had a developer today use "test case" to refer to the conditions needed to manifest a bug. I.e. the repro steps. "We haven't yet found the test case for this bug".
Richard Adams:
In my first role regression testing was about verifying bugs. Most of the time we were doing destructive testing and occasionally it was scripted. All manual. In my next role those terms had different meanings.
Now if someone asks me if there’s any test scripts for testing X feature, I’d be digging out python files that I use to help my testing.
Having moved team, I’ve found more differences in meanings. There’s a huge push for smoke tests running almost non stop but different understandings on what that means. One other that annoys me is “escapes”. I always understood that as bugs found in released software but my work use it to describe anything that has been pushed.
