Readit NewsDeleted Comment
lovehatesoft commented on Ask HN: How do you keep track of software requirements and test them? · Posted by u/lovehatesoft
Let the product owner (PO) handle them.
The PO has to make the hard decision about what to work on and when. He/She must understand the product deeply and be able to make the hard decisions. Also the PO should be able to test the system to accept the changes.
Furthermore. You don't really need to have endless lists of requirements. The most important thing to know is what is the next thing that you have to work on.
That would be nice, and maybe I should have clarified why I asked the question. I was asked to add a new large feature, and some bugs popped up along the way. I thought better testing could have helped, and then I thought it would possibly help to list the requirements as well so I can determine which tests to write/perform. And really I thought I could have been writing those myself - PO tells me what is needed generally, I try to determine what's important from there.
Or maybe I just need to do better testing myself? There's no code reviews around here, or much of an emphasis on writing issues, or any emphasis on testing that I've noticed. So it's kind of tough figuring out what I can do
lovehatesoft commented on Ask HN: How do you keep track of software requirements and test them? · Posted by u/lovehatesoft
As a junior dev, this isn't your job.
Your job is to do what is being asked of you and not screw it up too much.
If they wanted to track requirements, they'd already track them.
People have very fragile egos - if you come in as a junior dev and start suggesting shit - they will not like that.
If you come in as a senior dev and start suggesting shit, they'll not like it, unless your suggestion is 'how about I do your work for you on top of my work, while you get most or all of the credit'.
That is the only suggestion most other people are interested in.
Source: been working for a while.
Well so the reason I asked this questions is that I did screw up a bit, and I think it could have been caught had I done sufficient testing - but I didn't because it doesn't seem to be part of the culture here, and neither are peer reviews.
So I _was_ trying to do only what was asked of me, just writing the code, but I guess I thought what I did at my previous job could have helped - which is keeping track of what was needed and then how I planned to accomplish and test.
But yeah, you've got me thinking about how or whether I should broach this topic; I think my lead is great, seems open to ideas, wants things to work well, so maybe I'll just ask what they think about how to avoid these kinds of mistakes.
My opinion would be to not use all the fancy features that automatically tie issues to merge requests, releases, epics, pipelines etc... it's way to much for a small team that is not doing any type of management.
Just use some basic labels, like "bug" or "feature" and then use labels to denote where they are in the cycle such as "sprinted", "needs testing" etc. Can use the Boards feature if you want something nice to look at. Can even assign weights and estimates.
You can tie all the issues of a current sprint to a milestone, call the milestone a version or w/e and set a date. Now you have history of features/bugs worked on for a version.
In terms of testing, obviously automated tests are best and should just be a requirement built into every requirement. Some times though tests must be done manually, and in that case attach a word doc or use the comments feature on an issue for the "test plan".
* It seems like this would have been a milestone?
* So then maybe a few issues for the different classes or requirements?
* For each issue, after/during development I would note what tests are needed, maybe in the comments section of the issue? Maybe in the description?
* And then automated tests using junit?