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??

Rohit Kumar
  • 159
  • 2
  • 3
    This depends 100% on the product you are developing, the test suite, and your organization. For some products/tests/organization it may make sense, for others not. Why do you ask strangers on the internet instead of your team or your superiors? – Doc Brown Dec 19 '16 at 14:38
  • No, it's not mandatory. But, it would be cool to have. If your organization can automate both smoke testing and feature level testing after a deployment, then someday you may be able to promote code up the food chain without the need for human testing/invention. To get to that point is not easy as one will need a comprehensive test and automation suite. You will probably need a full time dedicated "systems team" whose sole responsibility is keeping the automation framework up to date. – Jon Raynor Dec 19 '16 at 15:22
  • 1
    Why waste time QAing code that fails automated testing? – Sean McSomething Dec 19 '16 at 16:31
  • FWIW: is your automated integration test so slow that it seems to be worth to skip it and start with manual testing first or in parallel? Really? – Doc Brown Dec 19 '16 at 17:45

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
  • 102,279
  • 24
  • 197
  • 315
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
  • 8,911
  • 5
  • 35
  • 44
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.

Ajeet Ganga
  • 263
  • 1
  • 5