how prepare test plan
I forrige artikkel har vi sett noen viktige punkter i ERP som den virkelige betydningen av begrepet ERP, forskjellige moduler av ERP, viktigheten av ERP-testing, kritikkverdiene ved ERP-testing og et veikart for utarbeidelse av ERP-testing .
=> Sjekk ERP-testing del 1 opplæring her.
I denne artikkelen, la oss få mer praktiske detaljer om ERP (SAP) -testing som å utarbeide kvalitetssikringsplan, testplan, testpakke, testtilfeller og testutførelsesstrategi.
=> Klikk her for fullstendig testplanopplæringsserie
Denne opplæringen er et godt eksempel for å skrive testplan fra bunnen av for alle applikasjoner. Vi har også gittprøve test suite mal for nedlasting.
For demonstrasjonsformålet, la oss anta at ERP-applikasjonen som testes består av følgende moduler med litt viktig informasjon om implementeringsplanen som nedenfor.
ERP-navn: ABC Manufacturing ERP
Kundenavn: XYZ Petrochemicals LLC
Industrivertikaler: Produksjon
Bedriftskontor: New York
Avdelingskontorer: Los Angeles og Chicago
Fabrikk: Houston
Lagerlagre: Houston, Los Angeles og Chicago
Totalt antall ansatte: 2500
Systembrukere: 325
Selskapets omsetning: USD 1M
Avdelinger: Administrasjon, økonomi, kontoer, HR, produksjon, kvalitet, butikker, salg, markedsføring, vedlikehold, utsendelse, kundesupport
Moduler: Budsjett, CRM, kunde, leverandør, salg, kjøp, betalinger, kontrakter, økonomi, kontoer, menneskelig kapital, lønn, produksjonsplanlegging, prosjektledelse, varelager, materialadministrasjon, arbeidsordrer, anleggsmidler, forretningsinformasjon
Leveringsmodell: Lokalt og Cloud
Implementeringsplan: Kravsamling, arbeidsflytanalyse, dataflytvurdering, tilpasning og forbedring, levering og utrulling, opplæring av sluttbrukere
Anbefalt verktøy:
# 1) Oracle NetSuite
Oracle NetSuite tilbyr en kvalitetssikringsplattform som lar deg sette opp inspeksjonsplaner og spore testresultater. Verktøyet vil hjelpe deg med å levere den høyeste kvaliteten i produktene dine. Du vil være i stand til å administrere listen over tester sentralt og håndheve minimumskontrollørens kvalifikasjoner.
Den gir forskjellige funksjoner og funksjoner for testdefinisjon, mottak og inspeksjoner og datainnsamling.
Egenskaper:
- Oracle NetSuite utfører sanntidsbehandling av inspeksjonsresultater.
- Det er et enhetsagnostisk verktøy og kan brukes på alle nettleserbaserte nettbrett.
- Den har funksjoner i arbeidsflytbasert håndtering av ikke-samsvarende materialer.
- Du kan håndheve minimumskvalifikasjoner for inspektører.
Nedenfor finner du noen av skjermbildene til ERP-programvaren for noen viktige forretningsprosesser som salgsordre, kundeøkonomi, betalingshode, fast eiendom, ansattes ledelse og salgsrapport, som vil gi en ide om kritikken og kompleksiteten i ERP-testingen.
Skjermbilde 1: Salgsordre
Skjermbilde 2: Salgsordre (USA)
Skjermbilde 3: Kundeøkonomi
Skjermbilde 4: Betalingshode (India)
Skjermbilde 5: Payments Header (US)
Skjermbilde 6: Fast eiendom (India)
Skjermbilde 7: Fast eiendom (USA)
Skjermbilde 8: Ansattes ledelse
Skjermbilde 9: Salgsrapport
Hva du vil lære:
- ERP QA-plan
- ERP-testplan
- Prosjektbeskrivelse
- Objektiv
- Modulvise funksjoner for manuell testing
- Modulkloke funksjoner for automatiseringstesting
- Funksjoner som skal testes utenfor lokaler
- Funksjoner som skal testes på stedet
- Funksjoner som skal testes på mobil, Wi-Fi og sky
- Ressurskrav
- Testplan
- Test Saksutførelse
- Test dekning
- Leveranser
- Risikostyring
- Issue Tracker
- Kvalitetsmålinger
- ERP Test Suite
- Eksempel på nedlasting av testseriemaler:
- ERP-testtilfeller
- Konklusjon
- Anbefalt lesing
ERP QA-plan
Å sikre kvalitet er en viktig milepæl i ethvert ERP-implementeringsprosjekt, som består av følgende interessenter, og suksess er avhengig av dedikert innsats fra alle som en “ Team ”.
Interessentene i ERP-implementeringsprosjektet kan være:
- Implementeringsteam - Består av teamet av profesjonelle fra ERP Company eller fra den lokale implementeringspartneren. Må ha implementeringskompetanse.
- Programvareleverandør - Programvareleverandører for operativsystemet, databasen og andre kontorapplikasjoner som kreves for ERP.
- Hosting-leverandør - Hostingleverandører for servere, nettverk, internett og intranettinfrastruktur som kreves for ERP-implementering. Må ha implementeringskompetanse.
- Forretningsteam - Består av teamet fra forretningsutviklingen eller lederstyringskomiteen.
- Teknisk team - Utviklingsteamet eller implementeringsteamet skal være tilgjengelig i løpet av prosjektet. Må ha implementeringskompetanse.
- Testing Team - Testteamet fra ERP-selskapet eller fra lokale partnere som har ekspertise på ERP-implementeringsstrategiene.
- Kundeteam - Sluttbrukerteamet eller avdelingslederne, som har full arbeidskunnskap om forretningsprosessen.
Som vi diskuterte i forrige opplæring, er testing av ERP-programvaren (f.eks. SAP) annerledes enn å teste de andre programvarene. ERP-applikasjoner er domenespesifikke og bransjespesifikke. De vanlige modulene som økonomi, regnskap, varelager, anleggsmidler, salg, kjøp, menneskelig kapital og lønn er tilgjengelig i alle ERP-systemene.
Bortsett fra disse vanlige modulene, er det få industrielle spesifikke moduler tilgjengelig i henhold til målrettede kunder.For eksempel, en “produksjons-ERP” kan ha en “produksjonsplanleggingsmodul”, en “farmasøytisk ERP” kan ha en “lege-pasient” -modul og en “utdannings-ERP” kan ha en “student” -modul og så videre.
Så kvalitetsfaktoren bør aktiveres med at noen forhåndsdefinerte beregninger deles i god tid med alle interessentene i listen ovenfor.
For å opprettholde kvaliteten blir interessenter gjensidig inngått avtaler om servicenivå. Alle interessenter som et team skal ha de definerte handlingselementene, ansvar med måldatoer for å oppnå forventet kvalitet på arbeidserklæringen.
ERP-testplan
ERP-testplanen skal bestå av følgende informasjon for en effektiv og vellykket implementering.
Testplanen har målene, kvalitetsmålinger, funksjoner som skal testes manuelt, funksjoner som skal testes gjennom automatiseringsverktøy, prosjektmiljø, teaminfrastruktur, ressurskrav, testplan, testleveranser, testutførelsesinfrastruktur, testrammeverk, antagelser, avhengigheter, begrensninger, feilsporingsmekanisme, feilrapporteringsverktøy og akseptkriterier etc.,
udefinert referanse til hovedc ++
Nedenfor er testprøveplanen for vårt ERP-implementeringsprosjekt for XYZ Petrochemical LLC.
Se også - hvis du trenger mer informasjon om hvordan du skriver testplan, kan du sjekke disse veiledningene:
Prosjektbeskrivelse
ABC Manufacturing ERP er en integrert ERP-løsning for produksjonsindustrien. Produktet består av kjernemodulene som regnskap, økonomi, budsjett, varelager, anleggsmidler, kunder, leverandører, CRM, salg, kjøp, betalinger, kontrakter, menneskelig kapital, lønn, produksjonsplanlegging, prosjektledelse, varelager, materialadministrasjon, arbeid Ordrer og Business Intelligence.
Kundens vertikale er innen produksjon, og deres virksomhet er å produsere petrokjemiske biprodukter og selge dem til innenlandske og internasjonale kunder. Råvarene kjøpes fra innenlandske og internasjonale markeder. Selskapet opererer fra New York, USA med filialer i forskjellige deler av landet.
Selskapet har også varehus på avsidesliggende steder. ERP-systemet vil bli implementert på et sentralisert sted i bedriftens lokaler og koble sammen de andre filialene, varehusene, produksjonsanleggene, markedskontorene fra forskjellige deler av landet via Internett, WAN, Wi-Fi, Cloud Infrastructure. Den foreslåtte løsningen støtter flere språk som engelsk (for internasjonale kunder, hindi (for IN-brukere), arabisk (for Midtøsten-leverandører) og støtter flere valutatransaksjoner.
Systemet har også en E-Commerce kundeportal for online bestillinger med betalingskort for kredittkort og en leverandørportal for tilbud. Det er mer enn 300 systembrukere som skal bruke systemet fra forskjellige deler av verden med minst mer enn 10 000 transaksjoner per dag.
Objektiv
- Identifiser modulene som skal testes manuelt.
- Identifiser modulene som skal testes gjennom automatiseringsverktøy.
- Definer teststrategi, testomfang og testaktiviteter.
- Definer testkriterier, antakelser, avhengigheter og begrensninger.
- Identifiser testteamet, tildelingen og testplanen.
- Sett opp rammeverket for manuell testing og automatisering.
- Sett opp testinfrastrukturen med programvare- og maskinvarekonfigurasjonen.
- Definer interessentene i prosjektet for implementering av ERP.
- Definer kommunikasjons- og opptrappingsmekanismen.
- Definer arbeidsmiljø, oppgavedetaljer og ansvar.
- Risikostyring med risikoreduserende planer.
- Definer testleveransene og rapporteringsverktøyene.
Modulvise funksjoner for manuell testing
- Betalingsmodul (Opprettelse av betaling, Godkjenn betalinger, utstedelseskontroller)
- Finansieringsmodul (fellesbetalinger, godkjenn fellesbetalinger, utstedelseskontroller)
- Lønnsmodul (lønnssjekker, utstedelseskontroller)
- Modul for anleggsmidler (avskrivning av eiendeler, avhending av eiendeler)
- ...
Modulkloke funksjoner for automatiseringstesting
- Salgsmodul (salgsordre, fraktordre, restordre, salgsfakturering)
- Kjøpsmodul (kjøpekontrakt, innkjøpsordrer, innkjøpsendringer)
- Kundemodul (kundeadministrasjon, kundeøkonomi)
- Human Capital Module (ansattes ledelse, oppmøte, lån, permisjoner)
- ...
Funksjoner som skal testes utenfor lokaler
- Funksjonstesting: Alle funksjonstesttilfellene til alle modulene, som blir gjennomgått og godkjent.
- Regresjonstesting: Alle funksjonelle testtilfeller for de tilpassede modulene, som blir gjennomgått og godkjent.
- Røykprøving: Alle funksjonelle testtilfeller som er merket for Sanity, som blir gjennomgått, utført og godkjent.
- ...
Funksjoner som skal testes på stedet
- Systemtesting: Alle systemtesttilfellene til alle modulene, som blir gjennomgått og godkjent.
- Integrasjonstesting : Alle systemtesttilfellene til alle modulene, som blir gjennomgått og godkjent.
- Performance Testing: Alle ytelsestesttilfellene, som blir gjennomgått og godkjent.
- Lasttesting: Alle lastetesttilfeller som blir gjennomgått og godkjent.
- Test av brukeraksept : All brukertest, som blir gjennomgått og godkjent.
- ...
Funksjoner som skal testes på mobil, Wi-Fi og sky
Funksjonstesting: Alle systemtesttilfellene til CRM-modulen, som blir gjennomgått og godkjent.
Ressurskrav
Testplan
| Ja Nei | Oppgavedetaljer | Startdato | Sluttdato | Tester |
|---|---|---|---|---|
| 6 | Autorisasjon for returvarer | 05/27/2015 | 06/01/2015 | Tester B |
| 1 | Forbereder testplan | 05.04.2015 | 05.06.2015 | Tester A. |
| to | Gjennomgå og oppdater testplanen | 05/07/2015 | 05/07/2015 | Testledning B |
| 3 | Forbereder Test Suite & Test Cases | |||
| Modul 1: Salg og distribusjon | 05/16/2015 | 06/04/2015 | ||
| 4 | Salgsordreprosess | 05/16/2015 | 05/20/2015 | Tester B |
| 5 | Salgskontraktsprosess | 05/21/2015 | 26.05.2015 | Tester B |
| 7 | Betalingsmottaksprosess | 06.02.2015 | 06/04/2015 | Tester B |
| ... | ||||
| Modul 2: Kjøp og betaling | ||||
| 8 | Kjøp innrykk prosess | 05/16/2015 | 19.05.2015 | Tester C |
| 9 | Tilbudsprosess for kjøp | 05/20/2015 | 23.05.2015 | Tester C |
| 10 | Innkjøpsordreprosess | 05/24/2015 | 05/28/2015 | Tester C |
| elleve | Prosess for godkjenning av betaling | 29.05.2015 | 05/31/2015 | Tester C |
| ... | ||||
| Testutførelse | ||||
| 12 | Modul 1: Iterasjon 1 | 06/01/2015 | 06.05.2015 | Tester B |
| 1. 3 | Modul 2: Iterasjon 1 | 06/01/2015 | 06/04/2015 | Tester C |
| ... | ||||
| 14 | Regresjonstesting: Modul 1 | |||
| femten | Regresjonstesting: Modul 2 | |||
| ... | ||||
| 16 | Testrapporter og QA-planoppdateringer | |||
| ... |
Test Saksutførelse
Test dekning
A: Funksjonstesting, B: Systemtesting, C: Integritetstesting, D: Sikkerhetstesting, E: Brukervennlighetstest, F: Ytelsestesting, G: Grensesnitttesting, H: Installasjonstesting
Leveranser
Risikostyring
Issue Tracker
Confluence og JIRA verktøy brukes til problemsporing i prosjektet. JIRA er også tilpasset og konfigurert for alle testteammedlemmene til å eskalere problem og rapportere feil og tilordnet bekymringsutviklingsteamet med ansvar og måldatoer.
Kvalitetsmålinger
ERP Test Suite
I likhet med den vanlige testprosessen blir ERP Test Suite normalt utarbeidet som et Excel-dokument. Dette dokumentet kontrollerer fullstendig revisjonshistorikk for de forskjellige testpakkene til alle modulene i ERP-applikasjonen. Testtilfellene for hver modul, testutførelseshistorikk, liste over feil og testrapporthistorikken opprettholdes i en ERP-testpakke.
For automatiseringstesting er testmanus ”Opprettholdes i testpakken og den relaterte iterasjonen av testutførelseshistorikken opprettholdes. Avhengig av type test og kompleksiteten i testtilfellene, opprettholdes automatiseringstestskripter i suiten som skal utformes på en slik måte for gjenbrukbarhet.
Finn under øyeblikksbildet av en ERP-testpakke i Excel-dokument.
Eksempel på nedlasting av mal for testserie:
Nedenfor er eksempler på test suite mal for nedlasting. Den inneholder maler for revisjonslogg, testrapport, feilrapport, røykprøvesaker, regresjonstestsaker
=> Klikk her for å laste ned ERP-testpakke-mal.
ERP-testtilfeller
Bortsett fra funksjonelle testtilfeller, regresjonstesttilfeller, sunnhet / røyk testtilfeller, krever ERP-testing annen type testsaker for installasjonstesting, konfigurasjonstesting, implementeringstesting, tilpasningstesting, nettverkstesting, servertesting, offline testing, ekstern testing, multi-valutatesting, flerspråktesting, enhetstesting, intranett-testing, sanntidstest osv.,
Viktigst, ERP er en sentralisert automatisert løsning, som er tilgjengelig av flere brukere samtidig online i sanntid, som innebærer en økonomisk transaksjon, og hver testtilfelle skal skrives med mye dedikert innsats og sanntidsdata.
Testutførelsesstatusen bør også oppdateres som 'Bestått' etter å ha bekreftet utdataene med de forhåndsdefinerte sanntidsdataene. Så testtilfellene skal alltid ha en kolonne for ' testdata ”Og“ utdata ”.
Eksempel på testscenario:
Nedenfor finner du et eksempler på en testtilfelle for vår ERP-demonstrasjon. Disse testtilfellene kan bestå av mange små testtilfeller som kan adskilles og vedlikeholdes, men for demoformål er det kombinert med en enkelt testtilfelle.
| Test saks-ID | ABC_ERP_SD_X0121 |
|---|---|
| forventede resultater (Positiv) | 1. Bestilling skal bestilles og faktureres. 2. Plukkeseddel skal genereres. 3. Fraktordre skal genereres. 4. Hovedbokstransaksjoner bør bokføres. 5. Lagerbok skal oppdateres. 6. Debetmemo skal genereres. 7. E-post skal sendes til kunden og butikkene. |
| Modul | Salg og distribusjon |
| Trekk | Salgsordreprosess |
| Objektiv | For å sjekke salgsordren bookes og faktureres med riktige data angitt for salgsoverskrift og salgsdetaljer. |
| Steg for å reprodusere | 1. Salg og distribusjon -> Ordrehåndtering -> Salgsordreliste -> Ny salgsordre. 2. Velg bestillingsdato, velg bestillertype, velg utløpsdato, velg kunde-ID, velg frakt-ID, velg lager-ID, velg fraktdato, velg betalingsdato, velg moms, velg selger-ID. 3. Velg Nye salgsartikler og velg vare-ID, Velg vare UOM, Angi varemengde, Angi varepris, Velg Ledger-konto, Velg prosjekt-ID og klikk OK. 4. Klikk på Book Order-knappen i hovedskjermen. |
| Inndata (Positiv) | Bestillingsdato (01/01/2015), Bestillingstype (salgsordre), Utløpsdato (31/09/2015), Kunde-ID (SABIC), Frakt-ID (FedEx), Lager-ID (NaviMumbaiWH), Leveringsdato (03 / 02/2015), Velg betalingsfrist (28/02/2015), Moms-ID (ST929), selger-ID (Anand), vare-ID (polyPropylen), vare UOM (kg), vareantall (1000), reskontokonto (23499949), Prosjekt-ID (DueTarget2015) |
| Inndata (Negativ) | Bestillingsdato (01/01/2016), Bestillingstype (Innkjøpsordre), Utløpsdato (31/09/2012), Kunde-ID (STANDARD), Frakt-ID (tom), Lager-ID (tom), Leveringsdato (03 / 02/2013), Velg betalingsfrist (28.02.2012), Moms-ID (tom), selger-ID (STANDARD), vare-ID (STANDARD), vare UOM (tom), vareantall (0), reskontokonto (STANDARD), Prosjekt-ID (STANDARD) |
| forventede resultater (Negativ) | • Varselboks skal komme for hver negativ datainngang i henhold til varslingsprosessen og den definerte teksten. • Salgsordren skal omordnes hvis varene er utsolgt. • Salgsordren skal være på vent hvis kundens kredittgrense er lav. |
| Egentlige resultatet | |
| Forventet utgang | Salgsordre, salgsfaktura, pakkeliste, fraktliste skal genereres i det forhåndsdefinerte rapportformatet. |
| Faktisk produksjon |
Konklusjon
ERP-testing har mange risikoer og kompleksiteter sammenlignet med programvare / produkttesting. Å administrere kvalitetsmålingene i ERP-implementeringsprosjekter krever også mye oppmerksomhet og dedikert innsats som et 'team' fra flere interessenter.
Testpersoner må forstå forskjellen mellom produktets kvalitet og kvaliteten på implementeringen. ERP-testing krever pålitelig sponsing i tide og budsjett fra ledelsen og kundene. Testing skal utføres av ERP-ekspertteamet og bør ikke tildeles et uerfarent team av noen grunn.
Det er veldig viktig å bruke den allment bevist riktige prosessen, metodikk, tilnærminger og automatiserte verktøy. Vi bør ikke anta at 'automatisering' erstatter 'manuell' testing fullstendig, men vi bør ikke gå på akkord med å bruke den nødvendige testinfrastrukturen og rammeverket. Ikke undervurder tiden som kreves for å samle inn reelle data fra kundene.
For testpersoner er denne reisen 'Utmerket ressurs for ERP-produkttesting!'.
Gi oss beskjed hvis du har spørsmål om ERP eller spesielt SAP-testing.
=> Besøk her for komplett testplanopplæringsserie
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Programtestkursplan - Online kursdetaljert opplæringsplan
- Forskjellen mellom stasjonær, klientservertesting og nettesting
- Testing Primer eBook Download
- Hvordan skrive programvaretesting Ukentlig statusrapport
- Nybegynnerveiledningen til ERP-testing (SAP-testing) - Del 1
- Veiledning for testing av webapplikasjoner
- Testplanopplæring: En guide til å skrive et dokument fra programvaretestplan fra bunnen av