Effort Estimation

Estimates is considered to be difficult/challenging as most of the time estimate is requested so early in the project you might not even know how much information to provide a close to accurate estimate. In-order to provide a decent estimate below mentioned information is considered.

Factors for Estimation

Market opportunity

• Who the competition is?
• What is the opportunity now and in the future?

Contractual terms

• Are there penalty clauses?
• Is it phase wise delivery?
• Volatility of requirements
• How standard is the requirement?
• What could be the change in requirements over time?

Past Experience

• Have we had a better or bitter experience?
• Have we delivered something similar in the past?

Skill Set

• Talent pool of engineers and the expectations of the project
• In house training capability
• Ability to learn quickly
• Ability to ramp up
• Can we ramp up our team in case we win the project?
• Option and flexibility to outsource?

Technology

• Complexity
• Environment –Onsite/Offsite
• Virtual Testing

Estimation Models

What is it?

• Estimation model is the combination of the technique and the factors
• A predefined framework or template
• Adaptable with modifications

Build or use Models?

• Using existing models is a safe bet
• Derive and build your own models

Principle of Estimation for testing projects shall be:

• Based on
• Software requirements
• Previous projects
• Metrics
• Estimation shall
• Never forget the past
• Be recorded
• Be supported by tools
• Be always verified
• Consider automation needs
• Consider people skills
• Other Inputs to consider
• # of test cases/scenarios,
• # test cases per scenario,
• # of builds (for regression)

We also have an old thumb rule for estimation i.e. to complete testing we will take about 30% of Development time. This will not hold good all the time as some time coding for some functionality can be done much faster than the time it takes for testing the functionality.

If at al possible, keep a history of your estimates versus actual. Time and experience are some of the best educators. If you keep track you can gain some useful history.

Software Testing Methods

Software Testing Methods can be broadly classified as Black Box Testing, White Box Testing & Gray Box Testing.

Black Box Testing: In this type of testing , the tester views the program as a black - box, tester doesn't see the code of the program: Equivalence partitioning, Boundary - value analysis, Error guessing are the few which user will consider when testing.

White Box Testing: In this type of testing , the tester examine the internal structure of the program: Statement coverage, Decision coverage, condition coverage, Decision/Condition coverage, Multiple - condition coverage. This to do more with code verification. Usually the development team does this type of testing as many a times QA will not get accessto the code written by the developer.

Gray Box Testing: In this type of testing Black box testing can be combined with knowledge of database validation, such as SQL for database query and adding/loading data sets to confirm functions, as well as query the database to confirm expected result.

Software Testing Documents

Test Plan: The purpose of Test Plan document is to describe the overall test approach for the . The test approach will consist of the scope of the testing that is required for this Project, the activities that need to be completed, the resources required (people, software, hardware), test methodology, general release criteria, and any risks or dependencies for this project.
It should be noted, that test planning is an essential step in the overall software development framework. It sets expectations for the amount of testing (functional, system, and performance) that should occur for a project.

Test Effort Estimation: This document will give the details on how much time will be required for completion of the given Project / Module based on the priority of testcase (Low, Medium, High or Complex). For doing any effort estimation following few things are considered: Requirement Analysis, Testcase Design, Review, Automation/Performance Test, Manual Test Execution, Trainings if any & Project Management/Configuration Management.

Test Strategy: The purpose of a test strategy is to clarify the major tasks and challenges of the test project. Test strategy will consist of the following:
- Understand the decision algorithm and generate a parallel decision analyzer using Perl or Excel that will function as a reference oracle for high volume testing of the app.
- Create a means to generate and apply large numbers of decision scenarios to the product. This will be done either through the use of a GUI test automation system, if practical, or through a special test facility built into the product (if development is able to provide that), or through the direct generation of Decide Right scenario files that would be loaded into the product during test.
- Review the documentation, and the design of the user interface and functionality for its sensitivity to user error that could result in a reasonable misunderstanding of decision parameters, analysis, or suggestions.
- Test with decision scenarios that are near the limit of complexity allowed by the product. (We will investigate creating these scenarios automatically.)
- Compare complex scenarios (Automatically, if practical). - Test the product for the risk of silent failures or corruptions in the decision analysis.
- Using requirements documentation, user documentation, or by exploring the product, we will create an outline of product elements and use that to guide user-level capability and reliability testing of the product.

The principal issues in executing the test strategy are as follows:
- The difficulty of understanding and simulating the decision algorithm.
- The risk of coincidental failure of both the simulation and the product.
- The difficulty of automating decision tests.

Test Case: This document will contain the steps to be followed to achieve its objective. In a testcase document we will give the testcase Name, the steps to be followed, Test data, Expected and Actual results, Pass/Fail and remarks. We also specify the testcase version number and the author.

Software Testing

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality.