5

Could you, please, share your experience on test processes on your project.

  • Do you have code freeze for the test team to retest all the stories, that were made during the sprint, on the end of a sprint in order to start smoke and regression testing?

  • Or you have a solid E2E, API (on default unit, integration) test coverage of those tasks that were made during the sprint and on the end of the sprint you have quick code delivery to release candidate whereupon all levels of tests passed give you that level of confidence in build that test team starts regression testing immediately. (In our case it's in Stage environment)

We have 3 envs: dev -> stage -> prod

Improve this question

1 Answer 1

Reset to default
2

First, it's good to remember the agile principle of self-organizing teams - additionally, the context-driven testing principles of "best practices do not exist". It means any previous experience, from you or other people, must always be "re-validated" through experimentation within your current context.

Being said, I will just raise some things that may happen:

Do you have code freeze for the test team to retest all the stories...

It will depend on the risks of the changes. The team (not only testers) has to evaluate the impact that the changes may have and the need to re-evaluate "all stories".

smoke and regression testing

These are techniques, and must be used for reaching the right goals. Smoke tests are usually quick and low-cost, done on every story and automated somehow - so, rarely you would need to re-do them, because the information is low-risk. Regression testing is misunderstood very often - it does not mean re-test the whole system, but to look for bugs created by side-effects of changes in other components: It's a risk-based technique; therefore, should not be used blindly or periodically, but in the context of the changes.

you have a solid E2E, API...

Automated checks created during the development (especially when created as guides for development) are great tools for improving internal and external quality. Again, the details on what is to be automated will depend on the context: People involved and the goal of the project.

We have 3 envs: dev -> stage -> prod

Ensuring that everyone on the team understands the flows, and it's able to perform changes in the environments is very important. E.g., keeping testers idle because people are waiting a pull request on the master branch is not necessary. Give them the ability to get a commit hash, build it and deploy locally on their machines or on the stage/dev environments - the ability to run migration back and forth, and so on. Create the trust that they are able to understand the context of the project and that this kind of action is necessary for developing the best product as fast as possible.

Improve this answer
2
  • Hey Joao, thanks for your comment. I wondered why so few colleagues joined this topic. 1) We implemented the code freeze only for one specific purpose - to deliver clearer code to stage env. where (1.all the stories that have been made during this sprint are still working and not broken on the last or any another day of a sprint, 2.critical functionality is working properly(smoke testing)) 2) In STG we conduct again smoke testing and then if ok - regression testing (full) after pushing to prd, basing on risk analysis we conduct partial regression testing.
    – Alexander Tunick
    Dec 25, 2018 at 13:22
  • So the devs can't push any new commits to dev only about 2-3 hours in the end of a sprint. With automating all of these it will take for 20-30 minuites
    – Alexander Tunick
    Dec 25, 2018 at 13:25

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.