my unexpected journey becoming software tester
'Construyes una vida exitosa ... un día a la vez ...'
Mi viaje como tester de software comenzó de forma inesperada.
Aparecí para las rondas de entrevistas iniciales asumiendo que era una oportunidad de desarrollo. Para ser honesto, como todos los graduados en Ciencias de la Computación, era un poco escéptico acerca de seguir adelante con Testing.
Pero finalmente, decidí intentarlo. Solo con la esperanza de que mi naturaleza curiosa me ayude en este campo.
No podría aceptar la oferta sin hacer esta pregunta: ¿Tendré la oportunidad de cambiar a Desarrollo en caso de que Testing no me interese? :).
Créeme, nunca se me ocurrió dejar Testing después de eso.
qué programas pueden abrir un archivo dwg
Cuando aparecí para la ronda técnica, no estaba preparado para nada más que para concepto básico de pruebas de software . Supongo que lo único que me atrajo fue la idea de que me están evaluando lógicamente y no teóricamente ”.
Este fue mi primer aprendizaje en Testing: entendí cómo nosotros ( novatos ) fueron evaluados.
Incluso hoy en día, utilizo técnicas similares al contratar nuevos empleados para mi equipo. Verifico su lógica, tenacidad y enfoque ante un problema por encima de cualquier otra cosa.
Lectura recomendada => 4 cosas importantes que aprendí en mi viaje como gerente de pruebas de control de calidad
Me uní a Zycus como aprendiz de control de calidad y me asignaron un producto en un tercer o cuarto día. Era uno de los productos más grandes (estaba en concepto entonces) y más ambiciosos de la empresa. Después de establecerme durante las primeras semanas, no hubo vuelta atrás para mí.
Comenzamos como un equipo de control de calidad de dos y poco después de unos meses yo era el único que impulsaba los esfuerzos de prueba. En los primeros 2 a 2,5 años, había registrado casi 3000 defectos en diferentes categorías, como funcional, rendimiento, seguridad, interfaz de usuario, usabilidad, Plurilingüe , Multicliente, etc.
Durante un tiempo considerable, antes de las nuevas incorporaciones al equipo de pruebas, me enfrenté a un sólido equipo de desarrollo de 15-16 miembros. Incluso después de las adiciones, la proporción de QC: Dev no fue muy saludable y todavía puedo decir con orgullo que fue un viaje exitoso considerando todo lo que probamos, entregamos y manejamos.
El punto importante que quiero resaltar aquí es: Todo esto se debió a la comprensión de las pruebas en la práctica y no solo a la teoría.
He estado en el campo de las pruebas de software durante casi seis años. Ha sido un viaje increíble con tantas experiencias diferentes y mucho aprendizaje fructífero.
Actualmente, trabajo como Senior QA Manager y me ocupo de 5-6 productos y módulos. Pero lo que me da verdadera alegría y felicidad es liderar un equipo de más de 30 probadores felices y apasionados.
Por supuesto, muchas personas han contribuido a mi aprendizaje, pero aún puedo decir que la mayor parte de mi experiencia y conocimiento han llegado por el camino difícil (y probablemente el mejor), es decir, aprendiendo / resolviéndolo por mi cuenta.
'La experiencia es el mejor maestro.'
Mientras digo esto, no quiero decir en absoluto que no se beneficiará de aprender o seguir teorías documentadas sobre las pruebas de software. Lo que creo es que todo esto seguramente ayudará, pero nada puede superar comprender el concepto en el núcleo y enfrentar los problemas con valentía.
Creo que las cosas documentadas no te enseñarán prueba real , aunque puede darte alguna dirección y luego estarás solo. Al menos en mi caso, hubo problemas que pueden no estar documentados para resolver mis problemas exactos o no pude encontrarlos a tiempo. Mi única opción era comprender el problema / situación en el núcleo y reaccionar con el enfoque que encontré correcto.
Ejemplos: cómo me acerqué en diferentes situaciones
Permítanme explicar esto con la ayuda de problemas / situaciones a las que me enfrenté y cómo los abordé.
# 1) La comprensión empresarial es superior a la comprensión de las pruebas
Bueno, todos lo saben. Probar no es solo probar algunas validaciones y realizar alguna verificación.
Como probador, se supone que debemos visualizar todos los escenarios posibles, incluso el más raro de los escenarios raros sin falta. Se supone que debemos considerar todos los datos de prueba posibles que el usuario real podría estar usando.
Para todo esto, se supone que debemos entender el negocio al máximo.
No estaría mal si digo que debemos entender el negocio y la base de usuarios tanto o incluso más que un analista de negocios.
Me enfrentaba a probabilidades similares.
Se suponía que comprender escenarios comerciales complejos en el ámbito de las adquisiciones, realice una lluvia de ideas sobre los nuevos requisitos y evalúelos desde la perspectiva del usuario. No solo se suponía que debía resolver mis casos, sino también contribuir en las fases de Requisitos y Diseño de cada iteración. Incluso aquí, ninguna referencia inmediata vino a mi rescate aparte de mi capacidad de pensar y razonar.
Para comprender mejor el negocio y diseñar mejor sus escenarios / casos, nada funciona como papel y lápiz.
Leer también => 5 herramientas imprescindibles que no requieren pruebas para que los probadores hagan la vida más fácil
Antes de ir a Discusión de requisitos reunión, solía anotar posibles dudas / correcciones / puntos poco claros de antemano. Solía escribir los escenarios que quiero probar o construir casos de prueba; a veces, incluso dibujar tus escenarios funciona de maravilla.
Cuando escribes / dibujas, entra en tu mente con mayor claridad y luego tu mente trabaja con esta información y produce más escenarios y da mejor claridad. ¡¡¡Esto continúa hasta que tengas esa sensación de HECHO !!!
# 2) Actuando contra viento y marea y bajo presión
Estaba trabajando en un producto que era / es lo suficientemente grande y complejo como para hacer que un equipo de 30 ingenieros trabaje continuamente durante tres largos años para llevarlo a un nivel vendible.
Durante la mayor parte de la fase inicial, me enfrenté (solo) a un equipo de 15 a 20 desarrolladores que iban desde el nivel junior, intermedio y senior, o estuve acompañado por uno o un par de probadores. Todos estaban agregando nuevas funciones al producto sin descanso, lo que requería una atención igual y paralela por parte de las pruebas.
Ser parte de reuniones de requisitos, redactar casos, ejecutarlos, rondas exploratorias, mantener servidores, implementaciones, nada era opcional.
Para entonces yo no conocía ninguna metodología, mejores prácticas , curso o un libro que pueda mostrarme soluciones a tales problemas. Incluso hoy en día, no estoy seguro de si hay algo que pueda ayudarte precisamente a luchar contra las realidades básicas cuando las enfrentas.
Lo que estaba haciendo más bien es, agresivo y rondas rápidas de pruebas exploratorias (No sabía el nombre para ese entonces) en cada función una por una y luego repita. Esta solución se basa únicamente en la rapidez con la que puede cambiar sus pensamientos y enmarcar situaciones / escenarios.
Por supuesto, esto exigió un trabajo realmente rápido y agresivo, pero funcionó para mí.
Lo que quiero decir con ronda agresiva es, apuntas a una cosa a la vez (Diga un elemento de un formulario a la vez) y pruébelo de forma independiente y en asociación con otros elementos / cosas vinculados.
Lectura recomendada => Cómo ser un adicto a la productividad (especialmente como tester)
P.ej. Cómo probar un cuadro de texto.
Lo que puedes probar aquí es:
- Si acepta y almacena datos tal cual
- Validación del tipo de datos
- Validación de longitud máxima
- Manejo de personajes especiales
- Manipulación XSS
- Manejo de datos multilingües
- Manejo de espacios vacíos / sin datos
- Comportamiento de las teclas de tabulación e introducción
- Manejo de errores (varios navegadores)
- Alineación de la interfaz de usuario (varios navegadores)
- Copiar pegar datos / arrastrar datos de enlaces al cuadro de texto
- Lo más importante: el comportamiento de este campo w.r.t. otros elementos vinculados (cualquier expectativa comercial vinculada a este campo, como completar algo en otro campo en función de los datos de este campo)
¿Pensar en las pruebas anteriores le da la confianza de que nada puede salir mal en este campo?
Bueno, apuntar a una cosa a la vez siempre funcionó para mí y también solía terminar un poco el trabajo.
# 3) Cuando te enfrentas a lo 'inesperado'
¿Qué libro crees que te ayudará de repente con 'Cómo hacer' cuando se supone que debes hacer algo que nunca antes has hecho?
Si hablamos específicamente, entonces ... Ninguno.
Recuerdo el momento en que, en ausencia de nuestro líder de Producto, se suponía que yo, junto con algunos otros miembros junior y mid-senior, desplegaríamos nuestra aplicación en una instancia de demostración (era producción para nosotros en ese momento) por primera vez. Fue muy importante para la primera demostración de nuestro producto.
Bueno, lo hicimos, pero con muchas pruebas y errores. La razón es que ninguno de nosotros tenía experiencia en Linux y scripts de shell . Recuerdo que nuestro departamento de TI (todo de buena fe) planteó preocupaciones a mi entonces Gerente acerca de que yo ejecutaba comandos incorrectos en los servidores de producción. Tal vez esto era solo un catalizador y la creación de scripts de shell / Linux era mi interés natural, pero poco después de eso, terminé asumiendo la responsabilidad de mantener y actualizar de cinco a seis entornos simultáneamente.
Shell y Linux captaron mi interés tan bien, que pronto fui yo quien comencé a realizar sesiones de capacitación interna al respecto.
# 4) Cuando se mide su desempeño, su experiencia no es
Muy temprano en mi carrera, me compararon y me midieron con los probadores muy evolucionados y experimentados que había alrededor. Creo que muchos de ustedes deben haber experimentado una situación similar y saber lo que esas expectativas adicionales les hacen.
El remedio aquí fue Empujarme y evolucionar .
La única forma de avanzar era no pensar en lo menos experimentado que soy, sin limitarme a los estándares mundiales de medir qué tan lento / rápido debería crecer / aprender. Sin limitarme a los criterios de World sobre qué tan pronto se debe comenzar a liderar y el título que se necesita antes de hacerlo.
Bueno, en este punto, debo decir, independientemente del campo al que pertenezca, le recomiendo que lea The Leader Who No Title de Robin Sharma. Te ayudará a dar rienda suelta a lo que hay dentro de ti. Le dirá que nadie excepto usted puede detenerlo.
Si tengo que unir mi experiencia en pocas oraciones, dice así:
“Su curiosidad, atención a los detalles, disciplina, pensamiento lógico, pasión por el trabajo y capacidad para analizar las cosas es todo lo que importa para ser un Tester Destructivo y Exitoso. Me funcionó y creo firmemente que funcionará para usted. Si tienes estas cualidades, tiene que funcionar para ti '.
Bueno, leyendo hasta aquí, si estás pensando que estoy promoviendo las cualidades humanas básicas sobre un conocimiento teórico más profundo, entonces eso no es completamente cierto. Creo que para empezar con algo y probar el éxito en ello, depende un poco más de tus cualidades inherentes que de la información que hayas aprendido. Sin embargo, para llegar lejos en cualquier campo, es necesario aprender lecciones, principios y experiencias.
En mi caso también, tuve que aprender las terminologías, conceptos, teorías hasta cierto punto a medida que avanzaba en mi carrera. La razón es que, como evaluador, debes interactuar con varias personas que hablarán en esos términos y debes entenderlo.
sistemas operativos de código abierto para pc
Como líder o co-evaluador, tendrá un nuevo evaluador proveniente de alguna parte del mundo con su propio conocimiento de hechos, definiciones y terminologías. Aquí también, no puede permanecer pasivo hacia estas cosas; debe tener un conocimiento previo sobre el máximo de cosas posibles que se usan / dicen.
El aprendizaje es inevitable.
Tenía que aprender más sobre los diferentes tipos de pruebas, cómo ejecutarlas y formas de explicárselo a las personas de mi equipo en la etapa correcta. Tuve que evaluar nuevas ideas, herramientas e implementarlas. Aprender nuevos conceptos y metodologías se vuelve igualmente importante a medida que asciende en la escalera.
Leer más => La guía de la A a la Z sobre cómo seleccionar la mejor automatización
Conclusión
Aunque es casi imposible escribir cada cosa importante y minuciosa que he aprendido durante años, este es mi intento de resumirlo en una lista con viñetas.
- Las pruebas son muy difíciles de definir. Alguien puede hacer pruebas excelentes y es posible que no pueda definirlo con palabras. Es como lo ves.
- Todos pueden tener su propia definición de prueba. El mío era simple 'Se te da una cosa: encuentra fallas y hazlo mejor'.
- No necesitas necesariamente grandes teorías, matrices complejas o ISTQB para ser un tester destructivo. Tienes que ser curioso , centrado y apasionado, piensa lógicamente y tiene capacidad de disección. Sin embargo, saber más no hace daño, pero no a costa de perder el quid.
- Los enfoques / conceptos tradicionales también tienen su propia importancia y tengo el mismo respeto hacia ellos considerando el hecho de que hay una buena parte del mundo donde esos son una necesidad justa. Las pruebas por sí solas no pueden evolucionar; el entorno también tiene que evolucionar para eso.
- Como evaluador, es igualmente importante aprende nuevo herramientas, técnicas y metodologías a medida que avanza . Planificación de pruebas, mejores enfoques para realizar diferentes tipos de pruebas, pruebas situacionales son algunas de las que se mencionan.
- Como las pruebas son fluidas, la definición de ser el adecuado también difiere enormemente de una organización a otra. Ser un evaluador destructivo o excelente podría ser lo suficientemente bueno como para obtener un cheque de pago si tiene suerte o puede exigir un conocimiento adicional de cómo funcionan las pruebas en las empresas tradicionales. Ambos están en su propio lugar.p.ej.Contrato personas de acuerdo con mi definición de prueba (que varía un poco según la experiencia y el perfil del candidato, por supuesto).
- Como hay un estilo de codificar, conducir, cocinar; también hay un estilo de prueba. Puede que no lo disfrutes a menos que lo hagas a tu manera. Lo que quiero decir es que las pruebas pueden tener pautas, pero no deberían estar limitadas por los microprocesos.
- El plomo efectivo Debe hacer que su equipo elija el trabajo en lugar de asignarlo. Ocasionalmente, puede modificarlo para mejorar el Producto.
- Trate de capacitar a su gente en su área de interés y junto con el lugar donde desea que se capaciten. Alinee los pensamientos y esfuerzos de su equipo con el objetivo final, que es 'La mejor calidad'.
- No intente administrar a su gente, diríjalos. Sea amigable y accesible, hace que el trabajo sea mucho más fácil.
- Cada miembro de su equipo debe amar el trabajo que está haciendo, tener un apego al producto y ser cariñoso con las personas que lo rodean. Entonces solo saldrá lo mejor de ellos.
- El mundo de las pruebas tiene que evolucionar. Una parte considerable de World se está moviendo hacia enfoques más prácticos como las pruebas exploratorias, las pruebas basadas en el contexto (que muchas personas hacen sin saberlo) que incluso otros deberían probar y desarrollar más técnicas como la
- Deberían formarse más comunidades de prueba y personas de ideas afines deberían reunirse en una escala mayor. Hay mucho que compartir, aprender, adaptarse e innovar.
Espero que mi experiencia y mis hallazgos lo ayuden a convertirse en un mejor evaluador o lo ayuden a comprender mejor las pruebas.
Más lecturas => De principiante a profesional: una guía completa para el viaje exitoso de un profesional de pruebas
Sobre el Autor: Este artículo fue escrito por el miembro del equipo de STH, Mahesh C. Actualmente se desempeña como Gerente Senior de Garantía de Calidad y tiene experiencia en el frente de pruebas para múltiples productos y componentes complejos.
Me encantará recibir noticias. Comente aquí o comuníquese con nosotros. Muchas gracias por leer.
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Trabajo de asistente de control de calidad de pruebas de software
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Elegir las pruebas de software como carrera
- Prueba de software Escritor de contenido técnico Trabajo autónomo
- Algunas preguntas interesantes de la entrevista sobre pruebas de software
- Comentarios y revisiones del curso de pruebas de software
- Guía de currículum vitae de prueba de software perfecta (con muestra de currículum vitae de Software Tester)