Taula de continguts

La planificació de les proves d’una iteració o cicle de proves requereixen dels següents passos:

  1. Definir la release en la que s’inclouen els requisits o el cicle de proves
  2. Definir els requisits que es provaran i la seva valoració del risc
  3. Definir el cicle de proves
  4. Definir i/o escollir els casos de prova que s’inclouen en el cicle i que verificaran els requisits (amb agrupacions de casos de prova relacionats)
  5. Generar el document del Pla (Mestre) de Proves

Definir la release

S’ha de registrar cada release planificada. Aquesta permetrà tant assignar en quina versió està implementat un requisit, com per afegir els diferents cicles o iteracions de prova que es realitzaran per aquesta release.

  1. Accedir a l’apartat Management –> Releases, ubicar-se a la carpeta ‘Releases’ i amb botó dret escollir ‘New Release’
  2. Introduir el nom de release al camp ‘Name’, usant el format especificat a l’estàndard Estàndard per la creació de lliurables tècnics

Identificar els requisits (opcional)

La gestió de requisits a HP Quality Center es realitza a la secció Requirements –> Requirements.

Definició i estructura de carpetes

Per crear una carpeta en l’eina s’ha de sel·leccionar la carpeta de nivell superior, i escollir el menú Requirements –> New Folder.

Usar l’estructura i format de carpetes especificat a l’estàndard Estàndard per la creació de lliurables tècnics

Definir un requisit

Per donar d’alta un requisit a HP Quality Center seguirem els següents passos:

  1. Anar a la secció Requirements –> Requirements i seleccionar la carpeta on es vol desar el nou requisit,

    Si el requisit ha de ser fill d’un altre requisit, seleccionar aquest últim (no es recomana passar de dos nivells de jerarquia de requisits i en cap cas s’hauria de sobrepassar els tres nivells de jerarquia).

  2. Seleccionar el menú ‘Requirements –> New Requirement…” i omplir els següents camps a la secció Details:

    • Codi Requisit: un codi opcional del requisit
    • Name (*): títol del requisit
    IMPORTANT: No incloure el caràcter '/' dins el nom, ja que això pot provocar problemes en la generació dels informes.

    • Requirement Type (*). Escollir un dels valors següents:

      • Funcional: es tracta d’un requisit que defineix una funcionalitat de la solució.
      • No funcional: es tracta d’una qualitat desitjada de la solució (rendiment, accessibilitat, usabilitat, seguretat, …)

    • Description. Descripció detallada del requisit.

    • Priority (*). Prioritat del requisit.

    • Target Release (*). Versió en la que s’inclou el requisit (quan serà implementat o ha estat implementat)

    • Codi petició origen. Si es desitja, especificar el codi de la petició de canvi (del sistema de gestió de manteniment) que han originat la creació o modificació del requisit, per exemple d’eines com Remedy o JIRA.

    (*) indica que el camp és obligatori.

    Exemple:

    qc_requirements_tree_2

Si els requisits ja es trobaven definits en un sistema previ es pot realitzar un procés de migració, i continuar a l’eina amb la incorporació manual dels nous requisits. Veure guia

Identificar els riscos (opcional)

Prerequisits: Haver introduit els requisits prèviament (veure apartat previ).

Des d’un requisit es pot establir quin és el seu risc prement l’opció “Requirement Details” i accedint a la secció “Risk Assessment”.

Introduir en aquest apartat:

  1. Business Criticality: marcar “Use custom” i informar amb el nivell d’Impacte de Negoci que correspongui

    • A-Critical
    • B-Important
    • C-Nice to have

    Es seleccionarà el valor més adient, basant-se en criteris de negoci com són:

    • tipus de procés: És un requisit cosmètic, canvia dades, o implica un càlcul o validació important?
    • impacte de fallida: Una fallida no te impacte per l’usuari, suposa una informació incorrecte o te conseqüencies legals?
    • freqüència d’ús: La funcionalitat s’usarà poc, sovint, o molt sovint
    • número i importancia dels usuaris afectats: la funcionalitat afecta a pocs usuaris amb poca importancia pel negoci, o a molts usuaris o molt importants?

  2. Failure Probability: marcar “Use custom” i informar amb el nivell de Probabilitat de Fallida que correspongui:

    • 1-High
    • 2-Medium
    • 3-Low

    Es seleccionarà el valor més adient. Basant-se en els següents criteris:

    • Tipus de canvi: La funcionalitat canvia poc, molt, o és nova?
    • Maduresa del software: Quin nivell de maduresa té el codi?
    • Rati de defectes: Quin nivell de defectes relacionats amb aquesta funcionalitat es preveu que entraran?
    • Número de pantalles/entitats afectades: A quantes pantalles/entitats afecta aquest requisit?

  3. Functional Complexity: marcar “Use custom” i informar amb el nivell de Complexitat Funcional que correspongui:

    • 1-High
    • 2-Medium
    • 3-Low

    Es seleccionarà el valor més adient. Basant-se en els següents criteris:

    • Número de passos lògics del procés
    • Quantitat de dades afectades
    • Dependència amb altres sistemes

  4. Risk: assegurar que no està marcat el “Use custom” del camp Risk.

Es pot aprofitar l’opció d’importar massivament aquesta informació per un conjunt de requisits seguint la guia Registrar requisits a HP Quality Center

qc_requirement_risk

Definir el cicle de proves

  1. Accedir a l’apartat Management –> Releases, seleccionar la versió pare i amb botó dret escollir ‘New Cycle’

    Usar l’estructura i format de carpetes especificat a l’estàndard a l’estàndard Estàndard per la creació de lliurables tècnics

    hp_qc_cycles

  2. Introduir les dates estimades d’inici i finalització del cicle

  3. Accedir a la secció ‘Testing –> Test Lab’ i definir una carpeta sota ‘Root’ amb el mateix nom que la release (si no existeix ja)

  4. Accedir a la secció ‘Testing –> Test Lab’ i crear sota la carpeta que representa la versió una carpeta amb el nom del build

  5. Sota aquesta última carpeta crear l’estructura de carpetes segons s’especifica a l’apartat ‘Proves’ a l’estàndard Estàndard per la creació de lliurables tècnics

  6. Per les carpetes [Build], “Proves Desenvolupament”, “Proves Integració Sistemes”, “Proves Qualificació” i “Proves d’Acceptació” accedir a la seva pestanya ‘Details’ i assignar en el camp “Assigned to cycle” el cicle creat.

    Obtindrem finalment la següent estructura:

    + [x.y.z]
    + [x.y.z.Bxxx]
        + Proves Desenvolupament
        + Proves Integració Sistemes
        + Proves Qualificació
            + Proves Requisits Nous o Canviats
            + Proves Regressió
            + Proves Confirmació
        + Proves Acceptació

Dins d’una Release ha d’existir com a mínim un Cycle.

Definir els casos de prova (si no existeixen ja)

Per donar d’alta un cas de prova, accedirem al repositori de qualitat del CTTI (HP ALM), i dins l’apartat ‘Test Plan’ realitzarem els següents passos:

  1. Seleccionar o crear la carpeta on es vol desar la nova prova

    L’estructura de carpetes en aquesta secció ha de ser definida en dos nivells superiors:

    • Proves Funcionals. En aquest nivell s’hauran de crear subcarpetes inferiors que repliquin l’estructura definida en la carpeta ‘Requisits Funcionals’ de la secció ‘Requirements’ (definida durant la creació dels requisits).
    • Proves No Funcionals. En aquest nivell s’hauran de crear subcarpetes inferiors que repliquin l’estructura definida en la carpeta ‘Requisits No Funcionals’ de la secció ‘Requirements’ (definida durant la creació dels requisits).

  2. Seleccionar el menú ‘Test–> New Test’ i omplir els següents camps:

    • Test Name (*): el nom del cas de prova.
    • Type (*): informar MANUAL.

    • Tipus de prova (*): informar el tipus de prova segons la característica de qualitat que verifica:

      • Funcional
      • Rendiment
      • Seguretat
      • Accessibilitat
      • Adaptabilitat

    • Nivell de prova:

      • Integració (proves d’integració entre sistemes)
      • Qualificació
      • Acceptació

    • Status: informar “Design” mentre s’està definint i “Ready” una vegada s’hagi definit la prova

    • Description: fer una descripció general del cas de prova i indicar el seu objectiu (p.e. “Comprovar que….”). En el cas d’una prova de tipus rendiment, s’han d’indicar també els criteris d’acceptació (temps de resposta, …) Prémer el botó “OK”.

    qc_test_details

    (*) indica que el camp és obligatori.

  3. Enllaçar la prova amb el requisit que verifica (opcional)

    En cas que usem l’anàlisi de riscos de les proves o per poder mesurar la cobertura de proves amb els requisits, haurem de traçar la prova amb el seu requisit.

    Fer doble click sobre el cas de prova creat i escollir la pestanya ‘Req Coverage’.

    Prémer l’opció ‘Select Req’ que està representada amb una icona de paraigües. Ens apareixerà una nova finestra “Requirement Tree” des de la que podrem escollir quins requisits s’associen a la prova.

    qc_test_traceability

Cal tenir en compte que durant el pla s’inclouran tant casos de prova que hem de fer nous, com casos de prova ja existents prèviament.

Definir jocs de proves del cicle

Els diferents casos de prova definits s’executen habitualment en conjunts o agrupacions amb un objectiu comú (que anomenen jocs de prova).

Per exemple podem agrupar proves que són seqüencials entre sí (per exemple entre el Login i un cas de prova posterior, o un tràmit amb diferents casos de prova enllaçats, …) o bé que s’executen de forma seqüencial dins un pla (perquè són totes proves de regressió, o totes són proves de rendiment, etc.).

En aquest apartat definirem els jocs de prova, anomenades en l’eina “Test Sets”.

Seguir els següents passos:

  1. A l’apartat Testing –> Test Lab –> Test Sets, ubicar-se a la carpeta on crearem cadascun dels ‘Test Set’ o conjunts de proves relacionades.

  2. Amb botó dret seleccionar el menú Test Sets–> New Test Set i donar d’alta els diferents Test Sets o conjunts de prova omplint la següent informació a la pestanya ‘Details’:

    • Name: el títol del Test Set hauria de ser descriptiu dels Tests que conté

    • Categoria: informar un d’aquests valors:

      • ‘Nova funcionalitat’. Si els Tests continguts al Test Set són per provar noves funcionalitats.
      • ‘Regressió’. Si els Tests continguts al Test Set són per provar funcionalitats ja existents.

    • Entorn: entorn en el que s’executaran els Tests inclosos al Test Set. Escollir un dels següents valors:

      • Desenvolupament
      • Integració
      • Preproducció
      • Producció

    • Description: Incloure la descripció del conjunt de les proves

      En el cas d’una prova de rendiment s’ha d’especificar a més, en la descripció:

      • Quins casos de prova es proven en l’escenari, indicant quants usuaris concurrents executaran cada cas
      • nombre d’usuaris concurrents total
      • rampa d’entrada: increment d’usuaris per període de temps a l’inici de la prova
      • rampa de sortida: decrement d’usuaris per període de temps al final de la prova
      • durada: durada de la prova

      qc_test_set

  3. Per a cada ‘Test Set’ anar a la pestanya “Execution Grid” i amb el botó “Select Tests” seleccionar els Tests del Test Plan a incloure.

    En el cas que el Test Set correspongui a un escenari de prova de rendiment incloure els casos de prova (Test) de rendiment.

    hp_qc_execution_grid

    (*) Tant per l’alta de carpetes del build com per l’alta de Test Sets pot ser útil copiar les carpetes i/o Test Sets de builds anteriors.

Guies generals de suport

Es recomana llegir la secció ‘Test Plan’ del manual de ‘HP ALM Lifecycle Management User Guide’ per a més detall de les diferents tasques.

Alguns altres tutorials d’interès són: