Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
The QA manager in our organization is demanding that our dev team, which I am the manager of, do the smoke testing after we set up the testing environment and before the QA team begins testing, i.e. he wants us to sign off on the environment and to say that it is stable enough for testing.
I was wondering if this is a common practice in many organizations. If not, what are the more common practices.
I cannot speak for the industry in general, but at places I have worked, developer-initiated smoke-testing is a common practice if builds delivered to QA tend to be unreliable.
I had a job as a test lead on a team that required developers to smoke-test the builds. At first it was a painful process, taking up most of a developer's time for an entire morning. Eventually we automated the deployment and wrote some automated smoke tests. That freed up some developer time while giving the QA team an indication of whether testing the latest build was a good use of their time.
The "developers do the smoke tests" policy forced developers to pay more attention to the quality of the code they were checking in, which of course was the whole point. Over time, the build quality improved and the smoke test became less necessary.
m not happy with my team doing what they (and I) consider QAs work, but I now understand the benefit.
Apr 14, 2015 at 17:29
The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as "infinite defects methodology" Source, scroll to #5
I agree with @user246 and @Niels van Reijmersdal, but it grew longer than comment. :-)
If developers are allowed just "throw code over the wall" to QA, even if basic smoke test will fail in QA environment, they will have no incentive to fix the smoke testing process - and eventually automate most of it.
Goal is not kick the can down the road and make the failure someone else's problem - goal is to make most productive use of the time of every member of the team. If smoke tests fail, developers should be able to find cause faster - so it will be better use of team's time that QA manual testers trying to figure it out.
Sounds reasonable that you deliver an environment which at-least starts. Smoke tests often just consist of a check that the application starts and some basic functions work.
I think its a best practise is to setup a continuous integration environment which:
After step five the QA-team can start working on it.
Get their help to setup the integration and GUI tests that they need for it to be able to start testing on it. I would let the QA-team define the Smoke test and let the Dev team automate it.
Continuous integration server (Jenkins, Teamcity etc.) with unit-tests and automated functional smoke test test run before build is our choice in perfect work flow. And we have some checklist for developers that they should execute before their commit to repository at initial state before we do not have Continuous Integration server.
Where I work, a developer is expected to get their new feature deployed to the Dev environment and make sure that it and the platform are both still functioning at a very basic level. We had a period where quite a lot of new work checked in and deployed to Dev did not work at all, and got pushed straight back pretty much right away. I think that level of smoke testing from devs should be expected, as a handover period of the feature to QA.
The rest should ideally be covered by CI and any new, non covered functionality be picked up by the QA team, once the feature is in a testable state.
This means the Dev on the feature tests a few of the most basic functions of that feature once deployed to Dev to ensure its ready for the QA team to pick up, the Dev should absolutely not be spending much more than about twenty minutes doing this sanity check for most work: once it's deemed the feature is running then QA can pick up from there.
