How do you ensure the quality of the design when the design is "by doing"?

Question

I am convinced that an incremental design can be good.

But if in the beginning a bad design is chosen and the subsequent steps are always based on it, in my opinion it can also run very badly.

So how do you ensure the quality of the design when the design is "by doing"? How do you prevent the software from degenerating, because the team (or one of the teams) is always quick to hack something instead of making a meaningful design?

How can I get involved as a tester early enough to recognize bad designs early on?

I know the textbook wisdom, but does anyone have practical experience?

Answer 1

if in the beginning a bad design is chosen and the subsequent steps are always based on it, in my opinion it can also run very badly.

The whole point of iterative design is to be able to observe those bad decisions and be able to act upon them sooner rather than later. The team evaluates their design and implementation in each iteration.

when the design is "by doing"?

always quick to hack something instead of making a meaningful design

Iterative design does not mean zero design or thinking, or no upfront design at all. Some tasks are exactly that- design tasks or proof of concept tasks to evaluate different options.

Iterative design is about designing just enough to advance to the next step, it is true though that sometimes you need to take big decisions without enough information, for example which framework to use ? but then you get a chance to fix bad choices before it becomes impossible.

How can I get involved as a tester early enough to recognize bad designs early on?

"Just do it", insist on being involved as soon as possible. This will not only contribute to spotting bad design decisions bad will also contribute to the design of testing and stability for the coming project

Answer 2

There are a few practices and concepts that are very important to iterative design.

First, there should be a refactoring step in every iteration. This allows space for improvements to be implemented so you are not stuck with design decisions that the team has outgrown.

Second, the team should be building with an architecture that is as decoupled as possible. This allows for almost any design decision to be undone. This may seen inefficient (and strictly speaking, it is) but if the team is releasing frequently and getting constant value out of their application, then the value from the earlier design should have more than paid for the refactor. If it doesn't, that's a great topic for the team to discuss and improve upon.

Third, each design should be of good quality and viable in its context. That is to say that the team shouldn't be cutting corners to get to fast releases, just using simple, but still solid, designs for their early iterations.

Fourth, there is an idea of "last responsible moment" in iterative design and architecture. The team should strive to put off all decisions in design until they can't any longer without the delay negatively impacting the application. That's a hard balance to find, but luckily it's usually less of a moment and more of a range.

Finally, it is important to remember that you can't make paradigm shifts incrementally. The team may encounter a point at which they have to completely change some aspect of design. It happens in Scrum, it happens in waterfall. The decoupled architecture should make it less painful, but it will happen. If a team reaches that point, they shouldn't avoid doing the change just because it isn't incremental. Hope this helps.

Answer 3

This scenario is encountered commonly in a software QA company. Below are some of the points to avoid such situations.

1. As a tester, you can involve with design team at the stage of initiation of making of designs and can share your inputs before the designs are presented to the product management team.
2. In case of responsive application designs, you can check the feasibility of the updated designs for which the feedback are implemented.

These approaches can help you save time, effort and money while releasing the product and will result in a timely release.

Answer 4

By getting feedback to guide the Design

Design is the last D in TDD and BDD

From customers, what's working, what do they like ?

From automation and tools, what's working, what's broken ?

From developers, what is robust yet easy to change, what is not ?