Ask HN: How do you keep track of software requirements and test them? • Hacker News Board

Re: Ask HN: How do you keep track of software requirements and test them?

#131

Post by funcDropShadow » Thu, Apr 21, 2022, 8:04 AM UTC

null_shift wrote: post #80

nonameiguess wrote: post #56

Earlier quoted context omitted.

Waterfall is a great methodology where warranted. It ensures you're doing things in a principled, predictable, repeatable manner. We see all this stuff lamenting about and trying to implement reproducibility in science and build systems, yet seem to embrace chaos in certain types of engineering practices. We largely used waterfall in GEOINT and I think it was a great match and our processes started to break down and…

Even with “hard” requirements in advance, things are always subject to change, or unforeseen requirements additions/modifications will be needed. I don’t see why you can’t maintain the spirit of agile and develop iteratively while increasing fidelity, in order to learn out these things as early as possible.

> I don’t see why you can’t maintain the spirit of agile and develop iteratively

The question is not whether you can't. The question is whether it provides advantages. Agile comes with its own downsides compared to a waterfall. Note, that I've been working with agile methods most of my career and I don't want to change that.

Re: Ask HN: How do you keep track of software requirements and test them?

#132

Post by airbreather » Fri, Apr 22, 2022, 12:05 PM UTC

maerF0x0 wrote: post #130

airbreather wrote: post #127

Earlier quoted context omitted.

I would very much like to understand how it might be possible to improve on the conventional workflow for the work I am involved in. But I am not quite clear what agile as you implement it means, in contrast to v-model and waterfall, and how it provides advantages (I am guessing accelerated schedule?) to the process. Can you refer me to any available online case studies etc, or provide me some more detail? The sector…

I recommend you learn more about SAFe agile https://www.scaledagileframework.com/ . They all have their merits, but I find this works up to complex organizations, and can simply drop the things that are not worth it for smaller businesses.

I'm not seeing great things about SAFE

https://www.smharter.com/blog/safe-a-collection-of-comments-...

Re: Ask HN: How do you keep track of software requirements and test them?

#133

Post by splittingTimes » Fri, Apr 22, 2022, 9:47 PM UTC

sz4kerto wrote: post #33

What we do: - we track work (doesn't matter where), each story has a list of "acceptance criteria", for example: 'if a user logs in, there's a big red button in the middle of the screen, and if the user clicks on it, then it turns to green' - there's one pull request per story - each pull request contains end-to-end (or other, but mostly e2e) tests that prove that all ACs are addressed, for example the test logs in a…

That sounds like a dream. We do medical systems as well, but depend heavily on manual testing. We use digital scans of a patients mouth to design a restoration in our CAD application. So we have a 3D scene where the user interacts with/manipulates the objects in it.

Not knowing what kind of application you produce, but how do you automate user interactions?

Re: Ask HN: How do you keep track of software requirements and test them?

#134

Post by hotcrossbunny » Wed, Apr 27, 2022, 7:00 AM UTC

ako wrote: post #94

orangepurple wrote: post #52

Earlier quoted context omitted.

If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. ~ Gerald Weinberg (1933-10-27 age:84) Weinberg’s Second Law https://www.mindprod.com/jgloss/unmain.html

Programmers don't build, they design. It's more akind to what building architects do in a cad program. They go through many iterations and changing specs.

When programmers are designing it is more likely to be in the early stages when the program is still small. Often once the program gets bigger, the effort devolves to simply building. They might feel like the design is wrong, but the inertia by then is against the design evolving.

What we need is a practical way to keep the design and implementation synchronized and yet decoupled