Strategy to identify and document edge cases for new features

[Mateusz Kwiatkowski]

Hi fellow devs,

as a part of OLMIS-5561 we need to propose some strategy for identifying edge cases in tickets that will be worked on. I would say that those edge cases need to be identified before starting working on them, so we have 3 possibilities:

* person who created the ticket should try to identify some egde cases while writing it,

* while discussing tickets on grooming meeting we should ask ourselves if any of those tickets can possibly have some edge cases, those which could have can be marked with some label,

* sprint planning meeting should probably be the best place to try find those edge cases, maybe only those marked with label from last bullet point

I was also thinking about going through some old tickets on which we've missed some obvious edge cases so we could list those as some examples, maybe also we could list some most common edge cases.

For now those my only ideas, I'll update this thread if something will come to my mind. I'll welcome any ideas on this matter or some thoughts how you are dealing with finding edge cases in your teams.

Best regards,

Mateusz

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[Sebastian Brudziński]

Thanks for this, Mateusz.

I totally support the idea of having a checklist of the "most common edge cases" somewhere and using it as a supporting doc during backlog grooming and plannings. I think this can already help catch most of the issues before the ticket reaches QA/regression testing phase. I guess one of the most frequently missed edge cases is "what happens if you don't have one or more of the required permissions".

Have you thought on the proper place to document edge cases? Would it just be a section in the ticket description?

Also, have you thought about a proper place to document the change in the process of identifying edge cases?

Backlog grooming / Sprint planning meetings seem like the best candidates to identify the edge cases to me. The whole team can quickly collaborate and brainstorm to identify potential issues.

I'm looking forward to those improvements!

Best regards,

Sebastian.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAHq-FDP_somdr4%3Dx0r8nkDzNmo-hKz7vCGTwo1oM%3D7BFVv99MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Sebastian Brudziński
Technical Leader
sbrud...@soldevelo.com

[Mateusz Kwiatkowski]

Hi Sebastian,

thanks for your feedback. I'll definitely include your suggestions in final document/page.

I think that the best place for edge cases for ticket would be a section in description as we are doing it now i.e. for ACC. I think that we've used to have edge cases written in separate description section before if I remember correctly.

I'm still not sure where to put all of this info, probably most of ideas and suggestions can be included in Software Development Methodology but I would say that list of common edge cases can have page on its own.

Regards,
Mateusz

[jbe...@soldevelo.com]

Hi Mateusz,

I think that the best idea would be to devote some time to identifying edge cases during the backlog grooming meeting, and probably also the sprint planning meeting. A list of common edge cases is also a good idea - I think it should be a separate page on Confluence.

Probably the most common edge case, the easiest one to find is one that I mentioned in the "Test Strategy" document:

An edge case or negative testing will consist, in this example, in checking what happens when trying to save the form when one or more of the required fields are blank.

But of course, there are also more complex ones, as Sebastian mentioned, e.g. those concerning permissions - I agree that we probably sometimes overlook it, unfortunately. In my view, the edge cases concerning a given ticket should be included in its description, the way it used to be months ago, when ticket descriptions used to be much longer than they tend to be now - there used to be a separate section concerning the edge cases.

[Sebastian Brudziński]

Thanks for this work everyone! I think the document (https://openlmis.atlassian.net/wiki/spaces/OP/pages/460882144/Identifying+and+documenting+edge+cases+for+new+features+in+progress) is now in a good shape. If anyone sees any common edge cases worth adding, please feel free to mention them or add directly on the page.

I encourage that the teams try it on during the next grooming/planning meeting. We will also go over the strategy on the sprint showcase.

Kind regards,

Sebastian.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/592782bc-c3a8-4d6f-919e-4a24287fe635%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.