How you can design your Test Data, Lets discuss about
Tips and Tricks
All of us know that testing process require large amount
of test data to complete the testing. Test data itself contain the
condition and flow of testing which help tester to understand the flow of
application software. Test Data is a vital element of maximum functional
testing. So we will discuss about test data, what is test data? How we can
create test data? Etc..
Definition of Test Data and Its importance
Test data is the type of record which is used as input for
newly developed application to confirm its functionality. Test Data will show
its effect on application while execution. Effects can be positive or negative.
Positive effect will pass the testing and negative effects mean Fail. Test data
is used for both Positive and Negative Testing.
For positive testing test data should be well designed and logical proof
but for Negative testing any type of test data can be used. Poorly test data
will not be able to complete all the possible test scenarios.
Test data creation and why it should created before test case
execution?
When test data should create and how, it’s all depend on
your environment. But mostly it created before the time of test case execution.
Test Data can be generated by following way:
i.
Manually
ii.
All data copy from production on testing
environment.
iii.
All data carried from the legacy client
system
iv.
Automatically generated the test data by
testing tool
Typically it should generate before the test execution
because during test data creation can take very huge time. And this time can
cross the deadline of project therefore it should create before the test
case execution.
Test Data for White box testing:
-
Testing data should generate in such type
which can test as max as scenarios or branches of code at least once in all
execution.
-
Path Testing: All path of source code
should be test at leas once in complete execution.
-
Navigating the API testing: i. Test Data can contain some invalid
variable types used to invoke different functions.
ii. Test Data can contain invalid
combinations of parameters which can used to invoke the functions.
Test Data For Performance
Testing:
For performance Testing: Test
data should be real and live so that it can also used on production because
actual performance can be measure only on production server.
We can get real and live test data from live
customer. We can provide them Feedback form, by this way they will provide all
required and general information important for our test environment.
Test Data for Security Testing:
Required following necessary point –
i.
Confidentiality: Record or
data provided by the client should be secure with encryption format or
any other way. So this indicates how we use test data so that test data
confidentiality could not be lost.
ii.
Integrity: Created test data
should follow and satisfy the rule of integrity.
iii.
Authentication: rules should
be satisfied by the designed test data. It is the process of creating the
identity of a user with the different combination of usernames and passwords
and its motive to confirm that only the authorized people are able to access
the software application.
iv.
Authorization: This put the
light on the rights of a specific user. Test data should contain the different
-2 combination of roles, operations and users in order to verify only users
with enough advantages are able to execute a particular action.
Test Data for Black Box Testing:
In this testing internal code is not visible to Tester, He
will test only the functionality from front end:
So Test Data should be with following properties:
i.
No Data: System Validation for no
data enters.
ii.
Valid Data: Verify the system
response with valid data input.
iii.
Invalid Data: Verify the system
response with invalid data input
iv.
Illegal data format: Verify the
system response with invalid data Format\
v.
Boundary Condition Data Set: Test
data should meet all requirements with the conditions of bounding values.
vi.
Equivalence Partition Data Set:
Test data should qualify the equivalence partitions.
vii.
Decision table data set: Test data
should qualify the decision table.
viii.
State Transition Test Data Set:
Test data should satisfy the strategy of state transition.
ix.
Use Case Test Data: Testing data
should include or sync with our used cases.
Automated Test Data Generation:
-
DTM or GSApps should
generate the Test data for automation.
-
Live data will be used here as for
testing, Data should be industry specific which can be used for demonstration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
Real world scenario for, how you can design your test data, definition
of live and real test data, tips and tricks on test data creation and why it
should created before test case execution, test data for black box testing,
white box testing, security testing and performance testing,
No comments:
Post a Comment