Triaged Tester

March 16, 2009

Test Activities during phases

Filed under: Black Box Testing,Checklist,General,Guidelines,Test Plan,Tips — Triaged Tester @ 8:51 am
Tags: ,

Test activities vary with the model and also on the type of project. So here is a generic list of items that needs to be done. You can always do it at any point when enough data is available.

1. Requirement Phase :

  • Invest in analysis at the begining of the project
  • Start developing the test set at the requirement analysis phase
  • The correctness, consistency and completeness of the requirements should be analysed.

2. Design Phase :

  • Analysis of design to check its completeness and consistency
  • Analysis of design to check whether it satisfies the requirements
  • Generation of test data based on design
  • Setting up of test bed

3. Programming/Coding Phase :

  • Check code for consistency with design
  • Perform system testing in an organized manner – Buddy testing, feature testing, integration testing, System testing etc
  • Use available tools
  • Apply stress to the program
  • Test one at a time
  • Measure test coovergae

4. Maintanence Phase :

  • Retest/Regress
Advertisements

March 9, 2009

Recommended tools

Filed under: Automation,Checklist,Guidelines,Tips,Tool — Triaged Tester @ 1:23 pm
Tags: ,
Functionality Description Representative Tools
Functional Testing Record and Playback tools with scripting support aid in automating the functional testing of online applications  Win Runner, Rational Robot, Silk Test and QA Run. Tools like CA-Verify can be used in the m/f environment
Test Management  Management the test effort  Test Director
Test Coverage Analyzer Reports from the tool provide data on coverage per unit like Function, Program, and Application Rational Pure Coverage 
File Comparators  Verify regression test results (by comparison of results from original and changed applications). Comparex (from Sterling Software)
Load Testing  Performance and scalability testing Load Runner, Performance Studio, Silk Performer and QA Load
Run-time error checking Detect hard to find run-time errors, memory leaks, etc. Rational Purify
Debugging tools  Simplify isolation and fixing of errors Xpediter,  ViaSoft (Mainframe applications), VisualAge debuggers and many other debuggers that come with development kits. 
Test Bed Generator Tools aid in preparing test data by analyzing program flows and conditional statements CA-Datamacs

March 5, 2009

% of Dev effort for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:21 pm
Tags: ,

Some organizations utilize a quick estimation method for testing based on the estimated programming effort. For example, if a project is estimated to require 1000 hours of programming effort, and the organization normally finds that a 40% ratio for testing is appropriate, then an estimate of 400 hours for testing would be used. This approach may or may not be useful depending on the project-to-project variations in risk, personnel, types of applications, levels of complexity, etc.

March 3, 2009

Iterative approach for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:18 pm
Tags: ,

In this approach for large test efforts, an initial rough testing estimate is made. Once testing begins, a more refined estimate is made after a small percentage (e.g., 1%) of the first estimate’s work is done. At this point testers have obtained additional test project knowledge and a better understanding of issues, general software quality, and risk. Test plans and schedules can be re-factored if necessary and a new estimate provided. Then a yet-more-refined estimate is made after a somewhat larger percentage (e.g., 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate

March 2, 2009

Test work breakdown approach for test estimation

Filed under: Estimation,Guidelines,Metrics,Test Management — Triaged Tester @ 1:16 pm
Tags: ,

Another common approach is to decompose the expected testing tasks into a collection of small tasks for which estimates can, at least in theory, be made with reasonable accuracy. This of course assumes that an accurate and predictable breakdown of testing tasks and their estimated effort is feasible. In many large projects, this is not the case. For example, if a large number of bugs are being found in a project, this will add to the time required for testing, retesting, bug analysis and reporting. It will also add to the time required for development, and if development schedules and efforts do not go as planned, this will further impact testing

Next Page »

Create a free website or blog at WordPress.com.