Nincs olyan rögzített határidő, amely minden alkalmazásra vonatkozna. Egy kis alkalmazás korlátozott számú képernyővel és tiszta kódbázissal néhány hét alatt elérhető szintre hozható; egy sok egyedi komponenst, több platformot és hosszú technikai adósságot hordozó alkalmazás inkább hónapokig tart. A legnagyobb variábilis tényező nem a képernyők száma, hanem az, hogy az irányítás mekkora részét építették meg az iOS vagy Android standard komponenseinek kerülésével.
Durva tájékozódásként: egy olyan alkalmazás, amely nagyrészt standard felhasználói felület elemekből áll, és amelynek csapata már ismeri az elérhetőséget, a gyakorlatban gyakran hat-tíz héten belül módosítható. Egy sok saját irányítást, animációt, egyedi gesztusokat vagy harmadik féltől származó SDK-kat tartalmazó alkalmazás könnyen elérhet három-hat hónapot, egyszerűen azért, mert minden komponenst külön-külön meg kell vizsgálni, és néha újra kell építeni. Ezek nem kemény határok, hanem egy benyomás arról, hogy a legtöbb projektiv a gyakorlatban meddig tartanak.
A szállítási idő valódi meghatározói
Az az idő, amely egy projekthez szükséges, kevésbé a törvénytől magától függ, és inkább három gyakorlati tényezőtől. Először: az irányítás az operációs rendszer standard komponenséből épül fel, vagy nagyrészt egyedi építésű? A standard komponensek az elérhetőséget gyakran már nagyrészt megadják; az egyedi komponenseket egyenként kell ellátni a megfelelő címkékkel, fókuszsorrenddel és képernyőolvasó-bejelentésekkel. Másodszor: hány külső komponens van az alkalmazásban, mint például fizetési modulok, térképmegjelenítések vagy harmadik féltől származó csevegési ablakok? Ezek gyakran kívül esnek a saját csapat közvetlen kontrollja alatt, és a szállítótól való lekérdezés általában több időt vesz igénybe, mint maga a tesztelés. Harmadszor: van-e már teszteljárás képernyőolvasóval a valódi eszközön, vagy azt még fel kell építeni? Az utóbbi az első körben a legtöbb időt veszi igénybe, de a későbbi frissítéseket megtérítik.
Ahol a tervek gyakorlatban elakadnak
A legtöbb késedelem nem szöveg vagy színkontrast módosításakor merül fel, hanem olyan interakcióban, amely nem kezelhető billentyűzet vagy képernyőolvasó segítségével: egy gesztus nélküli húzás, egy olyan modális ablak, amely nem őrzi a fókuszt, vagy egy olyan forma, amelyben a hibaüzenetek nincsenek bejelentve. Ezt a fajta problémát gyakran csak egy képernyőolvasóval végzett kézi teszteléskor lehet észrevenni, amit egy automatikus ellenőrzés nem tud teljes mértékben helyettesíteni. Aki csak automatikus ellenőrzésre támaszkodik, ezeket a szűk keresztmetszeteket általában túl késően fedezi fel a projektben, ami továbbra is meghosszabbítja a szállítási időt. Egy jó kiindulópont ezért néhány kérdésben egy első benyomást kapni az alkalmazás aktuális helyzetéről, hogy a sok időt igénylő részek korán a képernyőre kerüljenek az átadás előtt.
Az alkalmazásbolt felülvizsgálati ciklusai is szerepet játszanak: egy olyan módosítás, amely javítja az elérhetőséget, még mindig át kell mennie az adott bolt szokásos felülvizsgálati időszakán, mielőtt a felhasználók meglátják azt. Ez kívül van a fejlesztési csapat befolyásán kívül, és minden tervbe rögzített időpufferként kell szerepelnie.
Az alkalmazás továbbra is elérhető marad az átadás után
Egy alkalmazás, amely ma megfelel, a következő frissítés után nem felel meg. Minden új funkció, minden új képernyő és minden módosított folyamat ugyanannyi figyelmet érdemel, mint az első körben, különben a probléma visszakúszik. Ez az oka annak is, hogy az kötelezettség nem áll meg egy tesztelésnél: az önértékelésnek naprakésznek kell maradnia, és az egy ismétlődő ritmushoz szükséges, nem pedig egyszeri projekthez. A háttérre vonatkozóan, hogy pontosan mit várnak el tőlük, az az egyes helyzetekhez kiválasztott háttér egy megfelelő kiindulópont.
Mit tesz az axessia.eu és mit nem ebben a folyamatban
Az Axessia teszteli, priorizálja, dokumentálja és felügyeli: a vizsgálat megmutatja, hogy az alkalmazás jelenleg hol tart, a jelentés az eredményeket egyszerű nyelven egy prioritásokkal rendezett listában foglalja össze, és a nyilatkozat valamint a fejlesztési terv dokumentálják, hogy mit végeztek el és mit kell még elvégezni. A kézi auditálás és az alkalmazás közvetlen javítása nem tartozik ide; ezt az fejlesztőcsapat vagy az alkalmazást fejlesztő fél végzi. A vizsgálat pontos lefolytatásáról és a felhasznált forrásokról részletesebb információ található az információ előállításáról szóló oldalon. Egy teljes folyamat ára, amely tartalmazza a jelentést és a nyilatkozatot, megtalálható előfizetési csomagok áttekintésében.
Aki szeretné tudni, hogy egy konkrét alkalmazás jelenleg hol áll, az axessia.eu ingyenes gyorsvissgálatával kezdi el a legjobban. Ez pár perc alatt egy kezdeti képet ad, ehhez nincs szükség regisztrációra.