Preface: I know that the question may be a bit broad, so I hope it doesn't get closed. However I feel this is a topic that a lot of QA engineers and managers struggle with and I don't think there's only one good way to do something about (like a lot of other topics in our field).

As the question says it, how do you determine that your project's quality has increased over time? What are you using and how do you measure project quality?

Personally, I don't think the number of test cases and number of bugs are a good metric in this case, especially in an Agile (Scrum and Kanban in my case) working organisation. We develop X features across all teams during a 2-weeks-sprint and they get deployed as soon as the testing is completed (not at the end of the sprint). While the bugs coming from support may be relevant as a starting point, the ideal scenarios would be to not get there.

So, how do you assess your project's quality now? How do you know to say about your project that it's in "good quality" shape or in a "bad quality" one?

What do you do, proactively or retroactive, to get, in time, to the desired level of quality and perhaps avoid business loss?

Preface: I know that the question may be a bit broad, so I hope it doesn't get closed. However, I feel this is a topic that a lot of QA engineers and managers struggle with and I don't think there's only one good way to do something about (like a lot of other topics in our field).

As the question says it, how do you determine that your project's quality has increased over time? What are you using and how do you measure project quality?

Personally, I don't think the number of test cases and the number of bugs are a good metric in this case, especially in an Agile (Scrum and Kanban in my case) working organisation. We develop X features across all teams during a 2-weeks-sprint and they get deployed as soon as the testing is completed (not at the end of the sprint). While the bugs coming from support may be relevant as a starting point, the ideal scenarios would be to not get there.

So, how do you assess your project's quality now? How do you know to say about your project that it's in "good quality" shape or in a "bad quality" one?

What do you do, proactively or retroactive, to get, in time, to the desired level of quality and perhaps avoid business loss?

Preface: I know that the question may be a bit broad, so I hope it doesn't get closed. However I feel this is a topic that a lot of QA engineers and managers struggle with and I don't think there's only one good way to do something about (like a lot of other topics in our field).

As the question says it, how do you determine that your project's quality has increased over time? What are you using and how do you measure project quality?

Personally, I don't think the number of test cases and number of bugs are a good metric in this case, especially in an Agile (Scrum and Kanban in my case) working organisation. We develop X features across all teams during a 2-weeks-sprint and they get deployed as soon as the testing is completed (not at the end of the sprint). While the bugs coming from support may be relevant as a starting point, the ideal scenarios would be to not get there.

So, how do you asses your project's quality now? How do you know to say about your project that it's in "good quality" shape or in a "bad quality" one?

What do you do, proactively or retroactive, to get, in time, to the desired level of quality and perhaps avoid business loss?

Preface: I know that the question may be a bit broad, so I hope it doesn't get closed. However I feel this is a topic that a lot of QA engineers and managers struggle with and I don't think there's only one good way to do something about (like a lot of other topics in our field).

As the question says it, how do you determine that your project's quality has increased over time? What are you using and how do you measure project quality?

Personally, I don't think the number of test cases and number of bugs are a good metric in this case, especially in an Agile (Scrum and Kanban in my case) working organisation. We develop X features across all teams during a 2-weeks-sprint and they get deployed as soon as the testing is completed (not at the end of the sprint). While the bugs coming from support may be relevant as a starting point, the ideal scenarios would be to not get there.

So, how do you assess your project's quality now? How do you know to say about your project that it's in "good quality" shape or in a "bad quality" one?

What do you do, proactively or retroactive, to get, in time, to the desired level of quality and perhaps avoid business loss?