Overview What is GUI testing…? The testing challenges Should you automate your test..? Test Recommendations GUI testing Checklist How to handle different GUI objects

1. USER INTERFACE
TESTING
DAVID TZEMACH
WWW.DTVISIONTECH.COM
JAN 13 2016

2. OVERVIEW
• THE MAIN IDEA IS TO ENSURE THAT THE GUI IS DEVELOPED BASED ON THE WRITTEN SPECIFICATIONS.
• A GREAT UI THAT CODED AND TESTED EFFICIENTLY WILL ALLOW THE END USER TO PERFORM A HIGHLY
COMPLEX OPERATIONS WITHOUT A COMPLEX SET OF TASKS.
• THE MAIN GOAL OF GUI TESTS, IS TO HELP THE USER TO PERFORM IS TASKS IN THE EASIEST WAY AND
MOST IMPORTANTLY IN A WAY THAT SAVES IS TIME.
• THE GRAPHICAL USER INTERFACES (GUI) IS THE MAIN PLATFORM THAT WE USE TO MANIPULATE A GIVEN
APPLICATION.

3. THE CHALLENGE IN USER
INTERFACE TESTING

4. THE USER INTERFACE COMPLEXITY
THE SOFTWARE INDUSTRY CAN PRODUCE A VERY COMPLEX GUI (THAT CONTAINS
INFINITE SCENARIOS AND COMBINATIONS) FOR THE END CLIENTS. THEREFORE, IT’S
SIMPLE FACT THAT THE TESTING COMPLEXITY IS CUT BASED ON THIS PARAMETER (GUI
COMPLEXITY = MORE TESTS).

5. MULTIPLE PLATFORMS
NOT LIKE 30 YEARS, TODAY APPLICATIONS BECOME RELEVANT TO ALMOST EVERY DEVICE AND
SOFTWARE PLATFORMS, THE MORE PLATFORMS WE NEED TO SUPPORT THE MORE TESTING IS
NEEDED, JUST FOR EXAMPLE, THINK ABOUT AN APPLICATION THAT SHOULD BE COMPATIBLE WITH
THE FOLLOWING PLATFORMS:
HARDWARE PLATFORMS:
MOBILE PHONES. COMPUTERS, TABLETS, ETC.
SOFTWARE PLATFORMS:
WEB BROWSERS (FIREFOX, IE, CHROME…).
PHONES OS (ANDROID, WINOS, MACOS…).
DIFFERENT OS SYSTEMS (WIN/LINUX OS….)

6. HOW MUCH TESTING IS ENOUGH?
JUST LIKE ANY OTHER TESTING TYPES, YOU CAN SAY THAT YOU MAKE
ENOUGH TESTING ONLY WHEN ALL THE RISKS YOU ANALYZED AT THE
BEGINNING OF THE TESTING PROCESS ARE REMOVED.

7. AUTOMATION
YES OR NO?

8. WHY TO AUTOMATE…?
• GUI TESTING IS ONE OF THE MOST TIME CONSUMING TASKS IN THE SOFTWARE
INDUSTRY, AUTOMATION WILL REDUCE THIS TIME ON ANY REGRESSION CYCLE.
• AUTOMATION WILL SAVE YOU TIME AND MONEY.
• GUI TESTS MAY INVOLVE AN INFINITE TESTING SCENARIOS, AUTOMATION CAN
COVER AT LEAST 90% FROM THEM.
• THE SAME TESTS CAN BE EXECUTED DAILY.

9. WHY NOT TO AUTOMATE…?
• DEPENDS ON THE GUI COMPLEXITY, WRITING AUTOMATION TEST CASES COULD
TAKE AN INFINITE AMOUNT OF TIME.
• AUTOMATION CAN COVER MAJOR ASPECTS OF THE TESTED GUI, BUT FEW GUI
CASES CANNOT BE AUTOMATED.
• GUI IS ONE OF THOSE COMPONENTS THAT COULD BE CHANGED MULTIPLE TIMES,
AS A RESULT WE NEED TO INVEST MAJOR TIME TO MAINTAIN THE WRITTEN
AUTOMATION

10. RECOMMENDATIONS
FOR USER INTERFACE TESTING

11. DO NOT IGNORE THE HUMAN EYE
AUTOMATION IS THE BEST WAY TO TEST THE USER INTERFACE, BUT
THAT DOESN'T MEAN THAT YOU CAN IGNORE THE PERSPECTIVE,
VISION AND SENSE OF THE MANUAL TESTER.

12. AUTOMATE YOUR TESTS!
GUI TESTING IS PERFECT FOR AUTOMATION THAT ARE A KEY PART
FROM ANY REGRESSION CYCLE. THEREFORE, TRY TO AUTOMATE AS
MANY TEST CASES AVAILABLE.

13. TEST EFFICIENCY INSTEAD OF UNREALISTIC COVERAGE
THE FACT IS THAT GUI TESTS MAY LEAD TO AN INFINITE TESTING
MATRIX THAT YOU JUST CANNOT COVER, THE SOLUTION IS TO RUN
YOUR TESTS BASED ON AN EFFICIENT DESIGN THAT INVOLVE RISK
ANALYSIS AND PRIORITIZATION.

14. SEPARATION OF GUI OBJECTS
THE GRAPHICAL USER INTERFACE IS BUILT FROM A SET OF OBJECTS, WHEN DESIGNING YOUR TESTS
YOU SHOULD CONSIDER EVERY OBJECT AS “STAND ALONE” AND ASK YOURSELF FEW QUESTIONS:
• WHAT ARE THE OUTPUTS WE NEED TO GET WHEN USING THIS OBJECT?
• IS THERE ANY INTEGRATIONS WITH OTHER OBJECTS?
• WHAT ARE THE ATTRIBUTES OF THIS OBJECT?
• AVAILABLE INPUTS (IF SUPPORTED)?
• WHY WE NEED IT?

15. MAKE SURE THAT THE UI IS USABLE
THE UI IS THE MAIN CONSOLE THAT THE USER WILL USE WHILE
WORKING WITH THE SOFTWARE, YOUR TESTS MUST INVOLVE
ADDITIONAL LAYER THAT GUARANTEE THAT THE UI WILL BE USABLE
WHEN IT’S BEEN USED BY THE CLIENT.

16. FOLLOW THE INDUSTRY STANDARDS
EVERY UI MUST BE TESTED BASED ON A FEW BASIC STANDARDS THAT WE
USE IN THE SOFTWARE INDUSTRY, EXAMPLES:
• EVERY FIELD THAT USED TO FIND VALUES SHOULD BE CALLED “SEARCH” AND NOT “FIND”.
• KEYBOARD BUTTON “F1” SHOULD POINT TO USER HELP GUIDE ON WINDOWS PLATFORMS.
• IN WINDOWS OS THE “OK” BUTTON WILL BE ON THE LEFT OF THE “CANCEL” BUTTON (THE
OPPOSITE BEHAVIOR FROM MACOS).

17. CHECKLISTS AND GUIDELINES
FOR UI TESTING
You can find the full list at :
http://www.dtvisiontech.com/2014/05/qa-graphical-user-interface-testing.html

18. GENERAL TESTS
• IS THERE A DEFAULT OBJECT THAT HIGHLIGHTED WHEN THE USER STARTS THE APPLICATION?
• THE APPLICATION NAME SHOULD BE DISPLAYED ON THE APPLICATION MAIN FORM.
• THE “HELP” MENU SHOULD BE AVAILABLE IN THE MAIN SCREEN NAVIGATION BAR.
• IN MOST CASES GUI FORMS SHOULD HAVE THE MINIMIZE/MAXIMIZE OPTIONS.
• WEB APPLICATIONS SHOULD BE TESTED WITH DIFFERENT RESOLUTIONS
• CLOSING THE APPLICATION SHOULDN’T OCCUR WITHOUT AN APPROVAL NOTIFICATION THAT
ALLOWS THE USER TO “APPROVE” OR “DECLINE” THE OPERATION.

19. OBJECT COLOR
• IF FIELDS BECOME “GRAYED-OUT”, DO WE DISPLAY THE CORRECT COLOR?
• FORM TITLE AND DESCRIPTION DISPLAYED IN THE CORRECT COLOR?
• WHEN FIELD IN FOCUS, DO WE MARK IT WITH DIFFERENT COLOR?
• IS THE LOADING SCREEN DISPLAYED WITH THE CORRECT COLOR?
• ARE THE HYPERLINK COLORS ARE IN THE EXPECTED COLOR?
• FORM BACKGROUND COLOR IS THE CORRECT ONE?
• LOADING PROCESS BAR IN THE CORRECT COLOR?
• ARE THE BUTTONS ARE IN THE RIGHT COLOR?

20. OBJECTS SYNTAX
• IS THE TEXT IN ALL OBJECTS ARE WRITTEN WITH THE CORRECT FONT?
• IS THE TEXT IN ALL OBJECTS ARE WRITTEN WITH THE CORRECT SIZE?
• IS THE FIRST CHAR (IF RELEVANT) IN A WORD SET AS CAPITAL?
• ARE ALL THE SCREEN TEXTS ARE ALIGNED CORRECTLY?

21. CHECKLISTS AND GUIDELINES
FOR SPECIFIC OBJECTS
You can find the full list at :
http://www.dtvisiontech.com/2014/05/qa-graphical-user-interface-testing.html

22. RADIO BUTTONS
• EVERY BUTTON SHOULD EXECUTE A SPECIFIC FUNCTIONALITY.
• BY DEFAULT AT LEAST ONE BUTTON SHOULD BE SELECTED.
• EVERY BUTTON SHOULD BE AVAILABLE FOR SELECTION BOTH BY USING THE
MOUSE AND KEYBOARD.

23. VALIDATION FIELDS
• DO THE SRS DOC, SPECIFIED THAT THE AUTHENTICATION SUPPORT SPECIAL CHARACTERS?
• DO THE SRS DOC, SPECIFIED THAT THE AUTHENTICATION SUPPORT NEGATIVE VALUES?
• CHECK IF THE VALIDATION FIELDS SHOULD SUPPORT A SPECIFIC FORMAT OF VALUES.
• DO THE VALIDATION FIELDS ARE “CASE SENSITIVE”?
• IN ANY CASE OF INVALID AUTHENTICATION, THE USER SHOULD BE NOTIFIED THAT THE PROCESS
FAILED WITH AN APPROPRIATE NOTIFICATION.

24. DROP DOWN LISTS / LIST BOXES /COMBO BOX
• DROP DOWN VALUES MUST BE PRESENTED WITH ORDER, IN 90%, THE ORDER DETERMINED ALPHABETICALLY.
• NOT LIKE THE FIRST TWO OBJECTS, IN COMBO BOX, USER SHOULD HAVE THE OPTION TO INSERT TEXT.
• WHEN USER SELECT A VALUE, THIS VALUE SHOULD BE DISPLAYED ON THE MAIN DROP DOWN FIELD.
• IF THE LIST CONTAINS MULTIPLE VALUES, THE LIST SHOULD BE SCROLLABLE.
• DROP DOWN OBJECTS DOESN’T NEED TO SET WITH DEFAULT VALUES.
• WHEN THE DROP DOWN IN FOCUS THE KEYBOARD COMBINATION OF CTRL-F4 SHOULD OPEN THE LIST OF VALUES.

25. PUSH BUTTONS
• CONTINUING THE PREVIOUS BULLET, THE “SPACE” KEY SHOULD DO THE SAME ACTION.
• EVERY BUTTON SHOULD HAVE THE OPTION TO TRIGGER WITH AN APPROPRIATE KEYBOARD
SHORTCUT (YOU MUST MAKE SURE THAT DUPLICATE SHORTCUTS ARE NOT EXISTING).
• ESC SHOULD ACTIVE THE “CANCEL” BUTTON (IF AVAILABLE IN FORM).
• MAKE SURE THAT ALL BUTTONS ARE SIMILAR IN SIZE, SHAPE AND SIZE.

26. TEXT BOX
• THE TEXT BOX MUST SUPPORT COPY/PASTE OF SYNTAX FROM DIFFERENT LOCATIONS.
• DOUBLE CLICK ON THE TEXT SHOULD HIGHLIGHT THE ENTIRE SYNTAX.
• ENTER SYNTAX IN THE TEXT BOX WITH SPACE AT THE BEGINNING.
• ENTER SYNTAX IN THE TEXT BOX WITH SPACE AT THE END.
• USER HAS THE OPTION TO ENTER TEXT INTO THE BOX.
• DO WE SUPPORT UPPER AND LOWER CASE?

27. DATE AND TIME FIELDS
• CAN YOU CHANGE THE DATE/TIME (INSERT DAY IN THE YEAR LOCATION, INSERT YEAR IN THE
MONTH LOCATION...) ORDER AND APPROVE THE CHANGE?
• CHANGE TIME ZONES IN SPECIFIC COMPONENTS TO SEE HOW THE APPLICATION CAN HANDLE
DIFFERENT DATE FORMATS.
• APPLICATIONS MUST BE TESTED WITH OS “TIME ZONE” CHANGES, DIFFERENT COMPONENTS
THAT INTEGRATED WITH DIFFERENT TIME ZONES MAY LEAD TO FAILURES IN THE DATA
SYNCHRONIZATION.

28. FOR ADDITIONAL KB’S PLEASE
VISIT MY BLOG
WWW.DTVISIONTECH.COM