Barcamp Degetel

Document confidentiel

La publication des applications mobiles vue par les opérateurs

Document confidentiel

SOMMAIRE

page 2

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 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 ?


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


Les stores (1/2)


Google

Android Market

Nokia

OVI Store

Windows

MarketPlace

Blackberry

AppWorld

Market 10K Apps

2 Million

compatible users

5500 contents

59 million

compatible users

250 apps

30 Million

compatible users

2000 apps in US,

12 apps in FR

Developper Fee $25 $200/year $99/year $200 for 10 apps

submission

Fee per app

submission

- - $99 per app

5 app are free

-

Opening an

account with

Google account

Google Checkout

account

Credit card

Publisher Account Credit Card

Windows Live ID

Paypal

Blackberry

Membership ID

Application

Approuval

Required

NO N/A YES (10 days

needed)

YES

Payment System Credit card Credit Card

Purchase voucher

Nokia Money

Credit Card

Carrier Billing

Paypal

Revenue sharing

on non-free apps

70% Editor

30% Google

70% Editor

30% Nokia

70% Editor

30% Microsoft

80% Editor

20% RIM

Les stores (2/2)


Un parc de téléphones pléthorique (1/2)

Apple

Windows Phone 7 BlackBerry

Samsung Bada


Un parc de téléphones pléthorique (2/2)

37 appareils sous Android (mobiles et tablettes)

HTCSamsung

Sony Ericsson et Sony

LG

Motorola


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


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


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 testsExemple de cas de tests


Exemple de motifs de rejet Apple2.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.


Exemple de motifs de rejet Microsoft


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é


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


Menaces Opportunités

Forces Faiblesses

• Le budget des tests n’est pas forcément prévu

• Trop de bugs sont encore remontés• La connaissance des contraintes des

« stores » est ignorée en amont du projet

• Mise en place d’un process• Etablissement de KPI• Mesure précise de l’activité

• Connaissances multi plateformes• Tests sur un grand parc de mobiles et

d’OS• Eviter des commentaires négatifs sur les

Stores

• Confusion des tests de pré publication vs qualification

• Respect du TTM (Time to market)• Non compréhension des rapports de

tests.

Perspectives


Merci

Barcamp Degetel

Documents

Transcript of Barcamp Degetel