0

If you found a major bug on the last day of a Sprint, what should you do? Can you change the length of the sprint which is already decided?

This question was asked me in an interview. What should be the expected answer to this question?

Improve this question
1

5 Answers 5

Reset to default
2

You communicate about the problem to whomever is of interest. Like... any other bug.

Sprints are a Scrum concept, nothing to do with testing.

Improve this answer
1

No. We will not change the length of the sprint

  • For any bug/un-expected task, its not recommended & general practice in agile methodology to increase the length of the sprint
  • If you found major bug on the last day of the sprint:
  • This is day to day scenario, but tag major bug suffice nothing
  • Being QA, I will start with filing the bug and assign to concern person with max details I can (Title, Description with Steps to reproduce, Platform, Build version, System details where I observed behaviour, Occurrence, Logs, Screenshots if req., Link with Feature/Parent ticket etc)
  • QA Lead/ Manager/Scrum master i.e. responsible person with authority will analyse the impact of the bug
  • After impact analysis, If found blocker team & concern developer will work on it in order to resolve/fix on priority
  • Being QA we can help in impact analysis & to developer by providing more information. Even helping them & check our other areas if impacted
  • Based on Severity (Severity is basically a parameter that denotes the total impact of a given defect on any software) and Priority (Priority is basically a parameter that decides the order in which we should fix the defects) Manager/Scrum master or responsible authority will take decision about when to deploy to production, provided its having impact huge on live users
  • Will contribute again after fixing the bug on various environments available
  • After testing resolved bug + all scenarios around the bug will flag according to the results of testing
Improve this answer
0

Interviewing is a skill like anything else. You want to keep in mind that interviewers keep questions vague on purpose because they want to know how you think. An interview shouldn't just be you getting question after question and you providing answers. The best interviews are a conversation.

This question is a good opportunity for you to ask clarifying questions and get a conversation going.

  • They mentioned a "major bug." What does "major" mean to them?
  • They mention a generic bug. You can ask them more about the specifics of the bug: Who is affected by it? What's the impact of the bug? Get them to explain the priority and severity.
  • What happens on the last day of the sprint? Is the dev team expected to deploy the work?
  • Does the team practice CI/CD and deploy any day of the week?
  • Is it possible to allow the feature ticket or bug ticket to just roll over to the next sprint?
  • Does every ticket in the sprint need to be completed by end of the sprint?
  • Is it ok to deploy a bug to production and to a fast follow-up tomorrow?
  • Can we deploy the bug to production behind a feature flag?
  • Does QA have the ability to provide the go/no-go for deployments?
  • How does the team triage bugs?

It's also a good time to explain how you work and explain your own knowledge.

  • Explain how bug priority and severity work and how they differ. Ask if this team has any definitions of priority/severity they work with. This turns the question back on them to explain what "major" means.
  • Explain a time in your work history when this situation has come up before. How did your previous team handle it? This is where learning the STAR method of answering questions helps.
  • Explain how you have triaged bugs in the past.
  • How do you alert the team about a "show-stopping," high priority/high severity bug?

Keep in mind that sprint start/end dates are arbitrary; they provide a nice boundary around work. I've been on many teams where we had tickets left over and they just rolled over to the next sprint.

This isn't an exhaustive list. Hopefully, this gives you a good idea of how to answer it in the future.

Improve this answer
0

As a QA, it is important to report the bug as soon as it is discovered. If a major bug is found on the last day of a Sprint, the following actions should be taken:

  1. Prioritize the bug: Determine the severity of the bug and whether it affects the functionality of the application or not.

  2. Notify the development team: Inform the development team immediately about the bug and the urgency to fix it.

  3. Provide details about the bug: Supply the development team with as much detail about the bug as possible, including steps to reproduce the issue, and any relevant screenshots or videos.

  4. Discuss the impact on the Sprint: Once the development team is aware of the bug, have a discussion about the impact of fixing the bug on the existing sprint plan.

  5. Determine the best course of action: Based on the impact, determine the best course of action, which can be continuing the sprint with a reduced scope, extending the sprint length, or reassigning some work to another sprint.

  6. Re-evaluate the sprint plan: If the sprint length is changed, the sprint plan should be re-evaluated, and the stakeholders should be informed of the revised timeline.

In conclusion, the goal is to balance the need to deliver a quality product with the constraints of the sprint timeline. Communication and collaboration between the QA and development team are key to finding the best solution.

Improve this answer
0

I have been associated with an outsourced software testing company for more than nine years, and this is a crucial stage at the end of Sprint.

In case an issue is encountered on the last day of the sprint then, following actions can be performed as per the current QA processes we follow in our organization:

  • The QA team should notify the stakeholders, like the scrum master and product team, regarding the issue.
  • For better tracking, a defect should be reported with all the details.
  • Fixing of the issue should be prioritized based on the severity and impact assessed by stakeholders.
  • If it is a blocker, then it should be fixed by the developer on priority.
  • According to the severity of the issue, the inclusion of the fixes in the production deployment can be decided by the stakeholders
  • Either defect can be fixed and tested thoroughly before shipping to production - OR - it can be hot-fixed later after the release.
  • Once bug fixes are available, QA should validate the fixes and also ensure that they test the related areas for any regression issues
  • For future releases, the QA team should create a test case for the above issue and include it during every release cycle.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.