User Interface Testing | Best Practices

19.901 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
15 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
19.901
No SlideShare
0
A partir de incorporações
0
Número de incorporações
36
Ações
Compartilhamentos
0
Downloads
129
Comentários
0
Gostaram
15
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

User Interface Testing | Best Practices

  1. 1. USER INTERFACE TESTING DAVID TZEMACH WWW.DTVISIONTECH.COM JAN 13 2016
  2. 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. 3. THE CHALLENGE IN USER INTERFACE TESTING
  4. 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. 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. 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. 7. AUTOMATION YES OR NO?
  8. 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. 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. 10. RECOMMENDATIONS FOR USER INTERFACE TESTING
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. FOR ADDITIONAL KB’S PLEASE VISIT MY BLOG WWW.DTVISIONTECH.COM

×