TEST DATA- black box and white box testing. in black box testing their is invalid data, valid data and borderline data. invalid data is data which should generate an error message if it was input outside of the expected range. valid data is data that you would normally expect the user to input within the expected range. finally borderline data is data where you need to be extremely careful to test it at the boundaries of different cases, to ensure they are dealt with correctly.
it is also important that any data testing which checks the validation should include the following: normal data-which is data that is in the normal range and will be accepted
extreme data- data that is on the extreme limits but should be accepted. for example if the borderline was 100 and you had 100 it will just about be accepted.
erroneous data-data that should fail if tested
TEST TABLES- is a table outlining the test plan. the heading in order are test number, part of system, test data, expected results, actual results and pass/fail.
DEBUGGING tools-it is a process of locating and getting rid of bugs from the computer.
TRANSLATOR DIAGNOSTICS-messages generated by the translator, while translating the source code and object code. it is used to find syntax and logic errors
trace tables are used by programmers to track the values of variables as they change throughout the program. this is useful when a program is not producing the desired results.
The first test of newly developed hardware or software in a laboratory setting. When the first round of bugs has been fixed, the product goes into beta test with actual users. For custom software, the customer may be invited into the vendor’s facilities for an alpha test to ensure the client’s vision has been interpreted properly by the developer. See beta test and testing types
for example when companies are developing videos game they first text the game in their own labs where they can make sure it actuals does what is is meant to do, then they use beta testing when they realise it for public to use and play so they can test how it performs in a real life situation
(This is also known as glass box, clear box, and open box testing.) In white box testing, you create test cases by looking at the code to detect any potential failure scenarios. You determine the suitable input data for testing various APIs and the special code paths that need to be tested by analyzing the source code for the application block. Therefore, the test plans need to be updated before starting white box testing and only after a stable build of the code is available.
A failure of a white box test may result in a change that requires all black box testing to be repeated and white box testing paths to be reviewed and possibly changed.
This approach tests all possible combinations of end-user actions. Black box testing assumes no knowledge of code and is intended to simulate the end-user experience. You can use sample applications to integrate and test the application block for black box testing. You can begin planning for black box testing immediately after the requirements and the functional specifications are available.
for a black box test you give it and input and compare it with the expected output e.g. when you make a user forum it should come out with and output of user created successfully.