Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ladybug user stories, first draft #110

Merged
merged 14 commits into from
Jun 17, 2024
Prev Previous commit
Next Next commit
Follow Sander's review comments
  • Loading branch information
Martijn Dirkse committed Jun 7, 2024
commit 1bd9bd70f6b1e26bae7df64666a1f5d5d43fb5ae
10 changes: 5 additions & 5 deletions misc/LADYBUG_USER_STORIES.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Ladybug is not limited to work with the Frank!Framework; it is a tool that can b

The Frank!Framework creates a Ladybug checkpoint for each pipe and each pipeline. Frank developers can thus see how each pipe transforms the message going through the pipeline.

Ladybug can be used as a debug tool. Ladybug provides a user interface that shows a table of all captured reports. When the user clicks a report, it is opened in a tree view. Multiple reports can be shown simultaneously in the tree view. Each checkpoint of each report is a node in the tree. Collapsing and expanding nodes is described in more details in the user stories below. When you click a node, the corresponding message inside the checkpoint is shown.
Ladybug can be used as a debug tool. Ladybug provides a user interface that shows a table of all captured reports. When the user clicks a report, it is opened in a tree view. Each checkpoint is a node in the tree. Collapsing and expanding nodes is described in more details in the user stories below. When you click a node, the corresponding message inside the checkpoint is shown.

In the tree view, the user can see all intermediate results of processing each message. Each checkpoint has a meaningful name. The Frank!Framework names each checkpoint after the adapter or pipe name. Therefore the user can relate the checkpoint's message to the debugged/tested source code, or to the Frank application being tested.

Expand Down Expand Up @@ -56,15 +56,15 @@ This page presents a few main user stories and groups the other userstories as s
* **Estimated memory usage:** TODO: What does this mean?
* **Storage size:** TODO: What does this mean?

**120:** As a Frank developer, I want to be able to add columns to the report table in addition to the ones shown in story **100**. I am willing to write Spring XML files to achieve this.

TODO: Do I have to specify what metadata extractors we have?
**120:** As a Frank developer, I want to be able to add columns to the report table in addition to the ones shown in story **100**. This way I can support the customer's tester who wants to search reports based on customer-specific data (see story **10**). As a Frank developer I am willing to write Spring XML files to achieve this for the customer. Customer specific data appears in the checkpoints of the reports, so I need Java Beans that together provide flexible search capabilities.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Geen reden aangegeven.
Ook gaat de tweede helft meer in op de oplossing dan de user story. Ik zou deze tweede helft weglaten. Ik hoor hier graag meningen over.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik hoop dat ik dit beter heb opgeschreven.


**200:** As a Frank tester I want to hide reports from the report table in which I am not interested. This way I can find the report I need more easily. For each metadata field I want an edit box in which I can write a regular expression. Only if for a report all the metadata fields satisfy their regex, then the report should be shown in the table.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

regex isnt the approach, drop down selection lists based on the current data in the table should be the user friendly way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regexes are more flexible. I think some users need that flexibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Het zou nu netjes voor verschillende users uitgeschreven moeten zijn. Sommige users willen regexen, anderen niet.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er zitten hier twee user stories in één.
De eerste twee zinnen horen bij elkaar, dan heb je de acteur, de wat en de waarom.
De derde zin is een aparte user story.
De laatste zin twijfel ik over. Dit zou of weg moeten, in een aparte user story gezet moeten worden of samengevoegd moeten worden in de eerste zin.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik heb dit geëdit op basis van Jaco's opmerkingen over de verschillende wensen van de service manager, de support engineer en de Frank developer.


TODO: What syntax do we support for the filters?

**210:** As a Frank tester, I want to see the reports ordered by the timestamp of the outer start checkpoint or by the timestamp of the outer end checkpoint. The latest timestamp should be in the topmost table row.
**210:** As a Frank tester, I want to see the reports ordered by the timestamp of the first start checkpoint or by the timestamp of the last end checkpoint. The latest timestamp should be in the topmost table row.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hier ook geen reden gegeven. Waarom zou een Frank tester dit willen?


**220:** As a Frank tester, I want to be able to sort both ascending and descending with respect to the timestamp of story **210**. This helps me to find reports more easily.

**300:** As a Frank tester I want to see how many reports-in-progress there are. There is a report-in-progress if for some correlation id the start checkpoint is not yet matched by a corresponding end checkpoint.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see and be able to open?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that reports-in-progress are not yet to be opened. These reports are not complete because the start checkpoint that started the report has not been matched by an end checkpoint yet. There is a user story that Ladybug should forcibly finish a report-in-progress to make it a regular report. That regular report can already be opened by the user.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik zou de definitie van report-in-progress eruit laten of apart zetten.
Ook hier mis ik de reden waaorm een Frank tester dit zou willen.


Expand Down
Loading