Retrospection and learning time

Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.

While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…

  • MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
  • Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
  • Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.

As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.

With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂

Our problem with test planning

There’s in an email thread in our office discussing a problem with the unit test plans of our newbie testers. Our senior tester raised that the newbies’ test plans seem to have been directly ported from the functional specs. That didn’t sound good. There’s a saying that the devil is in the details. And our functional specs usually just offered the high-level, logical design. If they had indeed simply transcribed the fspecs into test cases, then they might be missing critical test cases. Another problem raised was that the stringent standards compromise the efficiency of the test plan preparation. Now, with the level of details they are putting into the test plan, I worry whether they’ll actually use those plans during test execution.

I reckon that just as we try to make our programs usable, we should also do the same for our test plans. We must recall that the test plan is a tool, a guide. It should help us testers rather than inhibit us from doing out jobs efficiently. On the other hand, we also have to consider that sometimes the test plan is a deliverable. But for what exactly do the users want the unit test plans for? Knowing this would help us determine the level of details that we put into the test plans. There’s got to be some ground in between wherein we satisfy user requirements AND still manage to come up with a more maintainable, more usable, more efficient test documentation. Not finding that common ground can only be wasteful. Now if only I knew how. =/

Continue reading