Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testing banking apps

17,507 views

Published on

Published in: Technology
  • Be the first to comment

Testing banking apps

  1. 1. Software testing bankingapplications for mobile platforms Christian Ramírez
  2. 2. ContextDesign Considerations AgendaTest DesignTo work
  3. 3. Presentation
  4. 4. Presentation• My name is Christian Ramírez• Computer Engineer• QA & testing Architect• Over 8 years of experience in QA and software testing Presentation
  5. 5. Context
  6. 6. Context• Mobile Banking – provision and availment of banking- and financial services – help of mobile telecommunication devices – Services • Facilities to conduct bank and stock market transactions • Administer accounts • Access customised information. Context
  7. 7. Context• The first mobile phone-based banking service was launched in 1997 by Merita Bank of Finland, using SMS. Context
  8. 8. Context• The mobile banking market has grown significantly Context
  9. 9. Context• Mobile Banking includes a wide range of services. – These services may be categorised as following • Mobile Accounting • Mobile Brokerage • Mobile Financial Information Context
  10. 10. Context• What is the challenge? – Todays banking applications are being used on smartphones • Web • Native – Manual testing is inefficient and doesnt scale – All platforms are different Context
  11. 11. Design Considerations
  12. 12. Design Considerations• We need look beyond of the evidentSword of omens,give me sight beyond sight Design Considerations
  13. 13. Design Considerations• You don’t need to reinvent the wheel – Same domain same rules – Reuse Design Considerations
  14. 14. Design Considerations Features TestDevices Locations Complexity Carriers Design Considerations
  15. 15. Design Considerations Design Considerations
  16. 16. Design Considerations• Round 1 – Traditional apps VS Mobile Apps Design Considerations
  17. 17. Design Considerations• Round 2 Native Apps vs Web Apps Design Considerations
  18. 18. Design Considerations• Manual testing is inefficient, but necessary.• Test automation is logical solution. – Use test automation correctly Design Considerations
  19. 19. Design Considerations• Effective Test automation – Automate as much as possible – Focus in solve real problems – Think different, this kind of applications are very sensitive to external factors – Be a pioneer Design Considerations
  20. 20. Test Design
  21. 21. Test Design• Testing Framework Test Logic • Business Logic • Verification and Validation logic Dsl Application Driver • API Technical Driver • API • Access to technical data storage Software Under Test • Web • Native Test Design
  22. 22. Test Design• Divide and conquer – Separate all parts as much as possible Test Data • Reliability • Flexibility Test Logic • Maintainability • Clarity • Stability Application Driver Test Design
  23. 23. Test Design• Promote the reuse – Design for reuse – Design with reuse – Improve your productivity – Reuse among platforms and domains • Business logic Test Design
  24. 24. Test Design• Testability – The solution to all problems • the quality of a software design that allows for automated testing in a cost-effective manner. Repeatable Easy to Easy to write Testability understand Fast Test Design
  25. 25. Test Design• TDD – Is the strategy of starting the development process by the test cases and then provide the software that satisfies these tests Red -> Green -> Refactor Red: Create an automated test. Run it. It should fail Green: Create the code to pass the tests Refactor: Clean up the code Test Design
  26. 26. Test Design• TDD – Unit tests • Written by programmers • For programmers • In a programming language Test Design
  27. 27. Test Design• BDD Test Design
  28. 28. Test Design• BDD – Beer Driven Development??? Test Design
  29. 29. Test Design• BDD – Evolution in the thinking behind TDD – Common vocabulary between business, programmers and testers – BDD helps to achivement to increse the testability – Use a DSL(Domain Specific Language) to explain the behavior of the applications – Useful to write acceptance tests • A lot of tools • A lot of DSLs Test Design
  30. 30. Test Design• BDD – Use text scenarios • Given • When • Then – Defining steps Test Design
  31. 31. Test Design• BDD – DSL • Almost programming language dedicated to a particular problem domain – In banking apps is very useful to create acceptance tests • High level – tests are in the language of product management, at the user level • Readable – product management can understand them • Writeable - easy for developer or QA to write new test • Extendible – tests base is able to grow with DSL Test Design
  32. 32. To Work
  33. 33. To Work• Test Automation – Almost always is possible automate all tests of a mobile banking application UI System Module Code(unit) To Work
  34. 34. To Work• Test Strategy – Unit Test – Internal logic – Gui Test – Usability – Navigation – Always consider varied end user expectations To Work
  35. 35. To Work• Test Strategy – Separate generic from specific • Many mobile applications include algorithms, etc unrelated to the mobile platform or technology • These should be separated from platform / technology specific code • Use desktop test automation to test generic code • Consider platform-specific test automation once the generic code has good automated tests To Work
  36. 36. To Work• Data collection – Screenshots • DDMS for Android – Logs • adb shell for Android To Work
  37. 37. To Work• Test Strategy Emulators Real devices • Android SDK in real Real Devices network • iOS SDK in the lab • Carrier • Network To Work
  38. 38. To Work• Test Strategy for client applications – Unit testing – System testing when practical – Manual testing on devices – Use emulators with network analyzers – Custom clients help: Diagnose client capabilities – Identify and isolate the cause of problems – Model-based testing helps drive the client To Work
  39. 39. To Work• Testing on android platform – SDK integrates a testing framework – It’s based on junit3 – Supports • Unit tests • Functional tests • Activity tests • Mocks To Work
  40. 40. To Work• Testing on android platform – Functional testing in native apps • You can use activities – Pieces of code executables – Interact with user – Get data – etc • Activity can be manipulated • You can use sendKeys() to simulate user interaction • Is possible do isolated testing of a single activity • Tests can be annotated with @UiThreadTest To Work
  41. 41. To Work• Testing on android platform – Test application in controlled enviroment – Basic lifecycle • onCreate() called after createApplication() • tearDown() calls onDestroy() – Mock context can be injected – Application can be terminated with • terminateApplication() To Work
  42. 42. To Work• Testing on android platform – Some methods should be avoided and will throw exceptions if called To Work
  43. 43. To Work• Testing on android platform – Framework support to test Services – Lifecycle • onCreated() called after startService() or bindService() • Depending on how was started tearDown() calls appropiate method – Mock object can be injected by • setApplication() • setContext() To Work
  44. 44. To Work• Testing on android platform • Base class that can be extended to support different requirements • You can use this if you need – Test customs Views – Test permissions – Access Resources To Work
  45. 45. To Work• Testing on android platform – Assertions View • Aligned in several ways • View agrouped • Is on screen • Has specific screen coordinates To Work
  46. 46. To Work• Testing on android platform – Simulate complex user behavior – Use the methods to generate touch events • clickView() to simulate touching • dragX() to touch and drag • longClick() for touching and holding • scrollX()to simulate scrolling • tapView() to touch and release quickly To Work
  47. 47. To Work• Testing on android platform – Mocks – All classes has non functional methods • MockApplication • MockContentResolver • MockContext • MockDialogInterface • MockPackageManager • MockResources To Work
  48. 48. To Work• Testing strategy for browser applications in both platforms(iOS and Android) – The content is easy to test automatically – Use pattern-matching to check responses – Use complex assertions – Use Xpath o css selectors to locate elements – Newer Mobile Web Browsers support Scripting & AJAX To Work
  49. 49. To Work• Testing strategy for browser applications in both platforms(iOS and Android) – Testing using HTTP calls is inefficient – To automate, use tools such as: • WebDriver (with custom HTTP headers) • Selenium RC – On-device testing is possible but not ideal (yet) To Work
  50. 50. To Work• Testing strategy for browser applications in both platforms(iOS and Android) – Use selenium/webdriver • Native keyboard & mouse events • Same Origin Policy / XSS / HTTP(S) • Pop-ups, dialogs – Basic Authentication – Self-signed certificates – File upload/download To Work
  51. 51. To Work• Use selenium/webdriver – Clean API – You can use your prefered language • Python • Ruby • Java • C# – You need change one line to change of platform To Work
  52. 52. To Work• Testing strategy for browser applications in both platforms(iOS and Android) – PageObject pattern – Encapsulate Objects on a page – Provide useful functions e.g. searchFor – Separate things that change from business logic To Work
  53. 53. To Work• Best Practice – Use Oracle Testing • Mobile applications are derivated from web or client applications • All mobile banking applications consume services supplied by existing applications To Work
  54. 54. To Work• Best Practice – Use Rule-based testing • can be coded to detect ‘good’ and ‘bad’ content • Detect incompatible content • Create rules from bug reports, server logs, etc • Use manual testing to verify rules, if unsure • Helps developers of new applications to deliver good quality content quickly To Work
  55. 55. To Work• Best Practice – Model your application – You can use Model Based Testing • Utilizes formal models that model the SUT from the perspective of testing usually at a high level of abstraction To Work
  56. 56. To Work• Best Practice – Consider testing manually • When working with legacy / external development • When testing the UI and UX (User Experience) • To complement Automated Tests To Work
  57. 57. To Work• Best Practice – Continuous integration and Continuous testing • Execute your test frequently • Use pipelines in your CI server To Work
  58. 58. To Work• Best Practice – Continuous integration and Continuous testing • Each code submission automatically built • Automated tests can run and report results • Teams share a view of project status • Changes are routinely integrated • Fewer & smaller merge conflicts To Work
  59. 59. To Work• Best Practice – Use code analizers • Devices have limited memory • Clients use all the available memory • Little memory left for code coverage • Inclusion patterns up to method level To Work
  60. 60. To Work• Best Practice – Use code analizers – Detects faults in • Event handler / event listeners • Missing / incorrect GUI elements – Long running tests exposing memory leaks – Code coverage • also for Unit tests To Work
  61. 61. To work• General tips • Test code should be of Production quality • Import only those classes that you need. Avoid import abc.* • Use xPaths with caution. Do NOT use indexes. • Keep test data separate from test scripts. • Use private / protected member variables / methods. Make them public only when absolutely essential. • Keep test intent separate from implementation. • Do not simply copy / paste code from other sources without understanding it completely. • Duplicating CODE is NOT OK. To work
  62. 62. To work• Next steps – The cloud • Very useful when you have a lot of tests • Private cloud • Cross-browser testing – Service for selenium is available – Execute your tests in the cloud or in your test enviroment To work
  63. 63. Thats All folks
  64. 64. Contact• Christian Ramírez – chramirez@certum.com – @chrix2 – www.certum.com – Mail Address • Rodolfo Gaona 86-f, Lomas de Sotelo CP 11200 Miguel Hidalgo México DF México Contact

×