GUI TESTCASES

Which is used to test the  graphical interfaces which were visually seen by the user freely.

OR

It performs with the visual view which makes the user to feel free to use the application.

GUI interface provides the general idea of the application.

The following example for the notepad which gives the general idea about the GUI test case.

 Check the spelling for the windows

Check the font style for the window.

Check the menu bar style and formats.

Check the caption of the notepad.

Check whether the notepad within read only and normal conditions.

Check the scroll bar for the notepad.

Check the minimize, maximize and close option of the notepad.

Check submenus for menu bar.

Check the back ground color of the text area.

Check the color of the font typed match with the text area. 

Field Validation Check List

Date Field Checks

• Assure that leap years are validated correctly and do not cause errors/miscalculations.

• Assure that month code 00 and 13 are validated correctly and do not cause errors/miscalculations.

• Assure that 00 and 13 are reported as errors.

• Assure that day values 00 and 32 are validated correctly and do not cause errors/miscalculations.

• Assure that Feb. 28, 29, 30 are validated correctly and do not cause errors/ miscalculations.

• Assure that Feb. 30 is reported as an error.

• Assure that century change is validated correctly and does not cause errors/ miscalculations.

• Assure that out of cycle dates are validated correctly and do not cause errors/miscalculations.

Numeric Fields

• Assure that lowest and highest values are handled correctly.

• Assure that invalid values are logged and reported.

• Assure that valid values are handles by the correct procedure.

• Assure that numeric fields with a blank in position 1 are processed or reported as an error.

• Assure that fields with a blank in the last position are processed or reported as an error an error.

• Assure that both + and - values are correctly processed.

• Assure that division by zero does not occur.

• Include value zero in all calculations.

• Include at least one in-range value.

• Include maximum and minimum range values.

• Include out of range values above the maximum and below the minimum.

• Assure that upper and lower values in ranges are handled correctly.

Alpha Field Checks

• Use blank and non-blank data.

• Include lowest and highest values.

• Include invalid characters and symbols.

• Include valid characters.

• Include data items with first position blank.

• Include data items with last position blank.

Test case scenario for Cycle

1.Check whether the pedal of the cycle is free to rotate.

2.Check whether the bell of the cycle gives the exact horn sound.

3.Check whether the break of the cycle is working. 

4.Check whether the handle of the cycle is free to rotate.

5.Check whether the wheel of the cycle is circle.

6.Check whether the wheel of the cycle is free to rotate. 

7.Check whether the tyre of the cycle is made up of rubber.

8.Check whether the seat of the cycle is present.

9.Check whether the cycle is painted to avoid rust.

10.Check whether the parts of the cycle interact with each other.

11.Check whether the cycle grip is perfect to hold.

12.Check whether the cycle chain is free to rotate with the shaft drive.

13.Check the cable of the cycle.

14.Check whether the basket of the cycle is present to carry.

15.Check whether the dynamo for cycle is present.

16.Check whether the dynamo of the cycle is near to the wheel.

17.Check whether the light present in the front portion of the cycle.

18.Check whether the spokes of the cycle is perfect or not.

19.Check whether the capacity of the cycle is efficient.

20.Check whether the bar present in the cycle.

21.Check whether the carrier present in the cycle.

22.Check whether the leaf spring is working in the cycle.

23.Check the lubricant of the cycle is proper.

24.Check whether the nuts and bold are properly tightened.

25.Check whether the bearings were well lubricated.

26.Check whether the seat position is at correct position.

27.Check whether the height of the cycle is match with the user.

28.Check whether the height of the seat is match with the handle.

29.Check whether the cycle handle height is match with the seat.

30.Check whether the cycle pedal is rotated front side wheel rotates.

31.Check whether the cycle pedal is free to rotate cycle chain

32.Check whether the cycle tube is properly filled with air.

33.Check whether the cycle tube valve is properly fixe.

34.Check whether there is no leakage of air in the cycle tube.

35.Check whether the cycle stand is working properly.

36.Check whether the Chain is properly covered.

37.Check whether the cycle  rear break is present init

38.Check whether the shock absorber is present in the cycle.

39.Check whether the rubber tyres were fitted properly.

40.Check whether the cycle brand name is valid.

41.Check whether the noise is low.

42.Check whether  the cycle got two wheel.

43.Check whether the cycle seat is soft and made up of sponge.

44.Check whether the handle of the cycle is in correct position.

45.Check whether the tyre can accept  the nails

46.Check whether the cycle handle is free to rotate.

47.Check whether the cycle handle rotates simultaneously with cycle front wheel.

48.Check whether the cycle chain and their connections were made with back wheel.

49.Check whether the number of spokes in both the wheels is same.

50.Check whether the RIM is joined properly with spokes at certain distances and their positions

51.Check the logo present in all the parts of the cycle.

Equivalence class partitioning and Boundary value analysis.

Equivalence class partitioning 

A set of valid input data is selected, with those data choose randomly a value. Using that value which was given as an input and the output which was expected will be verified.

Boundary value analysis 

The maximum and minimum value for a range given should be calculated. max/min value will 

be given as input data  and the expected outcomes were verified.

Ex:

Consider number of employee in our company

Totally 80 members

Entry in the gate  need to write the conditions.

For ECP

Num 1-80  valid to entry in the gate

Valid - 5 or 64 or 35 or 79

Invalid – 864 or 82 or -34 or-1

For BVA

Valid- 1 or 2 and 79 or 80

Invalid – 0 and 81

Valid -> entry in the gate 

Invalid -> Not applicable.

These are the valid and invalid data to be given to calculate the ECP and BVA.

Positive and Negative test cases

Positive Test cases

                The testing operation has to be performed using the valid data (ie the actual input has to be given then the testing operation has been performed which gives the actual result)

Giving valid data and makes it “feel to pass”

Negative test cases 

               The testing operation has been performed using the invalid data(ie Invalid data has to be given and the Expected result should shows an warning messages or error windows)

Giving invalid data  and make it  “feel to fail”

Ex :

Using mouse Scroll bar;

Mouse pointer should move only when the mouse scrolled and its point to the exact location (Positive Test cases) 

Check pointer movements when mouse is  scrolled.

Mouse pointer should not move until the mouse scrolled and pointer should be in idle position (Negative Test cases) 

Check pointer movements when mouse is in idle condition.

Functional test cases for mobile

check with keypad

check the incoming call is being displayed
check with outgoing call
check with contact's name is being displayed while making out/incoming call
check with screensaver option
check with out speaker option
check with sms
check with profiles

To check whether a call is coming it must shown in screen along with whom the call is from along with the video should be running
To check whether when we attend the call the video should be paused
To check whether when we cancel the call the video should be played
To check whether when the call is on hold the video must be played

Functional Test case:

Testing will be performed functionality wise of the each and every field given in application link will also be included. Whenever values given into the field then its corresponding navigation should be take place.

Ex:

Whenever we click the start button of the windows it should displays the popup menu to select the list. Then the test case will be

Click start button using WIN key.

Click start button using mouse pointer.

Click start button using tab key.

Test-case Scenario for ATM Machine

Verify the door has been opened when inserted the ATM card.

Verify the card has been inserted in the ATM machine at the proper side.

Validate the language to be selected in the option

1) Tamil

2) English

3) Hindi

Verify the pin has been entered in the encrypted format of the system.

Verify the wrong pin num entered as the encrypted format.

Validate the following option to be selected in the proper action.

1) Withdrawal

2) Transfer fund

3) Enquiry

4) Change pin num.

1) Withdrawal

Check whether the amount entered is valid.

Valid- Get the amount

Invalid - reenter the valid amount.

2) Transfer fund

Validate the entered account number for fund transfer.

Validate the amount entered to be transferred.

Validate the entered amount for transfer.

Valid - transfer.

Invalid - reenter the valid amount.

3) Enquiry

Validate the contents available on the screen.

Validate the enquiry is received as the receipt.

4) Change pin number

Validate the following options present in the screen

i) pin num (enter original pin number)

ii) Enter new pin number

iii) Reenter new personal identification number.

Select an option for another transaction (yes/no).

Verify the machine donot have following problems.

No amount in the machine.

Connection failure occurs then transaction should be revoked

Verify the operation when u insert a right card.

Verify the operation when u inserted a card in right angle.

Verify the operation when u inserted a card in wrong angle

Verify the language selection.

Verify whether its displaying the selected language or not.

Verify the operation when u entered a right pinNo.

Verify the opertaion when u entered a wrong pinno..

Verify the pinNo is in encrypted form or not.

Verify the options.

If we click on option verify whether its giving the selected option.

Verify the amount entered.

Verify whether the money is drawing from the selected account or not.

Verify whether the correct amount is coming out or not.

Verify the operation when u draw money greater than balance.

Verify the operation when u draw money greater than the day limit.

Verify the operation when the machine don’t have money.

Verify the operation when the machine has some problems

Fuzz Testing

Fuzz testing is a Black box testing process that uses random bad information to attack a program & see what breaks in your application.
Fuzz testing is mostly used for,
• Generate a right to enter its program.
• Restoring a portion of the file with random information.
• Open the file with the program.
• Observe what is broken.
Fuzz testing can be automated to maximize their impact on giant applications. This check enhances confidence that the application is safe & secure.

Principles of Agile Testing & Development

Agile methods are a family of development processes, not a single approach to software development. Agile follows ‘adaptive’ planning rather than ‘predictive’ planning in conventional Waterfall Process.

• Customer satisfaction by rapid, continuous delivery of useful software.
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress.
• Even late changes in requirements are welcomed.
• Close, daily, cooperation between business people and developers
• Face-to-face conversation is the best form of communication.
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design.
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

Top 20 practical software testing tips you should read before testing application.

I wish all testers read these software testing good practices. Read all points carefully and try to implement them in your day-to-day testing activities. This is what I expect from this article. If you don’t understand any testing practice, ask for more clarification in comments below. After all you will learn all these testing practices by experience. But then why not to learn all these things before making any mistake?

Here are some of the best testing practices I learned by experience:

1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.

2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.

E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11) Go beyond requirement testing. Test application for what it is not supposed to do.

12) While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17) Testing teams should share best testing practices, experience with other teams in their organization.

18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep anything verbal.

19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.

Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.

Over to you: