the scenario was asked by some one in some of the groups earlier but no one answered .
Hope experts can answer to this .
There is a 2 web page, Page: 1 and page: 2
1. Name : ------------- Note : ----------(text)
2. user :--------------
3. pass :--------------
4. DOB :--------------
5. terms&condition(it is a checkbox)
5. Cancel button
If user clicks the submit button. it goes to the Page :2
if user clicks the cancel button. all data r cleared.
In this page All the information has displayed.(IN Label format).
for examples : Name : XYZ, user :XYZ ,DOB :21/05/2004
Here is one Button Called
when user click this button it goes back to the Page : 1.
Can anyone tell .
Explain How to write Test cases for this page and the Differences.
1. Functional Test cases
2. System Test cases
3. Integration Test cases
4. User Acceptance Test cases
And Also tell how to do design/plan and Report for these.
Integration,Functional,System and User Acceptance.
Please do the Need ful..
U should write test cases for GUi as for all the fields i.e all the fields(mentioned above) should be displayed and editable.For buttons : displayed and enabled.
2.Check for mandatory field validation test cases like if user forgets to fill any mandatory field is proper error message displayed or not.
3. write test case for actual behaviour of Submit and Cancel button.
4. Check after clicking Submit button all the details filled in page1 is displayed properly.
5. Editable fields validation like length of character.For name field: Characters are only accepted, special charcters and numbers are not accepted.DOB validation....
6.User field validation..i.e create a user as "user1" and again try to create a user with same name i.e "user1"...
7. pass:alpha numeric is accepted or characters or only numbers are accepted....
Hope this helps u......
Hi Heena ,
I wanted to know how we write integration testcases .
plz help me with sample example
Why don't you supply what you think should be done and then we can confirm and suggest additions.
I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison
As far as integration is concerned, what applications or sites does this site integrate with.
For example, is there a support application that might be used to retrieve this data, then ensure that this application is able to do so. As described above, there appears to be no need for integration testing, as this site has no effect on other systems.
Something you might want to write a case for is that the information has been recorded correctly. For example, if name is to be recorded to database A in NAME column, then ensure this has happened. And so on for information to be captured by the system. This falls more towards the system tests though.
But I agree with Lynne, specify what you think needs to be tested and others will confirm if you are on the right path.
Prani2k, let me be a little more specific about what you need to think of:
1. Catalog all the data elements on the screens with governing business rules, edits, range, domain, whatever leads to the need to provide the appropriate test alternatives. For example, you may want to enforce dates in a particular format and you may expect people to be at least 27 years old before they use your system.
2. Itemize the different business process flows that utilize the screens, and establish use cases that clearly identify the alternative flows that you may have to test. Identify how these flows may be determined by specific data (combinations) from point 1.
3. Between use cases and data variations you can identify many alternative test cases that can be defined. This is your base set, you may even do an all-pairs optimization (ok., your example is a rudimentary one, my suggestion pertains to a real test project and not a course assignment).
4. You have ignored unit testing and integration testing in development. You could provide cases to the developer for use prior to the delivery of well-tested code to QA. The practice is long long overdue, so I thought I'd bring it to focus.
5. Your pruned set of tests from point 3 reflect the system test cases (also called functional testing). This validates that all functionality in the system meets the requirements. If you put this together at a high level you write cases, if you spell it out so most persons can follow the instructions step-by-steo you write test scripts. There is no difference between system testing and functional testing, so you get a 25% bonus. What may be confusing is that you should do such tests in the IT development organization and possibly again in the client organization if this is some other company. Within the same company you only do it once.
6. User acceptance testing is normally the next step, to make sure that the software not only is compliant with requirements, but it actually does help the user operate more efficiently. This can also be classified as usability testing. This may be confusing also, because sometimes you write an application exactly as specified, but when actual results are shown the user realizes that this is never going to fly. Better late than never figure that out until after you deploy the software in a full-fledged production setting. For the majority of projects UAT will be based on a subset of your functional test cases: they don't need to try all variations because their focus is different.
7. Production testing is what we call integration of new applications with an existing slate of software, to make sure it properly coexists and that its performance characteristics do not cause problems for existing applications. Sometimes we need to verify that the code is compatible with a particular configuration, such as an OS release and a specific DBMS release. I will not go into a lot of detail here, but performance testing will be a major aspect of production testing.
I hope this gives you something to chew on while you consider a sample approach that you can then submit to this forum for review. Enjoy, it will be a good learning experience.