Thursday, March 10, 2011

Example of IPV6


Example of IPv6 address:
4FDE:0000:0000:0002:0022:F376:FF3B:AB3F

Whenever you want to give static IPv6 address then change the block# 5 of IPv6 with the last block of IPv4.

If you IPv4 address is : 40.40.40.155 then IPv6 address would be 4FDE:0000:0000:0002:0155:F376:FF3B:AB3F

Thursday, March 3, 2011

Test Summary Report


Test Summary Report
test summary report is a testing work product that formally summarizes the results of all testing on an endeavor.

Why Required?
  • Summarize all of the testing that was performed since the previous test summary report.
  • Enable project management and the customer to know the status of project testing.


Benefits
Project Management and end customer can:
  • Able to get project testing status
  • Able to get application quality status
  • Able to take corrective actions, if required


Guidelines
1.       A Test summary report should generated on regular basis
2.       It should be in metrics, charts and table forms, if possible
3.       Copy of each summary report should maintain until the build release. It can be kept on central location, for future reference
4.       To write  a test summary report, required pre requisites are- test plan should be complete, test execution should occur and respective test reports should be available.

Content of Test Summary Report 
Introduction
  •  Definition
  •  Objective
  • Reference document
  • Target Audience
  • Test Summary
    • Unit Testing Summary
    • Integration Testing Summary
    • System Testing Summary
    • Launch Testing Summary
  • List of Severity One Failures
  • Testing Issues Requiring Resolution
  •  Appendices:
    • TBDs
    • Assumptions

For each kind of testing summarized, a test summary report will include the following information (previous report, current report, and percentage change):
  • Test Suite Information:
    • o   Number of test suites planned.
    • o   Number and percentage of test suites implemented.
    • o   Number and percentage of test suites executed.
  •  Test Case Information:
  •  Number of test cases planned.
  •  Number and percentage of test cases implemented.
  •  Number and percentage of test cases executed.
  •  Number and percentage of test cases passed.
  •  Number and percentage of test cases failed (total and by severity).

About Test Data


Hey folks,

It’s so long time, to write blog on testing field back. Here I try to cover all about test data.

Test Data
A set of data created for testing new or revised applications.
Test data should be developed by the user as well as the programmer, tester and must contain a sample of every category of valid data as well as many invalid conditions as possible
Tester should check and update the test data before execution of any test case

Why Required
If you are writing a Test case then you need input data for executing that test case. If you don’t have the systematic approach for building test data while writing and executing test cases then there are chances of missing some important test cases. Preparing proper test data is a core part of “project test environment setup”. Preparation of test data is part of preparing a Test bed activity. Tester cannot pass the bug responsibility saying that complete data was not available for testing. Tester should create his/her own test data additional to the existing standard production data. Your test data set should be ideal in terms of cost and time.

Format of Test Data
The test data may be any kind of input to application, any kind of file that is loaded by the application or entries read from the database tables. It may be in any format like xml test data, system test data, SQL test data or stress test data.

Tips For Test Data
1.       Good practice for every tester keep/make their own set of test data. Sometimes on same build many testers work, so they have same access on the test data files and change the data as per their requirement. So better, keep a personal copy of your own data. It may be of any format like inputs to be provided to the application, input files such as word file, excel file or other photo files
2.       Always keep your test data up to date. Sometimes, test data is not updated so long times.
3.       Before filing the bug, please make sure that your existing test data is not corrupted for executing the test case on application.
4.       Try to make test data as per real time use of application
5.       Test data can be said to be ideal if for the minimum size of data set all the application errors get identified.
6.       Try to prepare test data that will incorporate all application functionality, but not exceeding cost and time constraint for preparing test data and running tests.

How to prepare test data that will ensure complete test coverage?
Design your test data considering following categories:
1.       No data: Run your test cases on blank or default data. See if proper error messages are generated.
2.       Valid data set: Create it to check if application is functioning as per requirements and valid input data is properly saved in database or files.
3.  Invalid data set: Prepare invalid data set to check application behavior for negative values, alphanumeric string inputs.
    • Illegal data format: Make one data set of illegal data format. System should not accept data in invalid or illegal format. Also check proper error messages are generated.
    • Boundary Condition data set: Data set containing out of range data. Identify application boundary cases and prepare data set that will cover lower as well as upper boundary conditions.
    • Data set for performance, load and stress testing: This data set should be large in volume.
    • This way creating separate data sets for each test condition will ensure complete test coverage.
In this article, I took the help from one stop testing site, As I can gather all the information at one place at time, I use some of the part from there

Thursday, January 27, 2011

QA Process Model- ETVX


Quality in the process
A quality process has the right inputs and performs the right actions to produce outputs that meet the needs of customer processes.
Definitions of quality thus include:
·       Fitness for purpose
·       Right output, right time, right place
·       Customer satisfaction
ETVX

The Entry-Task-Validation-Exit (ETVX) model views processes within the context of:
1.    Input or triggers
2.    Tasks (also called Procedures)
3.    Controls
4.    Constraints
5.    Output

There are four places where the quality can be specified and checked:
·      Entry criteria define what inputs are required and what quality these must be to achieve the exit criteria. Entry criteria should be communicated to supplier processes, to become their exit criteria. If supplier processes are sufficiently well controlled, then there is no need to check inputs.
Entry Criteria: Inputs or Triggers: Processes are initiated by either inputs or triggers. An input is usually an output from a preceding process; a trigger is an event that invokes the process. In either case, in input or trigger, an associated list of entry criteria must be satisfied in order for the process to commence.
·      Task definitions specify the actions within the process.
Tasks (also called procedures) are the action components of a process. In the ETVX model tasks follow a sequence that has a validation step. This step ensures that the process does not pass its output to another process or terminate until all exit criteria have been satisfactorily met.
·      Validation definitions identify test points within the process and define the tests and criteria for checking at these points. This enables problems to be caught close to their cause, reducing rework and scrap costs, and enabling problem causes to be addressed.
This is a process checkpoint that occurs after the task(s) associated with the process have been completed. This checkpoint is also known as quality gate – its purpose is to ensure that the task(s) have produced an output that meets specifications and/or requirements of the process. A failure at the validation checkpoint generally requires re-performing the process tasks.
·      Exit criteria define what outputs are required and what quality these must be to meet the needs of customer processes. Exit criteria may be derived from the entry criteria of customer processes.
All conditions that must be present and/or satisfied before a process can successfully terminate. Closely coupled to exit criteria is the output of the process itself. i.e, what the process was designed to produce. All processes produce an output.
·         Controls: Process controls are limits that have been purposely placed on the process to prevent undesirable outcomes. Example include:
Policies
Checkpoints
Audits and integrity checking (i.e. cyclic redundancy checks, etc)
Error detection and correction processes.
·         Constraints: Limitations imposed on a process are called constraints. Example include technical capabilities, available time frames, resources, transmission speeds, etc.
The key difference between a control and a constraint is that a control is designed into the process to produce or effect a desirable outcome, while a constraint is a limitation to the process (or environment) that may impact on the effectiveness and/or efficiency of the process.

Together, these make up what is known as the ETVX model (as below), which can be used to define the process and the quality required within it completely.


 

Fig. 1. The ETVX model

In process improvement, it can be useful to apply this model to processes that are suspected of being troublesome, in order to identify measures to identify specific problems.