Bouw uw browsermatrix op basis van risico's, niet van een selectievakje

Uw testsuite heeft een vervolgkeuzemenu voor de browser. Iemand selecteert alles. CI wordt langzamer, het aantal storingen neemt toe en niemand kan uitleggen welke configuraties het bedrijf beschermen. Een grote matrix ziet er zorgvuldig uit, maar kan nog steeds de mobiele stroom missen die klanten gebruiken om de aanmelding te voltooien.

Begin met het risico en kies vervolgens de configuraties die dit risico blootleggen. Deze handleiding gebruikt Playwright-projecten, de browserdocumentatie en de emulatiegids om een ​​kleine, leesbare browsermatrix te bouwen. De bijbehorende visual is een illustratief planbord en geen gemeten draagvlakrapport.

Scheid drie beslissingen

De eerste beslissing is de browserengine: Chromium, Firefox of WebKit. De tweede is de apparaatconfiguratie: viewport, user agent, touch en andere geëmuleerde instellingen. Het derde is hardware-bewijs: een echt apparaat en het echte browsergedrag ervan. Ze zijn verwant, maar niet uitwisselbaar.

Ondersteuning voor Playwright-documenten voor Chromium, Firefox en WebKit, plus merkchromium-kanalen zoals Chrome en Edge. De WebKit-build heet niet Safari. Een groen WebKit-resultaat moet daarom worden omschreven als WebKit-bewijs, en niet als een claim dat elke Safari-versie op elke iPhone is geslaagd.

Apparaatvoorinstellingen bieden geëmuleerde instellingen. Ze helpen bij het uitoefenen van een smalle lay-out of een aanraakgeoriënteerde gebruikersinterface, maar ze veranderen een desktopmachine niet in een fysiek apparaat. Voer controles op het echte apparaat uit op risico's zoals platforminteracties die de geëmuleerde installatie niet tot stand brengt.

Breng een reis in kaart met de risico's die deze met zich meebrengt

Voor het demobord is aanmelding afhankelijk van een smalle formulierindeling en een bevestigingslink. Factureringsinstellingen omvatten datuminvoer en landinstelling. Het uploaden van een document kan afhankelijk zijn van de browsermogelijkheden en het toestemmingsgedrag. Dat zijn verschillende redenen om voor een testconfiguratie te kiezen.

Vraag uw team naar de vereisten voor ondersteunde browsers en actueel publieksbewijs. Als er geen bestaat, noteer dan een voorlopige keuze en de beoordelingsdatum ervan, in plaats van klantpercentages te bedenken. Een QA-ingenieur kan dat gesprek leiden met product en ondersteuning; de keuze mag niet worden verborgen in een runnerbestand dat niemand leest.

Het bruikbare artefact is een matrixgrootboek: reis, risico, geselecteerd project, waarom het is geselecteerd, bewijsmateriaal buiten emulatie en eigenaar. Voeg alleen een configuratie toe als het grootboek zegt wat het koopt. Verwijder overtollig werk alleen als de ondersteuningsbehoefte en risicobeoordeling dit toelaten.

Zorg ervoor dat de projectnamen zeggen wat ze uitvoeren

Een Playwright-project groepeert tests met dezelfde configuratie. Deze kleine configuratie illustreert drie verschillende gezichtspunten en houdt de namen eerlijk:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium-desktop', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox-desktop', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit-phone-emulation', use: { ...devices['iPhone 13'] } }
  ]
});

Installeer de bijbehorende binaire browserbestanden in uw testomgeving. Voer een benoemd project uit met npx toneelschrijver test --project=webkit-phone-emulation. Deze namen beschrijven de configuratie en vormen geen productgarantie. De code is een startpunt voor uw eigen ondersteuningsbeleid en niet een universele aanbevolen matrix.

Playwright voert standaard geconfigureerde projecten uit. De projectgids laat ook zien hoe groepen verschillende testmappen kunnen gebruiken. Hierdoor kan een team een ​​gerichte rookset over verschillende motoren laten lopen, terwijl elders een bredere set kan worden gebruikt. Voorkom dat u stilletjes een bedrijfskritische reis onderbreekt, alleen maar omdat een brede run lastig is.

Stel een verschil vast in plaats van de configuratie te verwijderen

Als een test in het ene project slaagt en in een ander project mislukt, controleer dan of het product, het testcontract of de omgeving verschilt. Een smal zichtvenster kan de volgende actie onder de vouw verplaatsen. Lokale instellingen kunnen een datumnotatie wijzigen. Een browserfunctie kan zich anders gedragen. Een botsing tussen gedeelde gegevens is helemaal geen browserbewijs.

Houd het verwachte resultaat stabiel waar het productcontract stabiel is. Schrijf geen afzonderlijke bewering alleen maar om een ​​gebroken resultaat in één engine te accepteren. Als het product opzettelijk afwijkt, documenteer dat gedrag dan en laat de test dit expliciet controleren.

Controleer het bewijs van fouten op projectnaam en bewaar de configuratie met het resultaat. Een screenshot zonder viewport, engine en relevante instellingen kan moeilijk te interpreteren zijn. Bewaar deze details in het testrapport en niet in een gok tijdens de triage.

Waar gegenereerde verkenning past

AnyTest beschrijft het verkennen van een web-app en het bouwen van end-to-end-tests voor menselijke beoordeling. Gegenereerde trajecten kunnen u helpen bij het identificeren van stromen die de moeite waard zijn om te beschermen, maar ze bepalen niet de browser-/apparaatdekking van uw implementatie. Vraag naar de feitelijk ondersteunde uitvoeringsconfiguraties voordat u die claim maakt.

Voor één QA-ingenieur voorkomt een risicogestuurde matrix dat beperkte beoordelingstijd wordt verbruikt door onverklaarde duplicatie. Voor een groter team geeft het eigenaren van productgebieden een gemeenschappelijk vocabulaire. Het nuttige resultaat is een reeks configuraties die u kunt verdedigen, met bekende limieten en zichtbare follow-up, in plaats van de langste lijst die een instellingenscherm toestaat.