Mobile Testing at Gilt


Published on

The slides from Gilt Senior Software Engineer Matt Isaacs' presentation for the Brooklyn iOS Developer Meetup, April 2014.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mobile Testing at Gilt

  1. 1. Mobile Testing at Gilt Matt Isaacs @haveahennessy Gilt
  2. 2. What is Gilt?
  3. 3. Luxe brands up to 60% off
  4. 4. Inventory Changes Daily Sales last 36 hours.
  5. 5. Sales start at noon ET. Bonus sales at 9PM, Sundays and Wednesdays.
  6. 6. Gilt Mobile The simplified story
  7. 7. iPhone • iPad • Android
  8. 8. Developers focus on building the App(s). QA handles testing - All of it. No automation. Informal Process
  9. 9. When feature sets were simple. When the team was small. When the codebase was small. No Big Deal
  10. 10. – Some App Store Reviews “Perfect App !!! Well done” “Awesome app! Love it!” “OMG! Amazing!” “Your app is great and keeps getting better."”
  11. 11. We added more features. The codebase grew. The team grew. Some time passed
  12. 12. 5-stars become harder to get You can’t please everyone - But still…
  13. 13. Informal process doesn't scale
  14. 14. Add some structure CI + Nightlies with Jenkins. Dogfooding with Hockey. Code + git branching conventions.
  15. 15. And tests…
  16. 16. – NSHipster “Objective-C developers have, for the most part, remained relatively apathetic to Unit Testing.”
  17. 17. How can this be? Objective-C is statically typed. The compiler is awesome. TDD antipatterns - Cocoa makes heavy use of singletons.
  18. 18. ~40% revenue comes from native mobile. Bad reviews hurt more than ever. Increased pressure on QA. Mounting cost of issues
  19. 19. So help out QA Write some tests!
  20. 20. Bad habits are hard to break Make time - Monthly testing hack-days. Visibility - Make a scene when tests catch issues. Gentle, but firm approach.
  21. 21. Integration Tests UI + Functional tests. Notoriously difficult. Provides the most benefit for QA.
  22. 22. Appium Selenium webdriver for native mobile. Actively developed. Open source.
  23. 23. Test Appium Instruments App HTTP Unix Sockets DTrace + Magic
  24. 24. Accessibility makes it work. Elements located via accessibility labels. Be careful with container views. UIAccessibilityIdentifier is for tests.
  25. 25. Why we chose Appium We’ve already built Selenium infrastructure. We already have Selenium skills. No SDK to compile in.
  26. 26. – Someone at Gilt “Selenium is still too flaky. You can't trust the results. We need more dependable tests"
  27. 27. When should I wait? How long should I wait for? Waiting
  28. 28. Where am I? Is it where I should be? When should I be checking this? State
  29. 29. Staging or Production? Painful issues with either. Environment
  30. 30. Convention on top of Actions and Locators. Page validated during construction. Actions return new page objects. Page Objects
  31. 31. When to wait? - Page object construction. Page objects represent state. Actions → State transitions Solved!
  32. 32. Sore points. Accessibility. Overlays and pass-throughs. Partially obscured controls.
  33. 33. End of the day You’ll need some process eventually. It’s never too early - or late. TDD is not a religion.
  34. 34. Thanks @gilttech !