goksn

 Profile Answers by goksn 

• Sep 23rd, 2009

 

Generally the conditions will be specified in test plan under the section 'Entry criteria'.

The conditions most probably will be in the form of smoke test suit - which comprises a small set of test cases which tests basic functionalities in order to find 'show stopper'.

If smoke test suit passes, then entry criteria is satisfied and the build is ready for testing.

Sometimes, certain non-functional criteria may also be used.Sometimes, certain important bug refix will be the entry criteria-everything depends on context.

StevenPace

 Profile Answers by StevenPace 

• Sep 26th, 2009

 

A smoke test suite is attempting to determine if the build is worth testing.  Some things that probably should be considered:

1. Are there bugs in this build that severly interfere with the testing effort?
2. Has there been a major revision that is absolutely necessary for the viability of the finished product.  Or put another way, is the current build appear to be much closer to the finished product?
3. How does this current build compare to the previous build (the one you are currently testing).
4. Are there important bug fixes that need to be varified.

srinivasulub1981

 Profile Answers by srinivasulub1981 Questions by srinivasulub1981

• Nov 25th, 2009

 

HI

We are having our own standards of rejecting a build for testing, by receiving the build first we will do the smoke testing, if we found issues  then we will reject the build as per below conditions..


-> 1 critical issue for 8 hrs task : If devs developer a new funtionality, and QA team founds one critical issue, then QA team can reject the build.

-> 2 major issues for 8 hrs task: If devs developer a new funtionality, and QA team founds 2 major ssues, then QA team can reject the build.

-> 3 medium issues for 8 hrs task: If devs developer a new funtionality, and QA team founds 3 medium ssues, then QA team can reject the build.

-> 4 minor issues for 8 hrs task: If devs developer a new funtionality, and QA team founds 4 minor ssues, then QA team can reject the build.


CNU

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Dec 5th, 2009

 

REASONS TO REJECT A BUILD

SCENARIO 1:
A test team may reject a build when its Entrance Criteria have not been met.  In order to make this work, the Entrance Criteria must have been defined and agreed upon by all relevant stakeholders.  The Entrance Criteria should be a standard that applies to all builds and for all products.  It is often described in the Test Plan.  Entrance Criteria may include:

1) Turnover documentation is complete and submitted to test
2) All unit testing has been successfully completed
3) All expected software components have been staged
4) All walkthroughs and inspections are complete
5) Change requests have been updated to correct status
6) Configuration management and build information is correct and delivered to test

SCENARIO 2:
A test team may also estabish a set of Build Verification Tests (BVTs) that are run to ensure that the build is stable and major functionalities are working properly.  In order to run BVTs, the test team must have consensus with appropriate stakeholders (Project Manager, Development Manager or Lead) that they will reject a build if any one of these tests fail.

SCENARIO 3:
In this case, the test team runs a cursory set of tests (Sanity Tests, Minimum Acceptance Tests, Basic Acceptance Tests) to ensure it is suitable for testing and discovers that a particular functionality that should have been fixed still exists in the application. Upon further investigation, it turns out that the build contains files from previous versions. In this case, there is no point of further testing until the versioning issues are corrected.

gouri_suda

 Profile Answers by gouri_suda Questions by gouri_suda

• Sep 24th, 2010

 

For rejecting the initial build,

As a tester we can reject the initial build, if the
received build is unstable interns of basic functionalities like
1) Ease of use 2) operatable 3) maintainable 4)
compatible 5) look and feel

Nothing but Smoke testing fails.
Due to delays in schedules

• Oct 14th, 2011

 

Reasons..reasons..

1. Smoke tests fail. These tests are already listed in the test plan, if not come up with the most important and common transactions performed by users.
2. Release notes is not provided. As a tester, you must know which bugs were fixed/ new features added by dev in each build. in my current company we do not touch the build if dev team does not provide us release notes.
3. Requirements changed just before the build (oh Yes! this does happen in Agile environment)
4. Unrealistic deadlines (I did reject build on few occasions for this reason)
5. Critical defect is still unfixed in the new build