Test progress monitoring
The purpose of test monitoring is to give feedback and visibility about test activities. Information to be monitored may be collected manually or automatically and may be used to measure exit criteria, such as coverage. Metrics may also be used to assess progress against the planned schedule and budget.

Common test metrics include:

• Percentage of work done in test case preparation (or percentage of planned test cases prepared).
• Percentage of work done in test environment preparation.
• Test case execution (e.g. number of test cases run/not run, and test cases passed/failed).
• Defect information (e.g. defect density, defects found and fixed, failure rate, and retest results).
• Test coverage of requirements, risks or code.
• Subjective confidence of testers in the product.
• Dates of test milestones.
• Testing costs, including the cost compared to the benefit of finding the next defect or to run the next test.

Test Reporting
Test reporting is concerned with summarizing information about the testing endeavour, including:

• What happened during a period of testing, such as dates when exit criteria were met.
• Analyzed information and metrics to support recommendations and decisions about future actions, such as an assessment of defects remaining, the economic benefit of continued testing, outstanding risks, and the level of confidence in tested software.The outline of a test summary report is given in ‘Standard for Software Test Documentation’ (IEEE 829).

Metrics should be collected during and at the end of a test level in order to assess:

• The adequacy of the test objectives for that test level.
• The adequacy of the test approaches taken.
• The effectiveness of the testing with respect to its objectives.

Test control
Test control describes any guiding or corrective actions taken as a result of information and metrics gathered and reported. Actions may cover any test activity and may affect any other software life cycle activity or task.
Examples of test control actions are:

• Making decisions based on information from test monitoring.
• Re-prioritize tests when an identified risk occurs (e.g. software delivered late).
• Change the test schedule due to availability of a test environment.
• Set an entry criterion requiring fixes to have been retested (confirmation tested) by a developerbefore accepting them into a build.

Exposing systems to the internet increases the risk that security weaknesses in those systems will be leveraged to compromise the system or the underlying data. It is therefore necessary to examine the actual business risks this brings, understand the basic difficulties in implementing “secure systems”, and adequately test internet applications for security, as well as functionality and load performance, before they are exposed to the net.

Click Here to Download the Whitepaper. ( via @ appLabs)
Security Testing Fundamentals –

by – Ranjit Shewale jcrvs@hotmail.com
Summary
This article describes about the approach to reduce documentation and correction overhead of test cases for the test team so they can spend more time on creating
innovative test cases and actual testing. This also leads to a structured documentation approach of test case during the test case preparation phase.

Ask yourself
1. How much time does your team spend in documenting test case?
2. How much time do you spend in internal reviews?
3. How much time do you spend in correcting it?
4. How much time do you spend in correcting the test cases if the client sends across the review comments prior to signing it off?
If the answer to above is ‘most of the time’, then you need a structured approach to test documentation.
Why would you want to save the time?
Reducing Test Case Documentation Time