There is a scenario: In the new sprint there is a card for functionality refactoring in order to increase speed.
If functionality is broken because of code changes then what should I have to test first: the blocker issue or speed test?
There is a scenario: In the new sprint there is a card for functionality refactoring in order to increase speed.
If functionality is broken because of code changes then what should I have to test first: the blocker issue or speed test?
Well, it makes no sense to test speed if the functionality is broken.
First, make sure the blocker issue is solved. That's why it is called a blocker.
The first priority goes to the blocker issue as this is blocking the execution of the functional testing. Even though the requirement is for performance of the application but still we have to focus on functionality of the application.
Once the functionality of the application is fixed then focus on the speed test.
There is a classic choice between functional and non-functional testing priority.
Normally if you cannot afford both you should start with functional testing as this is more important for the business. If main functionality doesn't work it doesn't make a lot of sense to check performance and reliability because application is not usable in any way.
However you should be able to kill 2 birds with one stone as well behaved performance tests can be used for checking the functionality given you run them with 1 thread (virtual user)
Functionality first probably makes the most sense, because in most situations even if the application is slow it is more valuable if it is working on a functional level.
I would first test the thing that has the most uncertainty or is the most complex to start with. This so we get quick learnings. So maybe start with setting up performance tests, run the easy functionaly tests and then repeat the load-test.
It's worth considering risk here - at a simple level, what's the risk that the functionality is broken by the code changes versus the risk that the speed change is not effective?
In general, I'd say that the risk of broken functionality is going to be higher, and so worth testing first, over performance improvements.