5

In our organaziton to make the testing process a QA can start the QA process by deploying a feature branch to a QA machine. My question is that while doing so should the build process include running the integration/smoke tests as well or can we skip that.

This makes the build fast and makes it easy for anyone to get the executable for demonstrations, exploratory testing, or just to see what changed last week. I think the build taken from release branch should mandate the inclusion for IT tests and code coverage.

Thoughts??

3 Answers3

3

You should not be running integration/smoke tests ever time you build.

You should not be deploying to a QA machine without passing their basic tests.

You should not expect passing their tests to take more than a few minutes.

Smoke tests are supposed to be non exhaustive. If they are burdensome don't just ignore them. Work with QA to make them fast and targeted.

The point of QA is to think of things the programmers don't and to see things from a perspective that the programmers don't have: The users perspective.

Don't expect them to think of the code the same way you do. But be sure everything that can be done is done to automate every test and that the right ones are run at the right time.

candied_orange
  • 119,268
2

Yes. The tests should run on any build that QA is going to test. Testing a failing build is likely a waste of their time, so they should know that the branch is known to broken. I wouldn't normally recommend running the build on arbitrary branches, but if QA is going to be testing arbitrary branches, then so be it.

RubberDuck
  • 9,021
0

Adding my answer as it differs from the current other answer.

If the existing coverage of unit tests is far lesser than integration or unit-test coverage is negligible then I would NOT disable integration testing.

Even the exploratory work should have some quality check gates.