what do clients really expect from software testers
A l’article d’avui, compartiré algunes opinions sobre el que crec que els clients REALMENT esperen de nosaltres, basat en la meva experiència de primera mà treballant en ubicacions de clients amb interaccions diàries cara a cara i col·laborant a alta mar mitjançant correus electrònics o trucades telefòniques.
Els serveis de TI són una part important i integral de la indústria del programari i la satisfacció del client és important per tenir èxit. Cada client / organització pot ser diferent en el seu procés, pot seguir protocols diferents i pot tractar amb diferents tipus d’empreses.
Però, els següents factors són comuns i són importants per a tothom en general.
(imatge src )
Què aprendreu:
- 5 coses que el client espera dels provadors de programari:
- # 1) Benefici de cost
- # 2) Qualitat del treball
- # 3) Comprensió empresarial
- # 4) Disponibilitat
- # 5) Àmbit de millora
- Conclusió
- Lectura recomanada
5 coses que el client espera dels provadors de programari:
# 1) Benefici de cost
Quan es pensa en vendre o comprar alguna cosa, el cost té un paper important i sovint és un dels factors decisius importants. No esperem tots amb ganes el Black Friday, la venda de Flipkart Billion Day o el gran festival comercial d’Amazon? Ens convertim en compradors bojos durant el temps de venda. És un comportament humà simple esperar el valor adequat o extra pels nostres diners.
Les empreses i els clients no són diferents. Els beneficis en els costos augmenten les relacions amb el servei al client i no és estrany que les empreses de serveis perdin les ofertes a causa de la competència de cotització més baixa.
La BIG pregunta ara és: Com podem mostrar avantatges de cost als nostres clients?
Aquests punts poden ajudar:
- Mostreu-los els seus diners . Justifiqueu i proporcioneu proves de suport per al vostre estimacions .
- Penseu en formes creatives per estalviar despeses.
- A mida del vostre pressupost. En lloc de seguir el vostre procés estàndard que costa una quantitat de diners X, proporcioneu alternatives més econòmiques. Per exemple : Suggeriu proves de camí crític en lloc de proves de sistema completes.
- Conegueu la vostra competència . Una revisió ràpida de la realitat del que altres empreses de serveis ofereixen als seus clients a quins costos és important per mantenir rellevant el vostre model de preus.
# 2) Qualitat del treball
La qualitat i la quantitat de treball són dues coses molt diferents.
Enrere han quedat els dies en què el nombre de casos de prova creats o els defectes reportats s’utilitzaven per indicadors de productivitat o de qualitat. Mai més.
La situació s’assembla més a la següent imatge:
A) Sàpiga quan cal dir 'NO'
Tots hem estat en llocs on hem treballat hores extres, hem estat de guàrdia els caps de setmana, hem assistit a trucades nocturnes o de matinada, etc. No obstant això, el que no ens adonem és que podem dir NO si les coses segueixen empitjorant. Dir NO és l’única manera de mantenir intacta la qualitat del treball i el seny.
En fer-ho, susciteu la vostra preocupació per endavant i defenseu la qualitat.
Aquí teniu una situació en què em trobava i això us pot donar una millor idea del que estic parlant:
La meva empresa va guanyar un nou logotip i, com a part de la migració d’una antiga empresa a la meva empresa, es van planificar sessions de transferència de coneixement. Nosaltres, un equip de 6 membres, vam viatjar al lloc del client. El primer dia després de la introducció, ens van compartir el pla KT. Vaig trobar que el meu nom estava etiquetat amb diversos mòduls. Un d’aquests mòduls hauria d’haver quedat totalment fora del meu abast perquè ni tan sols era conscient d’aquesta tecnologia; no coincidia de cap manera amb les meves habilitats.
Vaig anar al líder de transició del coneixement i li vaig explicar la situació:
- Se'm van assignar massa elements de treball, que al seu torn dificultaran la qualitat i la meva capacitat per capturar el 100% a les sessions.
- Els elements previstos tenien àrees en què les meves habilitats no coincidien i, com que no era l’adequat, potser no ho entendria al 100% durant la transició.
El plom va comprendre el problema i va revisar el pla KT.
implementar la taula hash c ++
Espero que això ens ajudi a confirmar que: si hi ha alguna cosa al plat, no vol dir que l'haguem de menjar tot. Sobretot no si vol dir comprometre la qualitat.
B) Completesa del cas de prova
Quants de vostès estan d’acord amb mi si ho intentem millorar la forma d’escriure casos de prova , condueix a una millor qualitat?
A continuació es mostren alguns errors comuns que són habituals en la majoria dels casos de prova:
| Components del cas de prova | Problema actual | Solució |
|---|---|---|
| Objectiu | L’objectiu és la part més important de qualsevol cas de prova; això és el que fa que tots els casos de prova siguin diferents. Falta errors de claredat als errors habituals amb Objective. Com tots els casos de prova creats per a una funcionalitat, té un objectiu sense mostrar la diferència de cada cas de prova. | L'objectiu / finalitat de cada cas de prova hauria de ser clar per explicar quina funcionalitat i quina condició de prova es provarà com a part d'aquest cas de prova. La mateixa funcionalitat pot tenir casos de prova positius i negatius, de manera que l’objectiu hauria de ser prou clar per mostrar la diferència. Una bona idea és referir l’escenari de prova per definir l’objectiu. |
| Condicions prèvies | Molts provadors esmenten completament l’esment de la condició prèvia o molts simplement copiaran i enganxaran. La còpia d'enganxar comporta errors, ja que cada cas de prova pot ser completament diferent d'un altre. | Eviteu els errors de copiar-enganxar i parar atenció als detalls. |
| Dades de prova | Aquest és probablement el camp més ignorat i la majoria de casos de prova el tindran buit o amb una definició precisa | Esmenta les dades adequades que cal introduir. De vegades, no cal que sigui precís. Per exemple: el registre d'usuaris pot registrar una usuària Anna o John i no importaria. Però definir que un nom vàlid que tingui tots els caràcters i que tingui una longitud de 4-10 pot ajudar a aclarir moltes coses. |
| Identificador de cas de prova | Més d'una convenció simplificada de numeració o de numeració. Per exemple, esteu provant un botó d'inici de sessió. Sovint, els identificadors són: TC_1_Iniciar sessió TC_2_Iniciar sessió | Feu-los més descriptius: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
| Documents de referència | Copiar-enganxar incoherent de documents de referència o, encara pitjor, amb un document incorrecte. | Sempre és aconsellable esmentar el document de referència correcte amb el número de versió correcte, per exemple, per a alguns casos de prova s’haurien referit FRS i especificacions tècniques, de manera que el cas de prova de la secció de referència hauria d’esmentar tots dos. |
| Passos del cas de prova | Passos que falten, sobretot per verificadors que coneixen molt bé l’aplicació. Podrien assumir coses i deixar de mencionar els passos. Això causa problemes a l'empresa, als revisors i als provadors nous. | S'han d'utilitzar els passos i la seqüència adequats. |
En resum, si es tenen en compte petits detalls en la fase de disseny, la qualitat de sortida de la prova serà molt superior.
# 3) Comprensió empresarial
Aquest és un dels factors més importants que els clients cerquen als provadors. No obstant això, és trist que alguns provadors creguin que la seva feina consisteix a escriure casos de prova basats en FRS i que no facin cap esforç per entendre el negoci.
Intenteu conèixer l'empresa primer i, a continuació, analitzar la funcionalitat; tu pots imaginar les necessitats del seu client més i proveu en conseqüència.
Aquí en teniu un exemple- FRS afirma que “l’informe XYZ s’hauria de generar amb 3 columnes com a Data, Nom i Estat”. A continuació es mostren els casos de prova amb què acabareu quan assumiu aquest requisit al seu valor nominal:
- Es genera un informe de validació XYZ
- L'informe Valida té 3 columnes com Data, Nom, Estat
- Valideu les dades en 3 columnes.
Però, quan tingueu present l’aplicabilitat empresarial d’aquest informe, potser haureu de provar:
- Quin és l'objectiu comercial d'aquest informe?
- Es genera aquest informe cada dia?
- Qui són els usuaris empresarials que consulten aquest informe?
- Quina és la font de dades d’aquest informe?
- Cal generar l'informe si no hi ha dades disponibles?
Aquest és només un exemple, però suposo que tots estem d’acord que es poden aconseguir millors proves augmentant la consciència i l’experiència empresarial.
# 4) Disponibilitat
Tant si sou una persona individual que dóna suport al client o com un equip, sempre s’ha de comprovar la vostra disponibilitat ( 
).
Per disponibilitat, no significa assistència les 24 hores del dia, els 7 dies de la setmana. Només significa una comunicació clara i directa sobre el temps lliure, els plans alternatius i ser accessible i no passar a MIA.
A continuació es mostren alguns dels models que segueix la indústria dels serveis:
implementació de la taula de hash c ++
- Model d’augment de personal - Si esteu treballant en un model d’augment de personal i sou l’únic representant de la vostra empresa, és recomanable que el client tingui coneixement dels vostres horaris laborals i de les absències previstes perquè es puguin fer les gestions necessàries.
- Model de projectes gestionats - En un model de projecte gestionat en el qual es formen grans equips de projecte i estan dirigits per gestors de lliurament / projecte, tenir un pla de recursos de còpia de seguretat ja no és responsabilitat dels clients. La necessitat del primer ministre de gestionar temps lliure previst i no previst. En aquest model, és aconsellable que els primers ministres intentin recollir amb antelació les dades d’absència previstes del seu equip i gestionar-les en conseqüència. Hi ha casos en què els clients sol·liciten assistència el cap de setmana o un horari de treball ampliat. Aquests casos també s’han de planificar mitjançant la rotació dels recursos. Un equip ha d’estar format per membres que poden fer còpies de seguretat mútuament si és necessari. Les dades previstes s’han de compartir amb el client.
# 5) Àmbit de millora
Això no només és desitjable a la indústria del programari, sinó a tot arreu. Portar millora no és una feina d’un sol dia. L'abast de la millora s'ha de treballar contínuament i es pot dividir en 3 passos -
Llegiu també=> Com millorar les vostres habilitats de prova i superar la competència
Pas 1: identifiqueu-lo
Feu un estudi exhaustiu i identifiqueu les àrees / abast de les millores. Per exemple, quan se us demani que proveu la mateixa funcionalitat diverses vegades amb el mateix procés, arribarà un moment en què sentireu que voleu sortir del projecte o canvieu la manera de provar-lo. Així s’obtenen millores quan ens avorrim dels mètodes existents, pensem en canviar i millorar .
Pas 2: Inclou millores
Si es fessin les coses de forma manual, podríeu fer-ho intenteu automatitzar poques coses . Quan dic automatització, no sempre vol dir comprar una eina automatitzada.
Citaré una situació:
Formava part d’un equip de proves de bases de dades. El nostre treball diari implicava executar els mateixos scripts SQL diverses vegades al dia amb un conjunt de paràmetres diferents. Quan vam començar el projecte, estàvem bé amb aquests passos, però finalment vam entendre millor el sistema i vam pensar que es podrien executar els mateixos scripts SQL com a part dels procediments emmagatzemats en lloc d’algú que actualitzés i executés els paràmetres manualment.
Pas 3: Avaluar la millora
Sempre que s’implementi un nou procés, haureu d’assegurar-vos que funciona correctament i que no té efectes secundaris. Ampliant l'exemple anterior, una introducció de procediments emmagatzemats, comproveu si la sortida de la forma automatitzada de nova creació i la sortida de la manera manual són iguals.
L’altra part és supervisar els beneficis durant un període de temps per estar absolutament segurs i presentar els resultats als vostres clients. En el nostre projecte, vam mostrar als clients una reducció del 30% del temps d’execució de la prova, que al seu torn va reduir el cost.
Conclusió
En conclusió, només volia mencionar que cadascun de nosaltres té talent innat i que tots tenim els nostres propis estils de treball únics, i aquests són només alguns consells que crec que poden oferir als nostres clients una millor experiència de servei.
Sobre l'autor: Aquest impressionant article està escrit per Priya R., membre de l'equip de STH. Si voleu escriure per a nosaltres i compartir la vostra experiència, si us plau feu-nos-ho saber aquí .
Espero que us hagi agradat llegir aquest article i us hagi estat útil. Feu-nos-ho saber si teniu una experiència diferent per compartir.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- El negoci global de proves de programari arribarà aviat a 28,8 mil milions de dòlars
- Consells sobre proves de programari per a provadors novells
- Prova de programari Treball d'assistent de control de qualitat
- Com mantenir la motivació viva als provadors de programari?
- El Zen i l’art de provar programari
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Selecció de proves de programari com a carrera professional