Menú

Com realitzar proves de productes de programari: procés i mètodes detallats amb exemples

how perform software product testing detailed process

Proveu El Nostre Instrument Per Eliminar Problemes

Els productes de programari necessiten el seu propi enfocament únic per provar adequadament i correctament. Sovint, els equips els tracten com qualsevol altre programari (és a dir, aplicacions internes creades per a un client o equip específic; no són accessibles pel públic en general; no generen ingressos) i aquest és el punt de partida del problema.

Les proves de productes de programari necessiten un estil i una estratègia de prova personalitzats per afegir valor. El desenvolupament i el manteniment de productes de programari és en si mateix un ecosistema complex i, per prosperar, els verificadors s’han d’adaptar.

Permeteu-me un moment per explicar per què és important i per què crec que el desenvolupament de productes és complex, complicat i compost, fins i tot en els millors moments.

Com provar el producte

Què aprendreu:

Reptes de desenvolupament de productes de programari:

Aquests són alguns dels reptes als quals s’enfronten els equips de desenvolupament de productes de programari:

# 1)Falta de control sobre la demografia, els dispositius, els entorns, les plataformes dels usuaris, etc. : Els productes de programari a diferència del programari dissenyat per a grups d'interès específics no s'utilitzen en situacions controlades i previsibles. Hi ha massa factors a tenir en compte.

# 2)Visió de producte boirós : El comportament i les característiques del producte canvien per sempre i el viatge cap a la maduresa no és clarament visible. O el producte creix massa ràpidament que deixa fora de control que els equips no saben què està passant.

# 3)Línies de temps agressives : A causa de la forta competència al mercat de productes de programari, les coses han de moure’s a una velocitat vertiginosa i els equips han d’estar un pas per davant dels seus companys. En cas contrari, segur que perdran davant la competició.

# 4)Por al fracàs : Els productes de programari solen ser innovadors. Per tant, el seu èxit no sempre és determinat. Aquesta és la raó per la qual les empreses no es poden esforçar en termes de pressupost, tecnologies, infraestructures, etc. Sovint han de contenir-se per obtenir una certa immunitat contra el fracàs o fins i tot per aconseguir un punt d'equilibri.

# 5)Manca de comentaris útils: Com que no hi ha grups d’interès ni usuaris comercials ni clients, per dir-ho d’alguna manera, és difícil entendre què pot agradar o no a l’usuari final. Les empreses juguen constantment a un joc d’endevinalles i sovint tenen dificultats per salvar la bretxa entre allò que volen per al programari i allò que el client vol.

Aquests reptes afecten totes les àrees del desenvolupament de productes, màrqueting i sosteniment, i també afecten intrínsecament les proves de productes.

Per avançar en el joc, aquest tipus de proves ha de tenir en compte cinc punts clau:

  • Velocitat de desenvolupament i llançaments
  • Objectius de producte a curt i llarg termini del producte
  • Extensió i naturalesa de la competència
  • Públic objectiu i els seus entorns
  • Requisits - Funcional, rendiment, seguretat, usabilitat, configuració, etc.

Abans d’entrar en més detalls, entenem el cicle de vida del producte (es tracta d’un cicle de vida del producte genèric i no específic per als productes de programari, però el programari segueix un patró similar):

cicle de vida del producte

Una bona estratègia / enfocament de prova de producte hauria de tenir en compte l’etapa actual del producte en el seu cicle de vida.

Llegiu també => Com escriure un bon document d’estratègia de prova

Exemple: El producte d’una empresa XYZ és un programari de seguiment de defectes anomenat ‘TrackFast’. És un producte nou i la primera versió està prevista per llançar-se com a solució al núvol i local. TrackFast funciona com qualsevol altre sistema de gestió de defectes i està dissenyat tant per a accés mòbil com web. Actualment, hi ha sprints de 2 a 4 setmanes en què es crea el producte per parts. Esteu a l’equip de proves que prova ‘TrackFast’ abans que conegui els seus clients. La prova implica comprovar la funcionalitat, el rendiment i la seguretat.

Preguntes i respostes de l’entrevista informatica powercenter

En resum, aquests són els paràmetres amb els quals esteu treballant. O si ho preferiu, aquest és el vostre context

els paràmetres

Vegem com provar en cada etapa. Això és prova del producte procés, mètode o cicle de vida en cada etapa.

Etapa 1) Introducció al producte

Com que és la primera vegada que TrackFast sortiria al mercat, la idea és fer una bona primera impressió. Deixeu, doncs, cap pedra. Posa a prova tot i des de tots els angles. A més, estableixi les bases per a futures proves.

Una bona estratègia de prova en aquest moment hauria d’incloure el següent:

  • Proves que validen els objectius a curt termini de TrackFast. 'Què cal que s'enviï correctament' hauria de ser l'avantguarda de les proves. Crear Proves de punta a punta (frontal, middleware i backend) per provar a fons totes les funcions
  • Proves que comparen TrackFast amb la competència (idealment és la feina dels propietaris de productes, però com a provador podem afegir els nostres dos cèntims. A més, aquest pas és més fàcil si el programari ja té alguns parells. Per exemple: És fàcil comparar TrackFast amb Bugzilla o JIRA o altres sistemes heretats . Però diguem que estic creant una aplicació que faci alguna cosa inusual, com ara poder predir quan un bebè té gana o mal humor :), pot ser que sigui difícil trobar una aplicació que pugueu utilitzar com a base).
  • Plataforma, navegador i dispositiu proves de compatibilitat
  • Proves per facilitar la instal·lació , configuració i posada al dia
  • Proves de rendiment, seguretat i usabilitat
  • Proves d’integració si s’interface amb altres sistemes. Un exemple d’integració simple és que els sistemes de seguiment de defectes sovint interactuen amb els clients de correu electrònic per enviar notificacions
  • Pla de regressió - És una bona idea marcar o marcar proves crítiques que creieu que formaran part dels futurs cicles de regressió i pensar en automatitzar-les per a futures versions
  • Planifiqueu els problemes coneguts (els afegirà al backlog o els manejarà com a CR, etc.)
  • Flexibilitat per canviar quan el producte avança a la següent etapa del cicle de vida.

De vegades pot passar una llarga espera abans que el producte s’apagui, així que utilitzeu tot el temps que tingueu per fer una feina tan completa com sigui possible.

En aquesta etapa, tot i que hi ha un tros del producte llest al final dels sprints de 2 a 4 setmanes, el més freqüent és que cada sprint no doni lloc al codi enviat. Per tant, no tingueu en compte que l'última prova de sprint és 'feta i lliurada'. Repetiu les proves crítiques amb cada sprint fins al llançament. Amb cada sprint, proveu tot el producte que teniu fins aquell moment.

Etapa 2) Creixement del producte

Després de la introducció inicial del projecte, si tot va bé, espereu una afluència d'activitat perquè el creixement del producte és un carril de ritme ràpid. Ara estàs nedant juntament amb els grans taurons i, a menys que mantinguis el ritme, et devols.

Aquí, les versions es redueixen, les millores realitzades al programari són cada vegada més nombroses i l'extensió de la regressió gairebé no es pot gestionar.

L'estratègia de proves de producte ha de funcionar amb el ritme que segueix avançant el desenvolupament de programari i no ha de convertir-se en un coll d'ampolla.

Això pot ajudar:

  • Tingueu en compte els objectius a llarg termini del projecte. No es tracta d’aconseguir-ho ara. Es tracta de viure amb les característiques i prosperar amb elles.
  • Prova aviat- Penseu en TDD o BDD en lloc de diferir les proves fins al final amb nous requisits
  • Automatitzar la regressió i enfortir-la - Creeu una suite de regressió automàtica al lloc perquè no us quedeu mines terrestres no provades al vostre sistema
  • Si els propietaris de la vostra empresa o producte volen participar en les proves, tingueu en compte una eina d'automatització basada en el llenguatge empresarial, com ara Cogombre.
  • Mantingueu la usabilitat i el disseny del lloc central per a les proves. Com que, com més funcions afegim, més net hauria de ser el lloc
  • Realitzeu proves de rendiment i de seguretat quan s'hagi produït una versió important o es faci un canvi significatiu a l'arquitectura. (S'ha incorporat un servidor nou, etc.) La majoria de sistemes de programari no ho necessiten amb cada versió.
  • Mantingueu-vos en contacte amb la competència i coneixeu la visió del producte
  • Adaptar les proves de parells , per obtenir comentaris i solucions immediates. Incloeu el propietari del producte quan sigui possible
  • Planifiqueu els canvis i els problemes coneguts
  • Intenteu fer arribar els comentaris dels clients i comprovar si es poden fer un seguiment d’aquestes com a suggeriment de millora per mantenir el creixement constant. (una vegada més, aquesta no és la responsabilitat principal de l'equip de control de qualitat, però tothom compta)

Etapa 3) Maduresa del producte

Enhorabona perquè el vostre producte ha arribat fins aquí. En aquest moment, les funcions no canvien tan sovint. L’equip de productes estarà més centrat a aconseguir més negocis o els seus esforços de màrqueting. No obstant això, el desenvolupament i les proves de productes no necessiten i sovint no s’aturen.

Per tant, l'equip de proves pot:

  • Treballa per madurar la teva estratègia de prova. En aquest punt, les vostres suites de regressió, mètodes de disseny de proves i pràctiques de gestió de proves han de funcionar com màquines ben greixades.
  • Centreu-vos en els detalls més fins. Perquè, en general, el producte funciona i està funcionant bé, però com es diu- Déu està en els detalls » - Trobeu fins i tot el més petit dels problemes que poden millorar la qualitat del sistema
  • Tingueu en compte els comentaris dels clients
  • Prova de rendiment i seguretat periòdicament
  • Tingueu en compte els nous dispositius, plataformes i navegadors que podrien haver entrat al mercat des de la darrera vegada que vau provar
  • Proveu les pàgines del manual d'usuari i de les preguntes més freqüents, ja que ja teniu temps i us ho podeu permetre.
  • Experimenteu amb noves eines de prova de productes, serveis o un procés perquè ara podeu.
  • Proveu el procés d’instal·lació amb cada versió, per petita que sigui i obteniu estadístiques sobre la facilitat o dificultat que té l’usuari final.

Feu el que feu, no us complaceu.

Etapa 4) Disminució del producte / Tornar al creixement del producte

Els propietaris de productes i les empreses són intel·ligents en aquests dies i saben molt bé que no poden mantenir el seu producte igual i esperen que els usuaris es mantinguin fidels. Les coses es mouen massa de pressa i els productes també.

Per tant, TrackFast no pot seure i relaxar-se. Si ha de tenir una presència continuada al mercat i mantenir-se al capdavant, ha d’evolucionar. T’agradi o odi, Facebook va començar com una simple xarxa social per connectar persones i és una gran plataforma de programari que s’integra amb un milió d’altres coses i es manté al dia.

TrackFast també ha d’evolucionar. Després de demostrar que és un sistema de seguiment de defectes fiable i eficaç, ha d’evolucionar o disminuirà. Per tant, l’empresa XYZ decideix millorar TrackFast convertint-lo en un sistema general de venda de bitllets que pot fer servir el seguiment de qualsevol incident o cas per part de l’empresa que no sigui equips de TI / proves (alguna cosa com JIRA) i no només per defectes en el procés de desenvolupament de programari. .

La roda ha fet un gir complet i us trobeu tractant el sistema com un nou i seguiu l’estratègia que hem comentat a la secció Introducció al producte. Només ara teniu més experiència i coneixement del trepant. Però recordeu, amb cada nou torn apareix un nou repte. Així que estigueu aguts :)

Què us fa provar amb èxit els productes?

  • Comprobadors de productes ha de tenir un sentit empresarial agut, comprendre els models de desenvolupament de lliurament ràpid i ha de ser un proveïdor d'as que no tenen por d'experimentar amb eines i convertir-se en ells mateixos una mica codificadors si cal. Aquestes coses poden tenir un impacte positiu en qualsevol tipus de prova, però són una necessitat absoluta en aquest tipus de proves.
  • Una altra qualitat important és que a el provador de productes ha de creure en el producte i desitjo realment que tingui èxit. Quan, com a provador, penso que el programari és una brossa total, hi ha poques esperances de fer alguna cosa per millorar-lo.
  • Compartiu la visió del propietari del producte o de l'empresa . Si no sabeu cap a on va el producte i com evolucionarà, les proves seran molt limitades.
  • Les habilitats transversals són beneficioses - Saber provar la base de dades, prendre els paràmetres de rendiment, habilitar els certificats de seguretat, implementar-los, etc. Sigues curiós i explora .
  • No fixeu límits - no us penseu que avaluar el manual de l’usuari o comprovar les preguntes més freqüents no és la vostra feina i que un escriptor tècnic se n’hagi de fer càrrec. Bé, haurien de fer-ho i ho faran. Però quan el considereu com una persona privilegiada com algú que coneix el producte per dins, els vostres comentaris són molt útils.
  • Cerqueu comentaris dels usuaris finals. El següent gran grup de persones que fan proves després de vosaltres són els usuaris en temps real. Conèixer i comprendre quin tipus de problemes s’enfronten. Això us ajudarà a millorar el disseny de la prova, de manera que la propera vegada sabreu què heu de fer per evitar-los.
  • Treballa ràpidament i pren decisions
  • Eviteu el deute tècnic . En una situació de desenvolupament i proves ràpides, és fàcil provar de manera exploratòria exclusivament i perdre el marc de referència per a les futures versions. No deixeu que això passi. Mantingueu documentació esquelètica perquè pugueu rastrejar, rastrejar i mesurar

La diferència més gran entre el programari de proves construït com a servei i el programari construït com a producte és que: en el primer, un cop arribada l'estratègia de prova, s'aplica a totes les proves posteriors.

No obstant això, per a un producte, l'estratègia de prova ha de canviar en funció de l'etapa actual del cicle de vida en què es troba el producte i dels canvis en la dinàmica del mercat (nous dispositius, nous navegadors, etc.). L’estratègia de proves de productes ha de ser molt més flexible per canviar.

Sobre l'autor: Aquest article està publicat pel membre de l'equip de STH Swati S.

com obrir fitxers jar amb Java

Esperem que aquest article us hagi estat útil. No dubteu a publicar els vostres comentaris, preguntes i comentaris a continuació.

Lectura recomanada

^