what do clients really expect from software testers
En el artículo de hoy, voy a compartir algunas ideas sobre lo que creo que los clientes REALMENTE esperan de nosotros en base a mi experiencia de primera mano trabajando en ubicaciones de clientes con interacciones diarias cara a cara y colaborando offshore a través de correos electrónicos o llamadas telefónicas.
Los servicios de TI son una parte importante e integral de la industria del software y la satisfacción del cliente es importante para tener éxito. Cada cliente / organización puede ser diferente en su proceso, puede seguir un protocolo diferente y puede tratar con diferentes tipos de negocios.
Pero los siguientes factores son comunes y son importantes para todos en general.
(imagen src )
Lo que vas a aprender:
- 5 cosas que el cliente espera de los probadores de software:
- # 1) Beneficio de costo
- # 2) Calidad del trabajo
- # 3) Comprensión empresarial
- # 4) Disponibilidad
- # 5) Alcance de la mejora
- Conclusión
- Lectura recomendada
5 cosas que el cliente espera de los probadores de software:
# 1) Beneficio de costo
Cuando piensa en vender o comprar algo, el costo juega un papel importante y, a menudo, es uno de los factores decisivos importantes. ¿No esperamos ansiosos el Black Friday, la oferta Flipkart Billion Day o el gran festival de compras de Amazon? Nos convertimos en compradores locos durante el tiempo de venta. Es un comportamiento humano simple esperar el valor correcto o extra por nuestro dinero.
Las empresas y los clientes no son diferentes. Los beneficios de costos impulsan las relaciones con el cliente y el servicio y no es raro que las empresas de servicios pierdan ofertas debido a que los competidores cotizan menos.
La GRAN pregunta ahora es: ¿Cómo podemos mostrar los beneficios de costos a nuestros clientes?
Estos puntos pueden ayudar:
- Muéstrales el valor de su dinero . Justifique y proporcione pruebas de apoyo para su estimados .
- Piense en formas creativas de ahorrar en gastos.
- Adapte su cotización. En lugar de ceñirse a su proceso estándar que cuesta X cantidad de dinero, proporcione alternativas más baratas. Por ejemplo : Sugiera pruebas de ruta crítica en lugar de pruebas completas del sistema.
- Conoce tu competencia . Una verificación rápida de la realidad de lo que otras compañías de servicios ofrecen a sus clientes a qué costos es importante para mantener su modelo de precios en el mercado.
# 2) Calidad del trabajo
La calidad y la cantidad de trabajo son dos cosas muy diferentes.
Atrás quedaron los días en que la cantidad de casos de prueba creados o defectos reportados se usaba para indicadores de productividad o calidad. Ya no.
La situación se parece más a la siguiente imagen:
A) Sepa cuándo decir 'NO'
Todos hemos estado en lugares donde trabajamos horas extras, estuvimos de guardia los fines de semana, asistimos a llamadas nocturnas o temprano en la mañana, etc. Sin embargo, lo que no nos damos cuenta es que podemos decir NO si las cosas continúan empeorando. Decir NO es la única forma en que podemos mantener intacta la calidad del trabajo y nuestra cordura.
Al hacerlo, plantee su preocupación con anticipación y defienda la calidad.
Aquí hay una situación en la que me encontraba y esto podría darte una mejor idea de lo que estoy hablando:
Mi empresa ganó un nuevo logotipo y, como parte de la migración de una empresa anterior a mi empresa, se planificaron sesiones de transferencia de conocimientos. Nosotros, un equipo de 6 miembros, viajamos al sitio del cliente. El primer día después de la presentación, compartimos el plan KT. Descubrí que mi nombre estaba etiquetado con varios módulos. Uno de esos módulos debería haber estado totalmente fuera de mi alcance porque ni siquiera conocía esa tecnología; de ninguna manera coincidía con mis habilidades.
Fui al líder de transición de conocimientos y le conté la situación:
- Se me asignaron demasiados elementos de trabajo, lo que a su vez obstaculizará la calidad y mi capacidad para capturar el 100% en las sesiones.
- Los elementos planificados tenían áreas en las que mis habilidades no coincidían y, como no encajaba bien, es posible que no entienda al 100% durante la transición.
El plomo entendió el problema y revisó el plan KT.
árbol b y árbol b +
Espero que esto ayude a confirmar que: Si hay algo en nuestro plato, no significa que tengamos que comerlo todo. Especialmente no si eso significa comprometer la calidad.
B) Integridad del caso de prueba
¿Cuántos de ustedes están de acuerdo conmigo en que si intentamos mejorar la forma en que escribimos casos de prueba , conduce a una mejor calidad?
A continuación, se muestran algunos errores comunes que son comunes en la mayoría de los casos de prueba:
Componentes del caso de prueba | Problema actual | Solución |
---|---|---|
Objetivo | El objetivo es la parte más importante de cualquier caso de prueba, esto es lo que hace que todos los casos de prueba sean diferentes. Errores comunes con Objective es falta de claridad. Como todos los casos de prueba creados para una funcionalidad, tiene un objetivo sin mostrar en qué se diferencia cada caso de prueba. | El objetivo / propósito de cada caso de prueba debe ser claro para explicar qué funcionalidad y qué condición de prueba se probará como parte de ese caso de prueba. La misma funcionalidad puede tener casos de prueba positivos y negativos, por lo que el objetivo debe ser lo suficientemente claro para mostrar la diferencia. Una buena idea es referir el escenario de prueba para definir el objetivo. |
Condiciones previas | Muchos probadores se olvidan por completo de mencionar la condición previa o muchos simplemente copiarán y pegarán. Copiar y pegar conduce a errores, ya que cada caso de prueba puede ser completamente diferente de otro. | Evite los errores de Copiar-Pegar y preste atención a los detalles. |
Datos de prueba | Este es probablemente el campo que más se pasa por alto y la mayoría de los casos de prueba lo tendrán vacío o sin una definición precisa. | Mencione los datos apropiados para ingresar. A veces, no es necesario que sea preciso. Por ejemplo: el registro de usuario puede registrar un usuario Anna o John y no importaría. Pero definir que un nombre válido que tenga todos los caracteres y que tenga entre 4 y 10 de longitud puede ayudar a aclarar muchas cosas. |
ID de caso de prueba | Sobre convención simplificada de nomenclatura o numeración. Digamos que está probando un botón de inicio de sesión. A menudo, las identificaciones son: TC_1_Login TC_2_Login | Hazlos más descriptivos: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Documentos de referencia | Copiar-Pegar de forma inconsistente de documentos de referencia o peor aún, usar uno incorrecto. | Siempre es aconsejable mencionar el documento de referencia correcto con el número de versión correcto, por ejemplo, para algunos casos de prueba, FRS y especificaciones técnicas se habrían referido a ambos, por lo que el caso de prueba en la sección de referencia debe mencionar ambos. |
Pasos del caso de prueba | Pasos faltantes, en su mayoría por probadores que conocen muy bien la aplicación. Podrían asumir cosas y omitir mencionar los pasos. Esto causa problemas a la empresa, los revisores y los probadores nuevos. | Se deben utilizar los pasos y la secuencia adecuados. |
En resumen, si se tienen en cuenta los pequeños detalles en la fase de diseño, la calidad de salida de la prueba será mucho más superior.
# 3) Comprensión empresarial
Este es uno de los factores más importantes que los clientes buscan en los probadores. Sin embargo, es triste que algunos probadores crean que su trabajo es escribir casos de prueba basados en FRS y no hacer ningún esfuerzo por comprender el negocio.
Primero trate de conocer el negocio y luego investigue la funcionalidad; usted puede visualice las necesidades de su cliente más y pruebe en consecuencia.
Aquí tienes un ejemplo- FRS establece que 'el informe XYZ debe generarse con 3 columnas como Fecha, Nombre y Estado'. Los siguientes son los casos de prueba con los que terminará cuando tome este requisito en su valor nominal:
- Se genera el informe de validación XYZ
- El informe de validación tiene 3 columnas como Fecha, Nombre, Estado
- Valide los datos en 3 columnas.
Pero, cuando tenga en cuenta la aplicabilidad comercial de este informe, es posible que deba probar:
- ¿Cuál es el propósito comercial de este informe?
- ¿Este informe se genera todos los días?
- ¿Quiénes son los usuarios comerciales que miran este informe?
- ¿Cuál es la fuente de datos para este informe?
- ¿Debería generarse el informe si no hay datos disponibles?
Este es solo un ejemplo, pero supongo que todos estamos de acuerdo en que se pueden lograr mejores pruebas adquiriendo conocimiento y experiencia empresarial.
# 4) Disponibilidad
Ya sea que sea una sola persona que brinda apoyo al cliente o un equipo, siempre debe verificar su disponibilidad ( ).
Por disponibilidad, no significa soporte 24/7. Solo significa una comunicación clara y directa sobre el tiempo libre, los planes alternativos y ser accesible y no ir a MIA.
A continuación se muestran algunos de los modelos que sigue la industria de servicios:
- Modelo de aumento de personal - Si está trabajando en un modelo de aumento de personal y es el único representante de su empresa, es recomendable que el cliente conozca sus horarios de trabajo y ausencias planificadas para que se puedan hacer los arreglos necesarios.
- Modelo de proyectos gestionados - En un modelo de proyecto administrado en el que los grandes equipos de proyectos están formados y dirigidos por gerentes de entrega / proyectos, tener un plan de recursos de respaldo ya no es responsabilidad de los clientes. La necesidad de PM de gestionar tanto tiempo libre planificado como no planificado. En este modelo, es aconsejable que los PM intenten recopilar los datos de ausencia planificada de su equipo con anticipación y administrarlos en consecuencia. Hay casos en los que los clientes solicitan soporte durante los fines de semana o un horario de trabajo extendido. Estos casos también deben planificarse mediante la rotación de recursos. Un equipo debe estar formado por miembros que puedan respaldarse entre sí si es necesario. Los detalles planificados deben compartirse con el cliente.
# 5) Alcance de la mejora
Esto no solo es deseable en la industria del software sino en todas partes. Traer mejoras no es un trabajo de un día. El alcance de la mejora debe trabajarse continuamente y se puede dividir en 3 pasos -
También leer=> Cómo mejorar sus habilidades de prueba y vencer a la competencia
Paso # 1: Identificar
Realice un estudio exhaustivo e identifique las áreas / posibilidades de mejora. Por ejemplo, cuando se le pida que pruebe la misma funcionalidad varias veces utilizando el mismo proceso, llegará un momento en el que sentirá que desea salir del proyecto o cambiar la forma en que se prueba. Así es como se introducen las mejoras cuando nos aburrimos de nuestros métodos existentes, pensamos en cambiar y mejorar .
Paso 2: Trae mejoras
Si las cosas se hicieran de forma manual, podría intenta automatizar algunas cosas . Cuando digo automatización, no siempre significa comprar una herramienta automatizada.
Citaré una situación:
Yo era parte de un equipo de prueba de bases de datos. Nuestro trabajo diario implicaba ejecutar los mismos scripts SQL varias veces al día con un conjunto de parámetros diferente. Cuando comenzamos el proyecto estábamos bien con estos pasos, pero finalmente entendimos mejor el sistema y pensamos que los mismos scripts SQL se pueden ejecutar como parte de los procedimientos almacenados en lugar de que alguien actualice manualmente los parámetros y los ejecute.
cómo agregar cosas a una matriz java
Paso 3: Evaluar la mejora
Siempre que se implemente un nuevo proceso, deberá asegurarse de que funcione como se espera y no tenga efectos secundarios. Ampliando el ejemplo anterior, una introducción de los procedimientos almacenados, compruebe si la salida de la forma automatizada recién creada y la salida de la forma manual son iguales.
La otra parte es monitorear los beneficios durante un período de tiempo para estar absolutamente seguro y presentar los resultados a sus clientes. En nuestro proyecto, mostramos a los clientes una reducción en el tiempo de ejecución de las pruebas en un 30%, lo que a su vez redujo los costos.
Conclusión
En conclusión, solo quería mencionar que cada uno de nosotros tiene talentos innatos y todos tenemos nuestros propios estilos de trabajo únicos y estos fueron solo algunos consejos que creo que pueden ofrecer a nuestros clientes una mejor experiencia de servicio.
Sobre el Autor: Este asombroso artículo está escrito por Priya R., miembro del equipo de STH. Si quieres escribirnos y compartir tu experiencia, por favor avísanos aquí .
¡Espero que haya disfrutado leyendo este artículo y lo haya encontrado informativo! Háganos saber si tiene una experiencia diferente para compartir.
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- El negocio global de pruebas de software alcanzará los $ 28.8 mil millones pronto
- Consejos sobre pruebas de software para probadores novatos
- Trabajo de asistente de control de calidad de pruebas de software
- ¿Cómo mantener viva la motivación en los probadores de software?
- Zen y el arte de las pruebas de software
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Elegir las pruebas de software como carrera