How to fit regression testing in sprint?

Wouldn't the observation of a release-quality Definition of Done, each and every Sprint, be a wiser convention to have?

Why start new work before existing work in progress is finished?

Have you made the existence and impact of the technical debt visible? If not, that is a good first step. Make sure that the stakeholders are aware that there are issues that, if not addressed, will have a detrimental impact on product quality and development speed. Once the technical debt and its impact is visible, there needs to be an effort to pay the debts down.

In the meantime, though, the impact of the technical debt needs to be accounted for when performing Product Backlog refinement, Sprint Planning, and throughout the Sprint. When you are managing the Product Backlog - decomposing the work, identifying dependencies, estimating, and ordering - you need to be aware of which Product Backlog items may be impacted by the tech debt and consider the necessary regression testing when doing this work. Once you're in Sprint Planning, you also need to consider the impact of the tech debt on the team's ability to get work to a Done state. This probably means performing some level of regression testing and getting feedback to the development team within the Sprint.

If you do these things, you will see a decrease in the amount of work that you can do in the Sprint. However, that's normal. Technical debt, by its very nature, is something that slows the team down. Unless you invest the time to resolve those issues, the amount of deliverable value will be lower. Having clear and visible descriptions of deliverable work items to pay down technical debt will be greatly valuable in explaining the difficulty in delivering value.

Hi @Ian Mitchell

The team is made up of developers and QA members, so inevitably there is work in sequence to be done. Developers code, QA members test and approve the pull request. After all, when the sprint is "finished", the regressive starts. However, the regression is performed only by QA members. Assuming that regression testing would be included in the DoD, how would that look in practice? Would developers also participate in the regression? Otherwise, will they be in standby?

The entire Scrum Team is responsible for creating and delivering a potentially releasable product increment during the Sprint.  You are purposely not doing that since the regression tests are required in order to determine that state.  Your statement of 

However, the regression is performed only by QA members. 

could be the root of your problem.  Why can't the Developers participate in this activity? It could possibly bring the 2 day effort into 1 day and make it possible for you to do it during the Sprint.  However, waiting until the last days of the Sprint will still not allow you time to address any issues that need to be fixed in order to release.

I point out that the goal is to have a potentially releasable product increment. There is nothing that says there can't be additional work needed to make it actually releasable. How your organization decides to handle that work is up to you to decide.  You might want to look at some of the topics in this forum related to User Acceptance Testing for ideas. 

"so inevitably there is work in sequence to be done".

Imagine it IS evitable. How can it look like ?

First of all I would like to thank all the comments. The company is open to taking the necessary steps to implement Scrum in its essence, and C-Level is open to any suggestions, which is already great, but the point is that I don't know the solution to all the problems or what would be best practices to be implemented.

Returning to the subject, here we go:

Daniel Wilhite, the point you raised is interesting. I understand that perhaps the fact that the whole team does not participate in all process is the root of the problems. We have developers of all levels of knowledge, how can they be efficient while performing tasks that were previously performed only by the QA team? And what will the QA team do while the coding step is finished? None of them have developer skills.

Olivier Ledru, I imagine that to solve the problem the team should be composed only of members who have all the skills necessary to perform all the work, but is this real? I do not think so. Multidisciplinarity is necessary and will result in people with specialized knowledge and work inevitably being sequenced.

We have developers of all levels of knowledge, how can they be efficient while performing tasks that were previously performed only by the QA team? And what will the QA team do while the coding step is finished? None of them have developer skills.

Think along these lines.  How can someone that doesn't normally make coffee become as proficient as those that make coffee every day?  I suggest that attempting to make coffee is a learning opportunity.  And asking questions of the those people that make coffee every day and have them explain/show you the process will make your more proficient. No one can learn anything unless they try.  

What can QA do during the coding?  How about test?  How about help developers what needs to be tested?  How about spending time reviewing the Product Backlog providing comments and asking questions that can help the rest of the team understand validation needs or techniques. How about doing code reviews with the perspective of test coverage?  For example if a lot of code is introduced with no unit/component/integration tests should that work be considered complete? If there were significant lines of code modified but no tests were impacted, could the be work remaining? 

Think less about assuring quality and have the team think more about ensuring quality.  

And what will the QA team do while the coding step is finished?

Does this even matter if the overall result is an improvement?

Imagine you have a small town, and the local fire brigade are responsible for putting out fires.

This town's biggest employer is a waste disposal plant. This plant isn't particularly efficient. It basically just piles up all the wood and paper that comes in each day, and burns it. This regularly gets out of hand, and the few fire officers in this town are permanently on hand to help damp down the fires, every time they start to get out of control.

No-one in the plant sees a problem. They keep doing their jobs, starting fires as needed, and getting results (the wood is removed, after all). The fire brigade are busy, and putting out a lot of fires, so they feel successful too.

Then imagine the fire brigade give the staff at that plant access to a hose, and enough basic training to deal with small, simple fires. The fire brigade are still there to help, if needed; but now they don't have to be watching the fire 100% of the time.

The staff know the fire brigade will be there in minutes if they're actually needed, and the fire brigade can move on to educating people on how to prevent dangerous fires, or looking at trends associated with those fires (like how the most dangerous ones came from when the wood was piled above a certain height), or they can study more advanced fire fighting and prevention techniques.

Eventually the fire brigade can reduce the overwhelming majority of their job to providing advice, and only helping out in a hands-on way during real emergencies.

Wouldn't you pay just as much to have a town with zero fires, as to have one with a fire brigade that are always busy putting them out?

And that's possibly more representative of a real fire brigade. They are almost always available to respond, because they're usually not needed; and this means they can add even more value, because no-one has to wait when they really do have to step in.

So to take it back to the QAs, is it such a bad thing if they're not always busy? What would a less busy QA be able to achieve if they have enough free time to go where they think they can make the biggest impact, and they can focus on maximizing the effectiveness of others?

How amazing do you think these people would be at their jobs if they could spend a chunk of their time reading and gaining new skills, and also having enough time to focus on underlying problems, bringing out the best in others, and removing inefficiency from the system?

Manual executing regression test suites will become a problem quit fast with each new increment and from what I'm reading I'm coming to the conclusion that you haven't automated any tests.



You need to go follow two paths:

1) start covering new code (new functionality and rework of lecagy code) with unit tests by your developers. This will become a great aid with every build over time.

2) Start automating your functional tests into regression suites. Technology wise you can automate everything from webpages with Selenium Webdriver to Webforms in a double Citrix set-up with UiPath RPA and so much more...

It could be that you will have to convince senior management to work with a temporary test automation professionals, but in that case verify that the technology framework stays in your company, test automation standards must be respected and your company needs to attract new internal test automation specialist for taking over the test automation framework