Google gaat nieuwe Android-ontwikkelaars verplichten om apps eerst te testen

Google gaat nieuwe ontwikkelaars van Android-apps voortaan verplichten om deze te testen alvorens ze in aanmerking komen voor publicatie in de Google Play Store. De app moet minstens twee weken lang door twintig gebruikers worden getest, schrijft Google.

De aanpassing gaat vanaf 13 november in en geldt voor Play Console-accounts die na die datum zijn aangemaakt. Het is vanaf dan niet langer optioneel voor nieuwe ontwikkelaars om de testtools van Google te gebruiken alvorens ze een applicatie ter publicatie indienen. Google stelt dat ontwikkelaars hiermee crashes en bugs kunnen verhelpen, en voor de release al wat feedback van gebruikers kunnen verzamelen. Op die manier wordt de gebruikerservaring verhoogd, en de kans op negatieve reviews verlaagd, aldus Google. Bestaande ontwikkelaars worden voorlopig nog niet verplicht om hun applicaties eerst te testen.

Daarnaast wil Google meer tijd gaan investeren in het beoordelen van applicaties alvorens ze worden toegelaten in de Google Play Store, schrijft TechCrunch. Google wil zo beter kunnen inschatten of apps voldoen aan de richtlijnen en gebruikers niet misleiden of bedriegen, zowel binnen als buiten de Play Store. Google stelt dat het beoordelen van 'een klein aantal' apps hierdoor langer kan duren. Het zou voornamelijk gaan om apps die zich richten op kinderen, of bepaalde machtigingen vereisen.

Reacties (108)

[- peter -]

Vind t wel ver gaan dat je verplicht een gesloten test moet gaan uitvoeren. Ik snap ook wel dat dit de kwaliteit omhoog moet brengen, maar vind t wel ingrijpend als dev.

[moonlander]

Lijkt mij meer dan normaal.

[josttie]

Mij lijkt dit niet normaal. Ik heb weleens voor de grap iets in de store gezet, ik zou niet hebben geweten waar ik 20 testers vandaan zou moeten halen.
Voor een daadwerkelijk bedrijf lijkt mij dit anders. Waar ik werk hebben wij een app vernieuwd voor een bedrijf en daarna ruim 100 mensen in closed testing gezet, "friends and family" (ofwel collega's + nog een paar). Dat gaf ons goede feedback en zo konden wij die app verbeteren. Na een tijdje hebben we de groep vergroot en al met al een half jaar later daadwerkelijk live gegaan toen we feature complete waren, maar dan heb je het wel over een groot bedrijf met al bestaande klanten.
Dit zou voor mij persoonlijk als ik zou willen rondklooien en iets geinigs in de store wil zetten veel te veel rompslomp zijn.

[depeje]

Misschien dat ze juist die grap apps willen tegenaan, om de kwaliteit van de hele store omhoog willen brengen. Dat zorgt voor minder ruis voor de mensen die een app zoeken.

[yobikap]

Er zijn tegenwoordig bedrijven die gespecialiseerd zijn in crowd testing.

Ze zijn niet duur en ook niet goedkoop, maar geeft je wel inzicht in de eventuele feedback, je kan zelf kiezen hoeveel users je app mogen gaan testen.

[lilmonkey]

Dit zou voor mij persoonlijk als ik zou willen rondklooien en iets geinigs in de store wil zetten veel te veel rompslomp zijn.

Mooi, daar heeft ook praktisch niemand iets aan. Fijn om te horen dat Google's nieuwe beleid nu al z'n vruchten afwerpt!

[Strebor]

Mij niet. De overhead voor het maken en publiceren van apps in de appstores wordt steeds groter en onredelijker. Voor ons de reden om apps als Progressieve Web Apps uit te brengen. Dan hebben wij veel meer de touwtjes in handen. Eventueel ingepakt in een schilletje die in de appstore geplaatst kan worden. Maar hoe meer van dit soort regels kleine ontwikkelaars belasten, hoe minder app ontwikkelaars en apps er overblijven. Dat is vast wat Google wil.

[thePiett]

Native apps gaan toch sowieso grotendeels verdwijnen denk ik, het meeste zal in je browser of als een PWA achtige app gaan draaien. Lijkt me prima, veel apps zijn overbodig en brengen alleen maar extra ontwikkelingskosten met zich mee.

[84hannes]

Ooit was het een wedstrijdje tussen Apple en Google wie de meeste apps in de store had. Ik ben blij dat die tijd voorbij is en kwaliteit belangrijker is geworden dan kwantiteit. Ik zit op veel apps helemaal niet te wachten, zeker sinds ik een password manager gebruik maak ik vaak liever een account aan voor een website dan dat ik een app download (beide manieren om bijvoorbeeld voorkeuren op te slaan in een app).

[bommel]

Als een app alleen maar een heel dun schilletje is rondom een website of PWA (zoals @Strebor omschirjft dan is de toegevoegde waarde mi nul. Eerder irritant dan dat het mij als gebruiker een betere ervaring geeft. Vanuit ontwikkelaars standpunt begrijp ik dat volledige controle en niet afhankelijk zijn van een appstore grote voordelen geeft maar ik heb liever een (volwaardige) app dan een PWA.

[Strebor]

Als jij het verschil niet kunt merken tussen een schil die een PWA binenhaalt, die met local storage en functionaliteit de app draaiende houdt, ook als je offline bent, wat is dan voor jou de irritatie?

De enige reden om een PWA in een schil te wikkelen en met veel overhead weer in de appstores te plaatsen, is vindbaarheid van de app vergroten en voor het installatiegemak voor de gebruiker.

[latka]

Het is traaaaag en werkt soms gewoon kak omdat er onvoldoende getest is met de 'offline' werking. Of de initiele start is niet getest voordat er van alles gecached is.

[Strebor]

Jouw ervaringen zijn anders dan de mijne

En bovendien heeft een slecht geschreven op je device draaiende app hier ook last van, wanneer deze offline is voor hij zijn storage gevuld heeft, en de initialisatie en periodieke sync niet goed is ingericht.

[Reactie gewijzigd door Strebor op 23 juli 2024 00:10]

[latka]

Heb een tijdje cordova apps gemaakt.... het was bewerkelijk, maar wel de snelste route naar multiplatform. Dat ontegezeggelijk. Alleen moet je wel weten wat je doet en niet iedereen in het team is in staat iets goeds te maken hiermee.
Als je de juiste mensen hebt is het geweldig en een stuk goedkoper dan allerlei native apps bouwen.

[bommel]

Mwah het verschil is dat als er alleen een app is het dan het primaire product is en dan wel goed getest wordt. Net als de website die doet het meestal ook wel. Dat extra schilletje wordt vaak als service gezien en niet goed doorgetest.

[bommel]

Dat er geen toegevoegde waarde is, dan kan ik ook naar de website gaan en zoals hieronder al aangegeven dat zo'n app vaak vasthangt vanwege een change aan het backend waar het schilletje niet op bedacht was. Webserver zegt error en schilletje zegt waitcursor om het maar even plat te zeggen.

[h3x4d3c1m4l]

Dat dacht ik een paar jaar geleden ook, maar mobile apps zijn serieus springlevend. Er zijn bij ons nog steeds genoeg aanvragen vanuit bedrijven voor nieuwe apps en nieuwe functies voor bestaande apps en technisch zie je nog steeds nieuwe en verbeterde frameworks verschijnen (React Native, Flutter, Microsoft .NET MAUI).

Ik denk dat je voor een aantal toepassingen best gelijk krijgt, maar web apps (of zelfs PWA) zijn niet altijd handig. Denk aan offline toepassingen, apps die veel caching of speciale dataopslag nodig hebben, apps die afhangen van hoge performance of iets met Bluetooth doen (koppeling met bepaalde IoT-hardware).

Zelfs met het nieuwe WasmGC (kort door de bocht: techniek om te helpen de performance van klassieke programmeertalen en runtimes naar het web te brengen) zijn webapps nog altijd anderhalf keer langzamer dan native apps.

Toegegeven, een aantal van die problemen kun je uiteindelijk in een browser runtime ook best oplossen, maar je ziet dat standaardenmakers en browsermakers niet superhappig zijn op het loslaten van de beperkingen van browsers. Netwerktoegang, USB, Bluetooth, file system access, sensor access, allemaal dingen die beperkt zijn binnen browserruntimes en waar je ook in een "wrapper app" maar moeilijk omheen kunt werken.

[thePiett]

Zeker, heb je helemaal gelijk in! Er zijn genoeg apps die een bestaansrecht hebben met de huidige technologie. Ik denk alleen dat dit wel steeds meer en meer verschuift richting de browser of iets PWA-achtigs, alleen sommige apps die op lokale hardware of een netwerk hangen zullen voorlopig wel native blijven.

[josttie]

Ik denk niet dat die gaan verdwijnen. PWA's zijn over het algemeen een heel stuk lager in kwaliteit en staan verder van de hardware af. Als ontwikkelaar ruik je een pwa in een schil van meters afstand en zijn ze als gebruiker niet fijn in gebruik. Ze zijn alleen goedkoper om te maken, maar ik blijf er als ontwikkelaar graag ver weg van omdat ik meer geef om kwaliteit en ux. Zeker omdat veel bedrijven mobile first en some zelfs mobile only gaan, kun je de ervaring en waarde van native apps niet zomaar onderschatten.

[Mavamaarten]

Inderdaad. Ondertussen word ik elke maand wel lastig gevallen door Google met nieuwe requirements. Een mens zou er bijna PTSD van krijgen, er is gewoon geen ontsnappen aan. Wat ooit begon als een leuk sideproject is nu veranderd in een verplichte uitzoek- en updatesessie elke paar maanden. Sommige verzoeken zijn echt wel redelijk en makkelijk aan te voldoen (alle deceptive behavior policies), sommigen neigen richting het absurde. Dan update je alle libraries naar de laatste versie, krijg je een paar maand later weer een mail dat die deprecated wordt en dat je tegen x datum weer een update moet voorzien.

[teapot]

Ik werd er tureluurs van. En op gegeven moment had ik van het ene op het andere moment geen inkomsten meer, alles geprobeerd maar ik kreeg geen uitsluitsel van google. Voor mij geen playstore meer!

[KSU4reqY]

Consumenten mogen toch gewoon een veilig, up to date en werkend product verwachten? Neem aan dat google dit niet voor de lol doet.

Ik lees dit artikel met verontwaardiging, het komt mij asboluut absurd over dat er schijnbaar genoeg niet geteste apps op de play store staan dat google, dat niet bepaald om de klantenservice bekend staat, het nodig vind om iets basaals als een app testen als harde voorwaarde te stelen en dat het niet meer gewoon als standaad werkwijze aangenomen kan worden.

[Mavamaarten]

Consumenten mogen dat best verwachten. Maar de crux is net dat alles prima zou blijven werken moest Google er niet voor zorgen dat je constant op een bewegend doel zit te mikken. Ik begrijp dat ze de ondankbare taak hebben om een gigantisch platform vrij te houden van rommel-apps en malware. Maar ergens vind ik ze ook wel verantwoordelijk om alles niet zodanig te doen schuiven dat het een ramp wordt om te blijven onderhouden.

Mijn apps zijn beiden voor Wear OS, een simpele wijzerplaat en een soort launcher, met de optie om een donatie te doen via een in-app purchase. Beiden hebben niet eens de internet-permissie. Je wil niet weten hoe veel irrelevante dingen ik al heb moeten doen om een wijzerplaatje werkend te houden. Nee, ik ben geen COVID-app. Nee, ik ben geen nieuws-app. Nee, ik verzamel geen ad-id's. Opeens moet een app verplicht een splashscreen hebben (! een launcher met een splash screen? what?). 4x een update van de billing library. Opeens zijn de requirements voor app icons veranderd. Opeens is mijn privacy policy (voor een app die geen internet permissie heeft, remember?) niet voldoende want zeggen dat je geen data verwerkt is niet genoeg. Of ik even een kopie van mijn ID wil opsturen want ja "verificatie enzo" he.

[Strebor]

Ik snap je punt, maar gebruikers (of een testgroepje van gebruikers voor een kleine app, we zijn immers niet allemaal Netflix) gaan geen security bugs vinden in apps. Enkel functionele issues die in een volgende build eruit gehaald kunnen worden.

Het gaat erom dat Google (en Apple) aan de lopende band tijdens de wedstrijd de spelregels blijven veranderen, met steeds onredelijkere eisen en tijdspaden. De overhead wordt alsmaar groter.

We kregen onlangs van Google de verplichting een nieuwe up-to-date build te maken van een app. We kregen eerst een paar weken het te fixen, maar konden daarna nog 60 dagen uitstel krijgen. Om dat te doen moesten we helaas zo ongeveer de hele app herschrijven, omdat de eisen van Google een upgrade vereisten aan het gebruikte onderliggende platform en dat brak min of meer elk onderdeel van de app. Gevolg: We gaan inderdaad de app herbouwen, maar dan als PWA.

[bommel]

Is de reden daarvoor niet vooral het gebrek aan controle aan Google's kant? Dit klinkt meer als afschuiven naar de ontwikkelaar ipv gedegen controle aan Google's kant.

[DutchHammer]

Ik verbaas me als Operations Engineer elke keer weer over het feit dat developers zo laks zijn met het up-to-date houden van dependencies incl het vervangen ervan als ze deprecated raken. Ik geef toe, het is vast niet het leukste onderdeel van je werk.. Alsof log4shell nooit gebeurd is.

[Mavamaarten]

Dat vind ik een grote assumptie. Daarbij klaagt ook niemand over een minor version bump hier en daar, het probleem is breaking major changes (waardoor je plots vanalles niet meer kan of volledig moet herschrijven) en wijzigende policies, aan een hoog tempo.

Log4shell toestanden zijn sowieso niet echt van toepassing. Dependencies/libraries zijn eigenlijk per definitie helpers rond bestaande API's die Android toelaat om te gebruiken, maar bovenal zijn alle apps sandboxed. Nu zouden vulnerabilities in libraries technisch gezien code execution kunnen toelaten binnenin een eigen app maar wat zou je daaruit winnen? Dat je je eigen gegevens kan uitlezen?

[NoobishPro]

Dit is precies wat ik doe, maar alle nieuwe regeltjes maken het wel steeds lastiger om die schil te blijven onderhouden.

Daarnaast krijg ik bijna wekelijks een mail met veranderingen welke zelden relevant zijn voor mij, waardoor ik nog wel eens wat wil missen en opeens een waarschuwing krijg dat m'n app binnenkort verwijderd gaat worden. En ja, oké, dat ligt aan mij... Maar ik beheer maar één app van één groot product, wat een schil is van de webversie. De meeste updates gebeuren ook zonder de app daadwerkelijk te updaten in de store.

Het lijkt mij in ieder geval ook extreme overhead. Zo nu en dan is er nog wel eens een situatie waar iemand gewoon binnen 1 maand een app wil of een pilot wil draaien met een app alvorens te besluiten er meer geld in te steken of niet en dit soort dingen maken het gewoon lastiger.

Ik draai met mijn app ook pilots maar mijn klanten hebben weinig zin in dit soort gezeur. Die willen gewoon de app kunnen downloaden en er mee doen wat ze er mee moeten doen. Mijn app krijgt deze maand toevallig een nieuwe versie en ik wilde dit op een ander account doen, maar blijf nu denk ik even bij het oude account plakken.

[cricque]

Het probleem is installatie bij een PWA op Apple devices. Maar ik heb al jaren een PWA, het grootste voor velen was notificaties, dat is dit jaar op Apple ook opgelost. Nu alleen nog dat je een install button kan voorzien.
Maar iedereen is nu zo gewend om naar de App store te gaan ... En er zijn genoeg mensen die geen link kunnen intypen of ze typen dit in in de google search bar ofzo. Ze weten niet waar het browser icoon staat (internet dus ...). Het brengt wel een hele hoop andere support problemen mee "van dat werkt niet" ... maar het is altijd te herleiden tot een user probleem. Nu veel hangt ook af van de keuzes, maar als je met "tenants" werkt en subdomeinen dan is een pwa ook niet zo handig, maar daar zijn ook oplossingen voor. Maar heb al bij meerdere bedrijven hun app omgezet naar een pwa.

[SMGGM]

Uiteraard moet er getest worden, maar vind de manier waarop deze verplichting er is vreselijk vervelend. Wij houden gesloten testen los van de Play Store en doen dit via MS App Center.
Onze test in de Play Store is dan nog maar een smoke test die door 1 persoon uitgevoerd wordt.

Door deze verplichting moeten we heel ons testing gaan overzetten naar de Play Store met al zijn toeters en bellen.

[phizzie]

Dat lijkt het, en nu na zo'n 14 jaar is blijkbaar de volwassenheid en aanbod in de play store ver genoeg.
Kijken we naar de functies die appstores overboord gooiden om marktaandeel te forceren(!) zitten Apple en Google (Alphabet) precies op het pad van 15 jaar geleden.

Wilde je in de Microsoft/(RIM)BlackBerry/Samsung/Nokia wereld een applicatie leveren, moesten alle hardware en software combinaties getest worden door een externe partij. Pas met certificatie kon je een applicatie aanbieden. Dat vertraagde enorm en was niet te doen voor een beginnende developer. Mijn BSc en MSc onderzoeken gingen er over - de economische haalbaarheid van een app (met content van derden op licentie) met 1 dev in het pre-appstore tijdperk.
De onderling verschillende functies, configuraties en verdienmodellen inclusief blokkades in de verschillende processen was mijn Master scriptie.
We hollen terug in de tijd, waarin het gesloten marktmodel (dichtgetimmerd door licenties, testen, whatever) uiteindelijk blijkbaar relevantere content oplevert.
In 2009-2010 schreeuwden developers moord en brand om een zojuist ingevoerde drempel van $99 registratie fee bij Apple voor een developer account. Later werd dat een uitbetalingsminimum, alles om crappy devs te weren.
Uit mijn onderzoek kwam onder meer naar voren dat het beoordelen van kwaliteit enorm slecht te doen is met de reviews van 5 sterren. Als je echt wat wilt doen aan de kwaliteit van de content, moet je andere metrics en vindmechanieken toepassen.
Een punt wat nog steeds valide is: Modemerk Louis Vuitton zal nooit naast een Zeeman komen te zitten. Evenzo kiest een kwaliteitsmerk een verkoop netwerk dat omzet maximeert. Zeker daarom zijn er nog steeds apps die iPhone exclusief zijn.

[Snowfall]

Vind het zelf als iOS developer wel normaal. Ik heb echt nog nooit een app gelanceerd zonder dat deze getest werd door anderen.

[StefanJanssen]

Hoevaak schrijf jij apps die heel niche zijn en eigenlijk alleen werken in combinatie met een specifiek model omvormer voor zonnepanelen? Je moet dan heel specifiek mensen gaan zoeken die die omvormer heeft en toevallig ook het juiste OS op de telefoon.

[PaulHelper]

In dat geval moet je denk ik overgaan op los APKs aanbieden. Maar ik ben wel met je eens dat het erg onprettig is voor zulke kleinere toepassingen

[NoobishPro]

In hoeverre maakt dit uit?

Dit is niet iets wat jou is opgelegd door Apple. Ik heb ook nooit een app gelanceerd zonder pilot, maar dat mag ik wel op mijn eigen manier doen...

[UnanyMoose]

Maar Apple test updates ook zelf, bij ons in ieder geval wel. Deze stap van Google komt over dat ze nu hoge eisen stellen en alle verantwoordelijk voor hun ecosysteem naar alle developers gooien

[lepel]

Als ik dan kijk naar shovelware zaken en apps die met reclames van alles beloven maar niets waar maken vraag ik me af of dit niet makkelijk te automatiseren is. Paar emulators die af en toe beetje door je app heen gaan, hoe willen ze zoiets voorkomen?

Dan maak je het alleen legit ontwikkelaars moeilijker terwijl de werkelijk nutteloze apps met weinig moeite toch op de store komen.

[swhnld]

De emulatoren zullen wel Google accounts moeten hebben en inloggen op devices met unieke device id's.
Dus dan moet je of die devices kopen, of goede emulatie software maken met geautomatiseerde testen, waardoor je uiteindelijk toch je app goed test.
Dus doel van beter testen komt dan toch dichterbij dan een frutsel op de computer gelijk live te gooien.

[GertMenkel]

Clickfarms hebben honderden of duizenden smartphones die de hele dag rondklikken in apps en websites op een manier die adverteerders en andere webbedrijven niet kunnen detecteren. Ik denk dat ze "Google Play Instant Launch" als feature gaan aanbieden, betaal je een tientje en dan zorgen zij dat je app op 100 accounts wordt "getest".

Het blijft een stap extra, maar ik betwijfel dat dit het shovelwareprobleem oplost. De mensen die troep in de Play Store willen zetten, werken hier wel omheen.

[FreezeXJ]

Als ie inderdaad 2 weken in test moet staan dan gaan ze alsnog vertraging oplopen, of ze nou gebruikers hebben of niet.

[dog4life]

Als iedereen er 2 weken bij krijgt, is het m.i. geen vertraging meer.

[MacD]

Het probleem is dat any amateur dev dus genaaid wordt terwijl any niet-echt-nette-ontwikkelaar er makkelijk aan ontkomt.

De eerste wilt iets leuks opzetten maar heeft de ondersteuning niet. De tweede (Chinise gacha/clickfarm) app ontwikkelaar kan met gemak dit omzeilen,

[swhnld]

Dat was ook mijn eerste gedachte, maar toen dacht ik, als je vrienden en familie vraagt kom je waarschijnlijk wel aan die 20 testers. Het aantal klinkt haalbaar.

[Sinester]

Ik denk dat als je iets op bijvoorbeeld Reddit post en je app is redelijk gewild dat je makkelijk aan 20 testers kan komen

[kodak]

Aangezien Google ook minder vergaande moeite, zoals een open test, met vergelijkbare of zelfs betere testresultaten heeft ben ik het met je eens. Er lijkt geen enkele noodzaak dat een prive-ontwikkelaar 20 testers moet hebben die ook nog eens allemaal 2 weken lang geregistreerd testen, terwijl er ook minder ingrijpende mogelijkheden zijn.

Het lijkt er op dat Google niet het testen wil verbeteren maar het privé-ontwikkelen wil ontmoedigen. Anders hadden ze de open testen verplicht om geen onnodige drempels op te werpen die niets lijken toe te voegen aan het resultaat.

[Sanghelios]

Ik vind het eerder verbazend dat dat nog niet het geval was.
Zal de kwaliteit alleen maar ten goede komen, want er is nog steeds heel wat rotzooi te vinden waarvan je je afvraagt hoe het ooit in de Play store is geraakt.

[DdeM]

Ik vind het vooral opvallend dat de staat van apps schijnbaar zo slecht is dat Google dit nodig acht.

[Salvatron]

waar haal je 20 testers vandaan?

[Weicool]

Niet! Velen zullen het moeten doen met fake accounts en AI bots

[Reactie gewijzigd door Weicool op 23 juli 2024 00:10]

[Finger]

Xda, github, tweakers, familie, vrienden.

[demonite]

Tjonge wat een kansloze zooi weer. Dus, nu moeten we 19 fake accounts aanmaken en 2 weken wachten voor je een app kan publiceren.. Great

[xFeverr]

Ik neem aan dat je langer bezig bent met het ontwikkelen van een app en dat je gedurende die tijd de app voortdurend aan het testen bent. Volgens mij ben je er al ver dan.

[demonite]

Uiteraard wordt de app getest maar niet 2 weken lang nadat ie gedeployed is en ook niet door 20 man. Wie heeft er nou 20 testers in dienst?

Dus of 19 fake accounts of 19 random personen lastig vallen die verder nul toegevoegde waarde zullen hebben.

[xFeverr]

Slinger jij een nieuwe nooit gepubliceerde app zo de wereld in zonder dat daar iemand gedurende het ontwikkelproces ooit naar gekeken heeft? Als dat zo is, dan willen ze dat niet. Ze willen afdwingen dat je je app in het echt test voordat je hem wereldkundig maakt. En dat lijkt mij als ontwikkelaar ook fijn voordat het gelijk 1-ster reviews regent.

Bedrijfsaccounts lijken uitgesloten te zijn overigens. En dit geldt niet voor app-updates. Enkel voor eerste publicatie van een nieuwe app.

[demonite]

Natuurlijk worden apps uitvoerig getest, maar al ver voordat ze op de playstore terecht komen. Maar zeker niet door 20 man nee, I wish..

Hebben updates dit niet? Mooi, dan kunnen we beginnen met de hello world versie.. Oftwel ik zie nog steeds de logica hier niet van in.

[xFeverr]

Als je een Hello World versie bij 20 man krijgt voor een week, dan kun je net zo goed ook iteraties van je app aan die 20 man sturen. Stuur een bericht naar vrienden en familie, zet een post op GoT of Reddit, en je komt er wel

[TIGER79]

en wat heeft dat dan voor nut ?
Dus er zijn 20 testers nodig om een app te testen ? Die heb je niet dus ik nodig vrienden en familie uit (onprofessioneel !!!), oma ook trouwens die nog nooit een app heeft geïnstalleerd. Vervolgens is de gunfactor hoog natuurlijk dus eenieder geeft aan dat de app ok is. En door is ie !
Als ik naar onze situatie kijk : bedrijf van 50 man, ontwikkelafdeling van 10 ontwikkelaars op 4 verschillende platforms (embedded, cloud, mobile en legacy). Twee testers. Het is al best een club maar no way dat je aan 20 testers komt die daadwerkelijk weten en begrijpen "wat" ze aan het testen zijn. Misschien wel een kans voor Verkoop om een keer te weten wat ze verkopen wel een heeeeeele dure kans natuurlijk, want die jongens moeten het land in zijn om klanten binnen te halen en niet bij elke app-update daarmee bezig zijn...
Heeft dat geresulteerd in slechte apps de afgelopen 12 jaar dat we ze publishen ? Nou volgens de belangrijkste groep (de klanten) niet nee, volgens onze testers ook niet, en volgens de statistieken (crashes en ANR's anyone?) en de medianen van de Play Store ook niet...
Nee, wat mij betreft slaat Google hier de plank mis. En voordat men weer enkel in zwart en wit kan denken en dan het extreme standpunt aannemen dat testen dus niet nodig is : dat wordt niet beweerd, lees even de post goed door en als laatste : we hebben twee testers...

[Reactie gewijzigd door TIGER79 op 23 juli 2024 00:10]

[Sinester]

Dus er zijn 20 testers nodig om een app te testen ? Die heb je niet dus ik nodig vrienden en familie uit (onprofessioneel !!!)

Waarom is dat onprofessioneel? je wilt toch graag dat mensen testen die er verder weinig mee te maken hebben, maar wel in het dagelijks leven de app zullen gebruiken?

Een App moet je niet door de ontwikkelaar laten testen, maar door mensen die de techniek niet kennen maar er wel gebruik van maken lijkt mij

Zelfde met bijvoorbeeld games in Beta.. die wordt getest door de gamers, niet door de ontwikkelaars

[TIGER79]

Zelfde met bijvoorbeeld games in Beta.. die wordt getest door de gamers, niet door de ontwikkelaars

Nee hoor apps worden getest door de ontwikkelaars, gaan verschillende interne testrondes door (alpha en beta) en vervolgens pas naar externe beta testers (gamers)...
Onprofessioneel als in dat is niet hun professie, hun beroep. Een tester is daarvoor opgeleid, weet bijvoorbeeld precies wat de verwachtingen van het product zijn (aan de hand van de gedefinieerde specs), heeft ook weet van wat de specifieke aanpassingen zijn geweest (change lists) en hoe deze goed te testen, heeft weet van niet enkel de app maar ook het platform (kut-app het geluid doet het niet meer ! hhmm, als je het toestel op Do Not Disturb zet is dat ook de bedoeling) enz enz... Good luck met zo ver krijgen van deze externe 20 testers om uberhaupt zich in te lezen in de specs, SRS of PVE. Buiten het feit dat je dit soort documentatie als bedrijf niet aan een ieder wilt uitdelen...
De beta testing die jij noemt door de gebruikers is letterlijk nooit, NOOIT, een professionele aanpak indien dat niet aanvullend is op eigen testing...
Anders zou je het gewoon monkey-testing kunnen noemen....

trouwens ter aanvulling : ik wil niet eens ingaan op het verschil aan rapportage die je krijgt van een ontevreden gamer tov een ervaren tester Als je daarop je bugs of functionaliteit moet gaan oplossen ben je verder van huis dan dichterbij een oplossing

[Reactie gewijzigd door TIGER79 op 23 juli 2024 00:10]

[ShadLink]

Dit kan wel problemen geven voor kleinere apps, 20 mensen is best veel en niet voor elke ontwikkelaar een mogelijkheid.

[Idunno_WhyNoT]

Ik zit totaal niet in de software, dus ‘pardon my French’… is er mogelijk ergens een soort verband van kleine ontwikkelaars die elkaars software kunnen testen of zo? Zou misschien kunnen helpen met het vinden van testers.

[WoutervOorschot]

Ik denk dat het handiger is om een halfjaar te wachten totdat de EU de play store heeft opengebroken en Android heeft verplicht om sideloading/alternatieve stores fatsoenlijk toe te laten (ipv het afdoen als een developerfeature).

[MrMonkE]

Goed idee

[Robin94]

Misschien in het begin maar in een later stadium niet. Nu krijg ik een mailtje met: "ik wil graag x kunnen, kun je dat toevoegen". Maak ik snel iets in een dag of 2. Even zelf met het handje testen en dan uploaden. Daarna hoor ik wel of het goed is. Zowel van de gebruiker als van anderen. Nu mag men daar 2 weken op wachten. En als het niet helemaal voldoet nog eens twee weken.

[xFeverr]

Zo lees ik het niet. Ik lees het als nieuwe apps die voor de eerste keer gepubliceerd worden in de Play Store, dat die minimaal hieraan moeten voldoen. Updates van een app hoeven niet 2 weken te wachten.

[BrBuggyB]

Hoe is dit bij bijvoorbeeld de Apple en de Microsoft Store geregeld?

[xFeverr]

Daar bestaan dit soort regels niet. Apple zal bijvoorbeeld checken of je app werkt. Je moet ze bijvoorbeeld inloggegevens geven zodat ze meteen aan de slag kunnen. En er wordt een bepaalde kwaliteitsstandaard verwacht. Als je app tijdens de review niet goed werkt, dan gaat het feest gewoon niet door. Ook zullen ze je vragen om uitleg hoe je bepaalde dingen moet uitvoeren.

We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.

Lees er hier meer over: https://developer.apple.com/app-store/review/guidelines/
Het is best een duidelijk verhaal en goed door te lezen. Het is geen super saaie ‘terms of service’ oid

[ShadLink]

idd Apple geeft heel duidelijke info als je App bv crashed of dat een bepaalde functie niet werkt.

[GertMenkel]

Daar moet wel bij worden gezegd dat Apple's menselijk testteam notoir onbetrouwbaar is als het gaat om apps afwijken. Soms worden apps arbitrair afgewezen (en door de volgende reviewer doorgelaten), soms worden testcredentials van een hele andere app gebruikt, in enkele gevallen zagen developers zelfs dat de testers de verkeerde app aan het testen waren. Als je pech hebt, moet je dezelfde app met minimale wijzigingen gewoon door de reviews heen brute forcen wil je je app publiceren.

Er kijkt daadwerkelijk een mens naar, dus in veel opzichten is het beter geregeld dan bij Google, maar het is niet de ideale verificatiestap die Apple belooft. Heel jammer, want er zit veel meer potentie in hun aanpak.

[Qws]

Bij Microsoft was het vroeger (Windows 8 en vroege Windows 10 tijden) heel streng met apps. Alleen Metro en UWP apps konden gedownload worden.

Tegenwoordig staan alle .exe meuk ook op Windows 11 Microsoft Store.

Jammer, maar Microsoft Store is geen veilige plek meer om software te downloaden. Je hebt ook geen idee wat een .exe app allemaal uitspookt achter de schermen..

[Robinio010]

Daar draait Google dan mooi een hoop apps de nek mee om. Dat je een test traject moet doorlopen, prima, logisch. Maar 20 testpersonen regelen, iedere release? Voor eenvoudige apps die zich op een niche richten is dat nogal een gedoe. Evenals de twee weken tijd voor je live staat met je release.
Ik vond Apple al vervelend waarbij het altijd afwachten is hoe lang het duurt voordat je update goedgekeurd werd. Google gaat doodleuk mee doen.

Dit pleit toch steeds meer voor webapps, crossplatform en gewoon zelf in de hand wanneer je een update wilt doorvoeren.

[markg85]

Webapps. Tizen of MeeGo had dat. Goed, dat was een heel OS maar beide zijn behoorlijk dood in de smartphone wereld.

Denk dat het concept van een volledige app in de browser toch nog steeds niet geweldig is. Het verlaagt de ontwikkel drempel wel maar je krijgt ook trage crap apps. En dan heb je nog de geweldige last van app X heeft een bepaalde chrome versie nodig om te draaien, app Y heeft een andere versie nodig.

Stand-alone en cross platform in een framework als Flutter (dart) of Qt (C++) lijkt me veel beter.
of qml, maar daar heb ik geen hoge pet meer van op

[Robinio010]

Ik bedoel met webapps gewoon websites. Zodat je niet meer te maken hebt met een AppStore en bijbehorende regels. Dat de performance wat minder is valt te overzien, de meeste apps zijn relatief eenvoudig.
Enige jammere is dat een webapp qua look and feel nooit geheel overeenkomt met je platform.

[NoobishPro]

Is dat niet nogal een outdated stelling?

Bij Android is het sowieso enorm wishy-washy wat je krijgt betreft UI, maar voor Apple zijn er al heel lang standaarden welke echt niet moeilijk na te leven zijn.

Ik zie het juist andersom eigenlijk. Dat web-apps je vrijheid bieden om dingen te doen welke met enige regelmaat behoorlijk lastig zijn om native klaar te spelen.

Mijn app is bewust een web-app omdat native het alleen maar moeilijker zou maken. Tevens is het retensnel. Alleen het opstarten is al een verlichting voor de gebruikers, welke de app met regelmaat moeten openen 'tijdens de actie'. De app is in like 1 seconde opgestart. To be fair is mijn app ook relatief simpel en vereist het bijna geen native functionaliteiten, maar dit kan volgens mij over de meeste non-gaming apps worden gesteld, no?

[demonite]

Heb je nou een app of een website?
Dat een website niet "native" aanvoelt vind ik zelf geen issue. Wel dat je geen notificaties, nfc, bluetooth etc kan gebruiken, niet offline kan werken en traag is als je server ver weg staat (of te druk is) (scaling en geo repl is niet gratis)

[Vihaio]

Een webapp. Een website die je als app kan laten dienstdoen, waardoor die wel offline werkt notificaties kan versturen en andere functies heeft die normale websites niet hebben.
https://developer.mozilla..._is_a_progressive_web_app

[NoobishPro]

Een webapp in een native schil, waardoor je wél access hebt tot native functionaliteiten.

Een web app kan ook offline werken en hoe ver weg je server staat heeft niets te maken met native of web.

[Pep7777]

Dan mogen ze ook wel verplichten dat ontwikkelaars laten zien dat ze unit tests hebben.

[ExpectedError]

Met voldoende coverage. En ja... code coverage op zich zelf zegt niks, I know....

[StefanJanssen]

Mutation tests draaien geeft veel meer aan

[Pep7777]

Unit tests en coverage zeggen wel degelijk wat : namelijke dat je "kleine" bouwblokjes goed zijn en alle code paden een keer doorlopen zijn. Maar zeggen niet zoveel of je uiteindelijke product aan de requirments voldoet. Daar heb je dan weer integratie testen voor. Haha ik zal stoppen ik kan lang doorgaan over code kwaliteit

[ExpectedError]

Je hoeft niet te stoppen hor. Ikzelf gebruik de code coverage als een manier om te controleren of ik niets vergeten ben om te testen. Mijn grootste probleem met het gebruik van code coverage percentages door "niet developers" is dat het als absolute waarheid word beschouwd.

[DdeM]

Assert.True(true);

Ben hem daadwerkelijk al een aantal keren tegen gekomen in open source projecten.

Overigens kan je unit tests perfect gebruiken om te kijken of je code aan de requirements voldoet, aangenomen dat je daadwerkelijk gedrag test en niet interactie (wat velen helaas doen met mock frameworks).

[CykkVii]

Hoe willen ze dit gaan waarborgen met al die meuk in de Google play store?

[swhnld]

Ze willen het met nieuwe apps gaan doen. Werkt het systeem kunnen ze uitbreiding doen naar bestaande apps en zo de meuk verminderen.

[poktor]

Zou een goede zaak zijn. Als je nu bijv. Dns changer zoekt in de app store moet je je door 100 waardeloze klonen heen worstelen om die ene die WEL goed werkt eruit te vissen.

[henry906]

Belangrijk detail is wel dat dit volgens de bron alleen geldt voor nieuwe 'persoonlijke' ontwikkelaars accounts en niet voor bedrijfsaccounts.

[Zenomyscus]

Raar, dat zou je andersom verwachten. Als individuele ontwikkelaar ga je niet zo snel 20 mensen optrommelen. Kleine bedrijven overigens ook niet. Is het wellicht een manier van Google om mensen te pushen naar een bedrijfsaccount?

[MrMonkE]

Helemaal als je het maakt voor jezelf en alleen deelt omdat je het toch al hebt.
Gewoon stoppen met delen en alleen voor jezelf vanaf nu.

[markg85]

Maar de app store is toch juist een makkelijke centrale plek om je applicaties te downloaden en installeren? Is toch handing? Hoef je niet op elke site de app zelf te downloaden en installeren.

Zo zijn we de app store en varianten daarop ingerold. En zo klinkt het ook wel goed.

Maar dan krijg je de commerciële belangen. Als we dan een mooie centrale app store hebben vragen we ook mooi een fee voor de apps die betaald zijn. En om deze app store als enige plek te hebben zetten we lekker standaard bij iedereen uit dat je apps van derde partijen kan installeren. We scannen de app ook wel voor je, helpt tenslotte het gevoel van (schijn) veiligheid te versterken. En weet je wat, we verplichten je ook hoe je de app moet ontwikkelen en testen. Maar advertenties duwen we je ook gelijk door je strot, want waarom niet. (hypothetisch) In de toekomst mag je alleen apps installeren als je telefoon niet rooted is. (hypothetisch) Ook gaan we je geld vragen voor het gebruik van de app store zelf. (hypothetisch) En bieden we je als gratis gebruiker alleen maar een lijst apps aan die wij goedkeuren, wil je andere apps dan moet je een "premium app store" account afsluiten.

De stukjes met "(hypothetisch)" zijn er nu nog niet. Gelukkig! Maar hoe lang gaat dat nog duren?

Een app store achtige centrale winkel is best hoor. Maar het zou niet veel meer moeten zijn dan een "register" waar je apps op beschikbaar stelt. Een makkelijkere manier dan individuele sites. Zo'n app store moeten we weer hebben. Op de manier zoals het nu is heeft google (en apple aan de iphone kant, maar ook microsoft met de windows store) teveel macht en zullen ze het ook ten nadele van de gebruiker en developer inzetten voor hun eigen (commerciële) belang.

[Martinspire]

Dat is best een barriere voor kleine devs die gewoon wat leuks willen bouwen. Sowieso 2 weken is al vrij lang eigenlijk. Doe er dan gewoon een waarschuwing bij of zo. En wat is testen nou eigenlijk? Moet dan alles een keer gebruikt zijn of gaat het alleen om opstarten en dergelijke? Is een crash of error (ook al ziet de gebruiker daar niks van) dan ook meteen geen reden om te publishen of komt er geen controle op hoe die dat hebben ervaren? Ook voor veiligheid zegt het niks want dan laat je gewoon de eerste 2 weken je malware niet zien en vervolgens wordt het nog meer verspreid en kun je veel meer malware bij mensen naar binnen brengen.

Dit nodigt alleen maar uit om via alternatieve stores of sideloading te werken. Nee, ik zie hier totaal geen voordeel van in. Een waarschuwing zou veel logischer zijn dan meteen zo'n barriere. Maar ik sta niet verbaasd als over een paar weken deze regel weer terug wordt gedraaid.

[Reactie gewijzigd door Martinspire op 23 juli 2024 00:10]