• Save
 

Like this? Share it with your network

Share

Mobile testing

on

  • 551 views

 

Statistics

Views

Total Views
551
Views on SlideShare
544
Embed Views
7

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 7

http://www.linkedin.com 6
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mobile testing Presentation Transcript

  • 1. Introduction to Mobile Testing Christian RamírezMadrid, 4th-7th of June 2012
  • 2. Context •What is the challenge? –Todays mobile applications are being used on smartphones •Web •Native –Manual testing is inefficient and doesnt scale –All platforms are differentMadrid, 4th-7th of June 2012
  • 3. Design Considerations
  • 4. Design Considerations •We need look beyond of the evident Sword of omens, give me sight beyond sightMadrid, 4th-7th of June 2012
  • 5. Design Considerations •You don’t need to reinvent the wheel –Same domain same rules –ReuseMadrid, 4th-7th of June 2012
  • 6. Design ConsiderationsMadrid, 4th-7th of June 2012
  • 7. Design Considerations •Round 1 –Traditional apps VS Mobile AppsMadrid, 4th-7th of June 2012
  • 8. Design Considerations •Round 2 Native Apps vs Web AppsMadrid, 4th-7th of June 2012
  • 9. Design Considerations •Manual testing is inefficient, but necessary. •Test automation is logical solution. –Use test automation correctlyMadrid, 4th-7th of June 2012
  • 10. 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 pioneerMadrid, 4th-7th of June 2012
  • 11. Test Design
  • 12. Test Design •Testing FrameworkMadrid, 4th-7th of June 2012
  • 13. Test Design •Divide and conquer –Separate all parts as much as possibleMadrid, 4th-7th of June 2012
  • 14. Test Design •Promote the reuse –Design for reuse –Design with reuse –Improve your productivity –Reuse among platforms and domains •Business logicMadrid, 4th-7th of June 2012
  • 15. Test Design •Testability –The solution to all problems •the quality of a software design that allows for automated testing in a cost-effective manner.Madrid, 4th-7th of June 2012
  • 16. 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 codeMadrid, 4th-7th of June 2012
  • 17. Test Design •TDD –Unit tests •Written by programmers •For programmers •In a programming languageMadrid, 4th-7th of June 2012
  • 18. Test Design •BDDMadrid, 4th-7th of June 2012
  • 19. Test Design •BDD –Beer Driven Development???Madrid, 4th-7th of June 2012
  • 20. 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 DSLsMadrid, 4th-7th of June 2012
  • 21. Test Design •BDD –Use text scenarios •Given •When •Then –Defining stepsMadrid, 4th-7th of June 2012
  • 22. Test Design •BDD –DSL •Almost programming language dedicated to a particular problem domain –In mobile 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 DSLMadrid, 4th-7th of June 2012
  • 23. To Work
  • 24. To Work •Test Automation –Almost always is possible automate all tests of a mobile applicationMadrid, 4th-7th of June 2012
  • 25. To Work •Test Strategy –Unit Test –Internal logic –Gui Test –Usability –Navigation –Always consider varied end user expectationsMadrid, 4th-7th of June 2012
  • 26. 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 testsMadrid, 4th-7th of June 2012
  • 27. To Work •Data collection –Screenshots •DDMS for Android –Logs •adb shell for AndroidMadrid, 4th-7th of June 2012
  • 28. To Work •Test StrategyMadrid, 4th-7th of June 2012
  • 29. 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 clientMadrid, 4th-7th of June 2012
  • 30. To Work •Testing on android platform –SDK integrates a testing framework –It’s based on junit3 –Supports •Unit tests •Functional tests •Activity tests •MocksMadrid, 4th-7th of June 2012
  • 31. 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 @UiThreadTestMadrid, 4th-7th of June 2012
  • 32. 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()Madrid, 4th-7th of June 2012
  • 33. To Work •Testing on android platform –Some methods should be avoided and will throw exceptions if calledMadrid, 4th-7th of June 2012
  • 34. 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()Madrid, 4th-7th of June 2012
  • 35. 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 ResourcesMadrid, 4th-7th of June 2012
  • 36. To Work •Testing on android platform –Assertions View •Aligned in several ways •View agrouped •Is on screen •Has specific screen coordinatesMadrid, 4th-7th of June 2012
  • 37. 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 quicklyMadrid, 4th-7th of June 2012
  • 38. To Work •Testing on android platform –Mocks –All classes has non functional methods •MockApplication •MockContentResolver •MockContext •MockDialogInterface •MockPackageManager •MockResourcesMadrid, 4th-7th of June 2012
  • 39. 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 & AJAXMadrid, 4th-7th of June 2012
  • 40. 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)Madrid, 4th-7th of June 2012
  • 41. 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/downloadMadrid, 4th-7th of June 2012
  • 42. 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 platformMadrid, 4th-7th of June 2012
  • 43. 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 logicMadrid, 4th-7th of June 2012
  • 44. To Work •Best Practice –Use Oracle Testing •Mobile applications are derivated from web or client applications •Someone mobile applications consume services supplied by existing applicationsMadrid, 4th-7th of June 2012
  • 45. 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 quicklyMadrid, 4th-7th of June 2012
  • 46. 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 abstractionMadrid, 4th-7th of June 2012
  • 47. To Work •Best Practice –Consider testing manually •When working with legacy / external development •When testing the UI and UX (User Experience) •To complement Automated TestsMadrid, 4th-7th of June 2012
  • 48. To Work •Best Practice –Continuous integration and Continuous testing •Execute your test frequently •Use pipelines in your CI serverMadrid, 4th-7th of June 2012
  • 49. 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 conflictsMadrid, 4th-7th of June 2012
  • 50. 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 levelMadrid, 4th-7th of June 2012
  • 51. 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 testsMadrid, 4th-7th of June 2012
  • 52. 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.Madrid, 4th-7th of June 2012
  • 53. 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 enviromentMadrid, 4th-7th of June 2012
  • 54. The FutureMadrid, 4th-7th of June 2012
  • 55. The Future •Domain Specific Based Testing •One test -> all platformsMadrid, 4th-7th of June 2012 To Work
  • 56. Thats All folks
  • 57. Contact •Christian Ramírez •chrix2@gmail.com –@chrix2Madrid, 4th-7th of June 2012