Estamos contratando a una persona de control de calidad y se supone que debo formular algunas preguntas para la entrevista. La verdad es que no sé mucho sobre lo que debería saber un buen ingeniero de control de calidad, y mucho menos sobre las buenas preguntas de la entrevista. ¿Alguien tiene sugerencias?
Alguna información: El entorno es dos aplicaciones web separadas (pero entrelazadas) para la pila de Microsoft (ASP.NET, SQL Server, IIS).
Respuestas:
A menos que tenga mucha experiencia trabajando con probadores, lea los primeros capítulos del "Testing Computer Software" de Cem Kaner para tener una idea del tipo de términos que desea escuchar: prueba de límites, prueba de error, prueba de ruta feliz, funcional, rendimiento, seguridad, integración, etc. Si no puede hablar el idioma, no podrá realizar una buena entrevista.
Dales una especificación para una pequeña parte de tu sistema. Pídales que lo prueben. Está buscando la organización del pensamiento y su capacidad para presentar pruebas interesantes. Desea verlos separar las áreas de prueba de manera ordenada y luego profundizar en cada área, ideando casos de prueba cada vez más interesantes. Los probadores realmente buenos pueden hacer esto durante horas con todos los problemas menos triviales, por lo que es posible que deba cortarlos y hacer que pasen a otra categoría para tener una buena idea de cómo piensan.
Describa el comportamiento causado por un error real en su sistema que fue difícil de entender. Pregúnteles qué harían si vieran este error durante la prueba. Aquí, está buscando la reducción de errores: la capacidad de encontrar el conjunto más simple de circunstancias que pueden reproducir un error. Esto hace que la depuración sea mucho más fácil para los desarrolladores, ya que tienen una mejor idea de lo que causó el problema y demuestra una capacidad clara para resolver problemas y una comprensión clara de qué factores pueden interactuar para causar errores. Con su producto específico, discutir una condición de carrera puede ser divertido.
Dales un programa de línea de comando simple que hackeaste juntos (tal vez sembrado con errores) y una especificación simple, y déjalos sentarse en la computadora y jugar con ella, con el objetivo de encontrar problemas. Aquí está buscando creatividad y la capacidad de apuntar a áreas problemáticas. Deben probar cosas como entradas grandes, entradas pequeñas, entradas extrañas, entradas vacías. Si encuentran un error, pídales que intenten averiguar exactamente cuándo ocurre ese error (¡nuevamente con la reducción del error!).
Pregúnteles qué harían si un SDE responde a un error con "No Repro" o "Won't Fix", si piensan que el error es importante. Aquí estás buscando a alguien que no solo sea un imitador, sino que tampoco sea antagónico. Las respuestas razonables incluyen agregar escenarios de ejemplo que demuestren más claramente la gravedad del error y luego volver a abrir el ticket, hablar con el desarrollador para tratar de entender por qué las cosas se resolvieron de esta manera antes del cierre, etc.
Hable con ellos sobre su aplicación a un alto nivel. Pregúnteles qué tipo de pruebas les gustaría realizar. Aquí está buscando áreas generales de prueba como pruebas de componentes funcionales, pruebas de integración, pruebas de rendimiento, pruebas de seguridad.
Si se trata de un ingeniero de automatización / SDET, bríndeles algunas preguntas de entrevista para desarrolladores con aproximadamente 1/3 a la mitad de sus años totales de experiencia.
Si esta es su primera persona de control de calidad, asegúrese de que pueda comenzar por sí misma. Pregúnteles cómo se ven su primera semana o mes de trabajo. Deberían decir algo sobre la recopilación de requisitos y la configuración de herramientas, y luego describir un enfoque razonable para comenzar con las pruebas. Estás buscando a alguien que no necesita un jefe que les diga cómo comenzar a realizar las pruebas y que puedan autogestionarse. Si ya tiene personal de control de calidad, esto es menos importante.
Lo que hago cuando entrevisté a los candidatos de control de calidad es pedirles que esbocen una estrategia de prueba para una solicitud. Por lo general, les doy mi teléfono y elijo una aplicación con funciones limitadas, o les dejo elegir algo con lo que estén más familiarizados. Cuando enumeran una estrategia de alto nivel (algunas no pueden), podría pedirles que profundicen y enumeren algunos casos de prueba.
Una vez hecho esto, podría darles un escenario en el que tenemos recursos limitados y ver cómo se priorizan.
También les pregunto cuándo el software es lo suficientemente bueno para enviar, cómo manejar situaciones en las que PM o dev no sienten un error, pero lo hacen. Escenarios típicos de desarrollo de productos.
Estos son para posiciones de control de calidad sin codificación. Codificación de puestos de control de calidad Les doy una entrevista combinada de desarrollo / prueba.
Pregúnteles cómo diseñarían los planes de prueba. Pregúnteles si tienen experiencia en el uso de pruebas de regresión y cómo lo hicieron si es así. Pregúnteles cómo hacen para probar una interfaz de usuario. Pregúnteles cómo harían para probar las importaciones de datos que no pasan por la interfaz de usuario (si hace tales cosas). Pregúnteles cómo comunicarían sus problemas a los desarrolladores y cómo verificarían la resolución del problema. Les preguntaría sobre el error más interesante (o más difícil de encontrar) que encontraron y cómo lo encontraron.
Antes de comenzar a entrevistar, busque algunos de los libros sobre pruebas y analice un poco lo que una persona de control de calidad debería hacer. Eso te ayudará a evaluar sus respuestas.
Además, también está buscando un buen ajuste de personalidad. No quieres una persona de control de calidad que sea un imitador, pero tampoco quieres un matón o un imbécil. Pero sí quiere a alguien que se enfrente a la gerencia cuando las cosas están mal y no solo apruebe todo porque la gerencia quiere cumplir con una fecha límite. Desea a alguien que trabaje con los desarrolladores de manera efectiva y que comprenda los requisitos de lo que están probando. Alguien con experiencia en el tipo de aplicación que está probando podría ser bueno. Un evaluador con experiencia en el cuidado de la salud sabrá cosas para evaluar que alguien que viene de otro campo puede no estar al tanto.
Supongo que no puede esperar que tengan un conocimiento serio de la tecnología; quien sea que lo haga probablemente rechazará trabajar como probador mundano.
Lo mejor que puede hacer es buscar cosas comunes como atención a los detalles, mente inquisitiva, entusiasmo por la experimentación, etc.