Proves tancades de Google Play: què hem après creant Kleos Music

Fa un mes vam començar a construir Kleos Music amb una idea molt senzilla: un reproductor de música local no hauria de semblar una versió inferior d'una aplicació de streaming.

Volíem que la música que ja tens al telèfon pogués oferir una experiència completa. Lletres, portades, metadades, widgets, notificacions i cerca, sense subscripcions, funcions innecessàries ni una connexió a Internet només per reproduir la teva pròpia música.

Després va arribar la part menys glamurosa: les proves tancades de Google Play.

Abans que una aplicació Android pugui arribar a producció, Google Play exigeix una prova tancada amb almenys 12 testers inscrits durant el període requerit. Sobre el paper sembla senzill. A la pràctica, trobar 12 persones és només el principi.

Per a Kleos Music, vam trobar la majoria dels nostres testers a través de comunitats de tester-for-tester, o T4T, on els desenvolupadors proven les aplicacions dels altres, i a través de r/ClosedTesting a Reddit. Era una manera pràctica d'aconseguir que les primeres persones utilitzessin l'aplicació fora dels nostres propis dispositius.

Però hi ha una diferència important entre tenir 12 testers i provar realment una aplicació.

Un tester pot inscriure-s'hi i no tornar a obrir l'aplicació. Un altre pot utilitzar-la una vegada i desaparèixer. Algú pot trobar un error i no arribar a comunicar-lo mai. Per això, dependre exactament del nombre mínim de testers és arriscat. La gent deixa de participar, s'oblida de la prova o simplement deixa d'estar activa. Tenir un cert marge per sobre del mínim dona més espai al procés.

I, sobretot, les proves reals canvien la manera com veus el teu propi producte.

Quan construeixes una aplicació tu mateix, ja saps com funciona. Saps on són els ajustos. Saps quin botó obre cada pantalla. Saps que existeix un gest determinat perquè tu mateix l'has programat.

Un tester no té aquest coneixement.

Aquesta diferència va fer aparèixer coses que probablement hauríem passat per alt.

Les diferents versions d'Android es comportaven de manera diferent. Les pantalles tenien proporcions i densitats diferents. Els widgets necessitaven ajustos. Les notificacions multimèdia tenien problemes de compatibilitat. La coincidència de metadades es comportava de manera diferent amb biblioteques musicals poc habituals. Fins i tot una cosa tan senzilla com explicar com escanejar manualment una carpeta de música va resultar menys evident del que pensàvem.

Cada descobriment es convertia en part del cicle de desenvolupament.

Utilitzar l'aplicació. Trobar alguna cosa. Comunicar-ho. Arreglar-ho. Crear una nova versió. Tornar a provar.

Durant la prova tancada, Kleos Music va passar per build rere build. Alguns canvis eren petits. D'altres afectaven parts senceres de l'experiència. El més important no era el nombre de builds. Era que cada build representava alguna cosa que havíem après gràcies a l'ús real.

També ens va fer pensar d'una altra manera sobre un altre projecte de Kleos, Kleos Breathe.

Breathe ens va ensenyar l'altra cara de les proves tancades. El problema no era que haguéssim descobert centenars d'errors. Era gairebé el contrari: no hi havia prou interacció. Hi havia poc feedback, pocs problemes reportats i, per tant, molt poques proves que el producte connectés amb els testers.

Aquesta experiència va canviar la nostra manera d'entendre les proves.

Una prova tancada no és només una barrera que has de superar abans d'arribar a producció. També pot funcionar com un filtre per al mateix producte.

Si la gent utilitza repetidament una aplicació molt poc, no hi torna i té poc a dir sobre ella, la resposta no sempre és buscar més testers. De vegades és el mateix producte el que s'ha de replantejar.

Aquesta diferència va ser important per a nosaltres. Kleos Music generava preguntes perquè la gent realment l'estava utilitzant. Breathe generava molt menys senyal perquè hi havia molta menys interacció. Les dues experiències van ser útils, però de maneres completament diferents.

Google també demana als desenvolupadors que expliquin què va passar durant la prova tancada quan sol·liciten accés a producció. Això inclou com es van aconseguir els testers, com van utilitzar l'aplicació, quin feedback van donar, què es va canviar a partir d'aquest feedback i per què considerem que l'aplicació està preparada per a producció.

Per a nosaltres, aquestes preguntes no eren simplement un altre formulari. Eren gairebé un resum del procés de desenvolupament.

Podíem parlar de converses reals amb testers, problemes reals descoberts en dispositius reals i correccions reals publicades com a resposta.

Això va ser probablement el més valuós que vam obtenir de les proves tancades de Google Play.

Ens van obligar a qüestionar suposicions que ni tan sols sabíem que teníem.

Pensàvem que determinades pantalles s'adaptarien correctament. No sempre va ser així.

Pensàvem que certes interaccions serien immediatament evidents. No sempre ho van ser.

Pensàvem que el nostre sistema de metadades es comportaria igual amb totes les biblioteques musicals. Les col·leccions reals van demostrar ser més complexes.

I pensàvem que, si una cosa tenia tot el sentit per a nosaltres, també en tindria per a tothom.

No és així.

Per això provar aplicacions Android és molt més que comprovar si una aplicació es tanca inesperadament. Una bona prova tancada revela la distància entre el que el desenvolupador volia construir i el que l'usuari realment experimenta.

Per a kleosvic, aquesta distància és on va passar bona part de la feina útil.

L'objectiu mai va ser simplement arribar al requisit dels 12 testers i prémer el botó de producció. L'objectiu era utilitzar el període abans del llançament per fer que el producte fos millor.

Vam començar el procés pensant que estàvem provant una aplicació.

El vam acabar provant les nostres pròpies suposicions sobre l'aplicació.

I això va resultar ser molt més útil.