Test Data for Black Box Testing
The Quality Assurance Testers perform integration testing, system testing and the acceptance testing, which is known as black box testing. In this method of the testing, we do not have any work in the internal structure, design and the code of the application under the test. The testers’ primary purpose is to identify and locate the errors. By doing so, we apply either functional or non-functional testing with using different techniques of black box testing.
At this point, the testers need the test data as input for executing and implementing the techniques of the black box testing. And the testers should prepare the test data that will examine all application functionality with not exceeding the given cost and the time. We can design the test data for our test cases considering data set categories like; no data, valid data, Invalid data, illegal data format, boundary condition data, equivalence partition, decision data table, state transition data, and use case test data.
Before going into the data set categories, the testers initiate data gathering and analyzing of the existing resources of the application under tester (AUT). According to the earlier points mentioned about keeping your test data warehouse always up to date, you should document the test data requirements at the test-case level and mark them useable or non-reusable when you script your test cases. It helps you the test data required for testing is well-cleared and documented from the very beginning that could be later referenced for further use.
The table below illustrates pretty much a sample of the test data requirement gathering that can be part of the test case documentation and to is updated when you write the test cases for your test scenarios.
|No.||Test Case||Test Data Requirements||Reusable||Remarks|
|1||TC_EMR_Login_01||Open EMR Username||Y||Min 4& Max 20|
|2||TC_EMR_Login_02||Open EMR Password||Y||Min 4 & Max 20|
|3||TC_EMR_Reg_03||Open EMR Patient Name||N||Min 3& Max 20|
|4||TC_EMR_Reg_04||Open EMR Patient SSN||N||<9> digits|
Let’s step forward to the creation of manual test data for testing Open EMR application for the given test data set categories.
- No Data: The tester validates Open EMR application URL and the “Search or Add Patient” functions with giving no data.
- Valid Data: The tester validates Open EMR application URL and the “Search or Add Patient” function with giving Valid data.
- Invalid Data: The tester validates Open EMR application URL and the “Search or Add Patient” function with giving invalid data.
- Illegal Data Format: The tester validates Open EMR application URL and the “Search or Add Patient” function with giving invalid data.
Test Data for 1-4 data set categories:
|No.||Test Case Data||No Data||Valid Data||Invalid/Illegal Data|
- Boundary Condition Data Set: It is to determine input values for boundaries that are either inside or outside of the given values as test data.
- Equivalence Partition Data Set:It is the testing technique that divides your input test data into the input values of valid and invalid.
Test Data for 5th and 6thdata set categories, which is for Open EMR username and password:
|Open EMR Test Data|
|Boundary Value Analysis||Equivalence Partition Analysis|
7. Decision Table Data Set:It is the technique for qualifying your data with a combination of inputs to produce various results. This method of black box testing helps you to reduce your testing efforts in verifying each and every combination of test data. Additionally, this technique can ensure you for the complete test coverage.
Please see below the decision table data set for Open EMR application’s username and the password.
|Actions||Expected Result||Error: Please enter username||Error: Please enter the correct PW||Error: Please enter the correct username||Logged in|
The calculation of the combinations done in the table above is described for your detailed information as below: You may need it when you do more than four combinations.
Number of combination = Number of Conditions 1 Values * Number of Conditions 2 Values
Number of combinations = 2 ^ Number of True/False Conditions
Example: Number of combinations – 2^2 = 4
- State Transition Test Data Set:It is the testing technique that helps you to validate the state transition of the Application Under Test (AUT) by providing the system with the input conditions.
For example, we log in the Open EMR application by providing the correct username and the password at first attempt. The system gives us the access, but if we enter the incorrect login data, the system denies the access. State transition testing validates that how many logins attempts you can do before Open EMR closes.
The table below indicates how either the correct or the incorrect attempts of login respond:
|EMR Login Attempts||Valid Password||Invalid Password|
|1st Attempt- State 1||Access||Denied|
|2nd Attempt- State 2||Access||Denied|
|3rd Attempt- State 3||Access||Denied|
|Logins in Successfully- S 4||Access|
|EMR Application Closes||Open EMR – Closed|
- Use Case Test Date: It is the testing method that identifies our test cases capturing the end to end testing of a particular feature.
Example, Open EMR Login
|User||1||Enter Username and Password|
|System||3||Access Open EMR application|
|User||1||Enter Invalid Username|
|System||2||Access Denial Message by EMR|
|User||3& 5||Re-Enter Invalid Username|
|System||4& 6||Access Denial Message by EMR- the same for third invalid entry|
|System||7||EMR Application Closed|
Creating complete software test data in compliance with the industry standards, legislation and the baseline documents of the undertaken project is amongst the core responsibilities of the testers. The more we efficiently manage the test data, the more we can deploy reasonably bug-free products for the real-world users. Test data management (TDM) is the process that is based on the analysis of challenges and introducing plus applying the best tools and methods to well address the identified issues without compromising the reliability and the full coverage of the end output (product).
We always need to come up with questions for searching innovative and more cost-effective methods of analyzing and selecting our methods as well as tools for generating the test data. In the end of this tutorial, well-designed test data allows us to identify defects of the application under the test in every phase of a multi-phase SDLC. We need to be creative and participating with all the members within and outside our agile teams.
Please share your feedback, experience, questions, and comments so that we could keep up our technical discussions on-going to maximize our positive impact on AUT by managing test data. The second part of this tutorial is on the “Test Data Generation with GEDIS Studio Online Tool”: