2

I have <5 years experience in the software industry and this is my first time doing QA.

Before the stories in a sprint move to UAT, I am supposed to retest every single story in ~1 day in an environment between QA and UAT.

The purpose is that multiple teams have their own QA environment where they exclusively test their features. The extra environment is to make sure features developed by separate teams don't interfere with each other.

This expectation seems surprising to me. I suppose this isn't technically an entire sprints worth of work, since test cases have already been written, but it still seems like a lot for one or two days.

Is this normal/reasonable/typical for an agile project?

Improve this question
3
  • 3
    This is what CI servers are for.
    – Robert Harvey
    Commented Jan 17, 2019 at 18:10
  • 2
    In my opinion it doesn't what is considered "normal" for a project. The whole point of agile software development is that it's a collaborative effort with process improvements along the way. If you don't feel you have enough time to do what is asked of you, then bring it up with your team so a solution can be found. A good team will listen and make changes to help everyone succeed.
    – Dan Wilson
    Commented Jan 17, 2019 at 18:12
  • yes this is normal. automatr your tests
    – Ewan
    Commented Jan 17, 2019 at 20:03

2 Answers 2

Reset to default
4

In Scrum, every sprint ends in a potentially shippable product. If regression testing is needed for a particular build to be releasable from a technical standpoint, then the answer to your question is yes. You will actually have to test much more than what you have said. There might be another solution, but the only way I've ever known to handle this is robust automated testing strategies.

Improve this answer
3

It's hard to answer "what is typical" because there are different types of customers who have their own demands on how software is deployed in their systems. There is a gamut of what happens from companies that maintain and deploy their own software (like Netflix, AirBnB, Stack Exchange, etc.) to companies that require hand-off to third parties to deploy.

The idea behind Agile is that you can deploy as needed. DevOps expands on that idea and automates deployments and testing processes as much as possible. Taken to the full implementation, DevOps will push changes live once they have been promoted.

I work in an industry where we have to deploy on private networks, which means we can't really automate everything. In our situation, we do something like this:

  • Development is done on feature branches and a pull request is made when it is complete
  • Every change to the develop stream causes our CI server to build and deploy the software to test servers
  • Automated tests run against that instance, followed by manual testing
  • We deploy on staging servers in the customer network
  • Customer performs UVT (User Verification Testing), only different from UAT in the sense that users can't stop a release
  • Finally install instructions are provided to a 3rd party to perform the installation in production and there are formal meetings to approve that action.

Up to the point where we deploy on staging servers, we use DevOps to ensure the product is correct and we haven't regressed in any critical functionality. However, we do find things that only exist in the customer network when we deploy there. For that reason, we have to manually perform a full regression test for our customer.

You'll find that the additional testing is required when you don't have full control over the deployment environment. That's less common in the commercial world, and more common where the industry or customer is more conservative.

Improve this answer

Your Answer

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

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