The V-Concept of Testing - The various steps involved in V-concept are listed below:

Step 4: Test Software DesignThis step tests both external and internal design primarily through verification techniques. The testers are concerned that the design will achieve the objectives of the requirements, as well as the design being effective and efficient on the designated hardware.Step 5: Program (Build) Phase TestingThe method chosen to build the software from the internal design document will determine the type and extensiveness of tests needed. As the construction becomes more automated, less testing will be required during this phase. However, if software is constructed using the waterfall process, it is subject to error and should be verified. Experience has shown that it is significantly cheaper to identify defects during the construction phase, than through dynamic testing during the test execution step.Step 6: Execute and Record ResultsThis involves the testing of code in a dynamic state. The approach, methods, and tools specified in the test plan will be used to validate that the executable code in fact meets the stated software requirements, and the structural specifications of the design.Step 7: Acceptance TestAcceptance testing enables users to evaluate the applicability and usability of the software in performing their day-to-day job functions. This tests what the user believes the software should perform, as opposed to what the documented requirements state the software should perform.

window.google_render_ad();

Step 8: Report Test ResultsTest reporting is a continuous process. It may be both oral and written. It is important that defects and concerns be reported to the appropriate parties as early as possible, so that corrections can be made at the lowest possible cost.Step 9: The Software InstallationOnce the test team has confirmed that the software is ready for production use, the ability to execute that software in a production environment should be tested. This tests the interface to operating software, related software, and operating procedures.Step 10: Test Software ChangesWhile this is shown as Step 10, in the context of performing maintenance after the software is implemented, the concept is also applicable to changes throughout the implementation process. Whenever requirements change, the test plan must change, and the impact of that change on software systems must be tested and evaluated.Step 11: Evaluate Test EffectivenessTesting improvement can best be achieved by evaluating the effectiveness of testing at the end of each software test assignment. While this assessment is primarily performed by the testers, it should involve the developers, users of the software, and quality assurance professionals if the function exists in the IT organization.

The V-Concept of Testing - Points to Ponder on Agile

1.Cost/Schedule Impact – Agile does NOT have a cost/schedule advantage over a typical waterfall model, assuming that the requirements remain stable over the duration of the project. Where Agile makes a difference is Iterative development addresses the impact of changing requirements far better than waterfall. Reduces the risk of severe defects during customer review by having multiple iterations and getting continuous feedback from the customer. Continuous integration and validation mean that defect fixes and minor requirement changes during development can be accommodated within the iteration. 2. Iterative Development – Split the dev phase into multiple iterations, depending on the total effort and risk of application Given our resource situation, iterations should ideally not be more than 8-12 weeks The first iteration while focusing on the framework and infrastructure components should include at least some UI intensive scenarios, to facilitate early feedback from the client.3. Development focus Test-driven design and programming – Agile depends heavily on the premise that the developed code is well-tested. The programmers should write code that is easily testable from an object oriented perspective. Automated and Complete Unit Testing – Code coming out of the developer’s workshop should have undergone complete unit testing amounting to 100% of achievable code coverage (who certifies this?). Emphasis is also put on an automated unit test framework, so that multiple iterations can be executed with minimal additional effort. Whenever a new code unit is tested, test previously released units as a sort of regression. Pair Programming – Can be explored based on cost & availability of skilled resources.
4. Continuous Integration Frequent incremental integration as opposed to big bang integration.i. Eliminates high risk integration issues which may lie hidden till the end in a big bang integration scenarioii. Quick turn around time for integration defects – dev or testing is not held up for long periods. Unit Tested Code – Only 100% unit tested code qualifies for continuous integration. Any integration issues should NOT be due to code defects missed during unit testing Frequency – Varies depending on the maturity of team, complexity of requirements, % of UI component in application etc. In our scenario, the recommended target would be at least two integrations a week, after the initial build on the integration box. Validation – Each of the cone integrations shall be smoke tested, and milestones shall be system tested.

window.google_render_ad();

5. Integration Team – A small team of developers will work closely with QA for managing the continuous integration process, and for test support. The responsibilities of the team will be Controlling the contents of each integration Sorting out integration issues Fixing defects found during testing.6. Testing – Agile relies heavily on “nipping defects in the bud”. Agile does not define a single, intensive integration testing phase, for the simple reason that there is no “integration phase”. How do we validate the continuously integrated build then? – Using the system test plan instead, to test minor milestonesi. Milestones – Define milestones that comprise of a small number of related functionalities, which can be tested independently. Ideally the cone integrations and milestones should be planned in such a way that every three or four cone integrations should add up to a milestone.ii. The system test plan for a milestone should be prepared and reviewed at all levels before the milestone is reached.iii. At the end of 2 or 3 milestones, do a full regression of the previous milestones. Defect fixes – Fixes for defects encountered during the system testing should be fixed during the integration for the next milestone, before a lot more functionality gets added on top of the buggy code. This ensures that by the time the application (or the iteration) reaches QA, the number of defects is minimal.
7. QA Involvement – QA Team gets involved from requirements phase itself An experienced QA resource shall be involved during initial requirements gathering and take control of requirement management from the QA side. From the end of the initial requirements phase, the QA plan preparation will go hand in hand with design. The QA plan should be granular in the extreme, containing all of the system or integration test scenarios in detail. QA will be responsible for validation the milestones during continuous integration.8. Team Composition – notes The dev team should aim for at least 50% mix of J2EE resources with quality experience in executing web projects, and usage of tools identified. The QA team should have 50% of its resources well experienced in requirements handling, preparation and management of QA plan from requirements/design, and Agile Testing processes.