Retour d'expérience sur les tests de pré publication

1. La publication des applications mobiles vue par les
opérateurs
Document confidentiel

2. SOMMAIRE
1. Historique
2. Les différentes Store
3. Un parc de terminaux pléthorique
4. Les principales contraintes des Stores
5. L’intégration des contraintes de pré- publication dans les projets
6. Des tests simples et reproductibles
7. Quelques chiffres (retour d’expérience)
8. Les perspectives des tests avant publication
9. Questions / Réponses
Document confidentiel page 2

3. Les tests de qualification se doivent d’être réalisés en amont du projet d’une
application donnée. En effet, cette nécessité ultime, dite de « pré-
publication », permet de nous assurer de la parfaite corrélation d’une application
avec les recommandations de chaque « Store ».
Quel recul a-t-on depuis 2007 ?
Document confidentiel page 3

4. Historique
2007 – Lancement de l’iPhone
2008 – Lancement du premier mobile sous Android
2010 – Lancement des mobiles sous Windows 7
2011 – Lancement du BlackBerry App World
2009 – Montée en compétence sur les stores
2010 – Mise en place des comptes de distribution
2010 – Mise en place des tests standards de publication
2011 – Suivi des évolutions des Stores et montée en charge des tests de publication multi OS
2012 – Montée en puissance des rythmes de publication
Document confidentiel page 4

5. Les stores (1/2)
Document confidentiel page 5

6. Les stores (2/2)
Google Nokia Windows Blackberry
Android Market OVI Store MarketPlace AppWorld
Market 10K Apps 5500 contents 250 apps 2000 apps in US,
12 apps in FR
2 Million 59 million 30 Million
compatible users compatible users compatible users
Developper Fee $25 $200/year $99/year $200 for 10 apps
submission
Fee per app - - $99 per app -
submission 5 app are free
Opening an Google account Publisher Account Credit Card Paypal
account with Google Checkout
Windows Live ID Blackberry
account
Membership ID
Credit card
Application NO N/A YES (10 days YES
Approuval needed)
Required
Payment System Credit card Credit Card Credit Card Paypal
Purchase voucher Carrier Billing
Nokia Money
Revenue sharing 70% Editor 70% Editor 70% Editor 80% Editor
on non-free apps
30% Google 30% Nokia 30% Microsoft 20% RIM
Document confidentiel page 6

7. Un parc de téléphones pléthorique (1/2)
Apple Samsung Bada
Windows Phone 7 BlackBerry
Document confidentiel page 7

8. Un parc de téléphones pléthorique (2/2)
HTC
Samsung
LG
Sony Ericsson et Sony Motorola
37 appareils sous Android (mobiles et tablettes)
Document confidentiel page 8

9. Les principales contraintes des Stores
• Apple édite à l’intention des développeurs un App Store Review Guideline
• Google Play réalise un contrôle a posteriori des applications
• Microsoft a des règles écrites mais peu claires
• Samsung n’a pas documenté ses recommandations
• RIM exerce un contrôle non documenté et opaque
• OVI (Nokia) n’a pas de recommandation mais réalise de simples contrôles
Document confidentiel page 9

10. Intégrer les règles de pré-publication dans les projets
• Les tests avant publication ne sont pas des tests de qualification
• Définition du process des tests avant publication
• Intégration par les teneurs du projet des tests
• Formalisation écrite des tests qui à réaliser
• Utilisation des outils de tests (Quality Center, Jira, Mantis, Bugzilla…)
• Détermination de KPI sur les tests avec objectifs
Document confidentiel page 10

11. Des cas de tests simples, aisément reproductibles
• Installation de l’application
• Lancement sous 3 modes de connexion (mode avion, WiFi, réseau mobile)
• Acceptation de la géolocalisation (si l’application en fait la demande)
• Mode d’affichage en 12h/24h
• Connectivité aux réseaux sociaux
• Test du moteur de recherche
• Rubrique « à propos »
• « User experience » (Ergonomie, design, éditorial)
• Tests fonctionnels sur toutes les rubriques de l’application
Exemple de rapport de tests
Exemple de cas de tests
Document confidentiel page 11

12. Exemple de motifs de rejet Apple
2.23
Your app does not follow the iOS Data Storage Guidelines, which is not in compliance with the App Store Review Guidelines.
Your app's backup allotment exceeds the guideline limits. You are backing up the downloaded data to iCloud instead of having the user download it again when
necessary.
The iOS Data Storage Guidelines specify:
"1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the /Documents directory
and will be automatically backed up by iCloud.
2. Data that can be downloaded again or regenerated should be stored in the /Library/Caches directory. Examples of files you should put in the Caches directory
include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
3. Data that is used only temporarily should be stored in the /tmp directory. Although these files are not backed up to iCloud, remember to delete these files when you
are done with them so that they do not continue to consume space on the user’s device.
4. Use the "do not back up" attribute for specifying files that should remain on device, even in low storage situations. Use this attribute with data that can be
recreated but needs to persist even in low storage situations for proper functioning of your app or because customers expect it to be available during offline use. This
attribute works on marked files regardless of what directory they are in, including the Documents directory. These files will not be purged and will not be included in
the user's iCloud or iTunes backup. Because these files do use on-device storage space, your app is responsible for monitoring and purging these files periodically."
For example, only content that the user creates using your app, e.g., documents, new files, edits, etc., may be stored in the/Documents directory - and backed up by
iCloud.
Temporary files used by your app should only be stored in the /tmp directory. Please remember to delete the files stored in this location when the user exits the app.
Data that can be recreated but must persist for proper functioning of your app or because customers expect it to be available for offline use should be marked with
the "do not back up" attribute. For more information, please see Technical Q&A 1719: How do I prevent files from being backed up to iCloud and iTunes?.
It would be appropriate to revise your app to meet the requirements of the iOS Data Storage Guidelines.
For discrete code-level questions, you may wish to consult with Apple Developer Technical Support. Please be sure to include any symbolicated crash logs,
screenshots, or steps to reproduce the issues when you submit your request.
Document confidentiel page 12

13. Exemple de motifs de rejet Microsoft
Document confidentiel page 13

14. Quelques chiffres (1/2)
• Un nombre de cycles de tests déterminés
• Des KPI pour objectif
• Une vision globale sur ce qui est réalisé
Document confidentiel page 14

15. Quelques chiffres (2/2)
• L’activité semestrielle est mesurée pour améliorer le cycle de production
• Une sensibilisation des porteurs de projet en amont
• Une vue globale sur ce qui est fait sur les plateformes
Document confidentiel page 15

16. Perspectives
Menaces Opportunités
• Confusion des tests de pré publication vs • Mise en place d’un process
qualification • Etablissement de KPI
• Respect du TTM (Time to market) • Mesure précise de l’activité
• Non compréhension des rapports de
tests.
• Connaissances multi plateformes • Le budget des tests n’est pas
• Tests sur un grand parc de mobiles et forcément prévu
d’OS • Trop de bugs sont encore remontés
• Eviter des commentaires négatifs sur les • La connaissance des contraintes des
Stores « stores » est ignorée en amont du
projet
Forces Faiblesses
Document confidentiel page 16

17. Merci
Document confidentiel page 17