¿Qué preguntas de la entrevista debe preguntar a un desarrollador de un probador?

Question

Tenemos algunas entrevistas que vienen con lo cual estamos reclutando para un papel de garantía de calidad. El propósito de los desarrolladores están involucrados es entender si la persona HTE funcionará bien con el equipo de desarrollo.

¿Cuáles son los más pregunta (s) importante que un desarrollador debe pedir a una persona de control de calidad? Busco cuestiones prácticas más preguntas abiertas mullidas, sus pensamientos?

Answer 1

Por desgracia, a veces, las preguntas abiertas suaves son los que le dan la mejor vista de una persona.

Lo que preguntas que usted (y esto depende mucho de su metodología de desarrollo, así que no puedo ayudarle allí, ellos deben adaptarse), se debe establecer siempre cómo el candidato potencial trabajar en un ambiente de equipo.

Es necesario establecer que:

• la persona que va a funcionar bien en el equipo.
• la persona que va a asumir la responsabilidad de trabajar con el desarrollo para obtener errores corregidos, no sólo "Aquí hay un error, vaya solucionarlo, a continuación, volver a mí".
• ego de la persona no se pondrá en el modo de trabajo del equipo (por ejemplo, la lucha por la clasificación o gravedad de los errores). Me parece que este es por lo general más de un problema con los desarrolladores de ponerse a la defensiva de "su" código.

Me parece el mejor enfoque en las entrevistas es presentar escenarios y pedirle al candidato lo que piensan, por ejemplo:

• es 16:00 viernes por la tarde y Bob, un desarrollador, ha acordado trabajar hacia atrás para corregir un error de alta severidad. Necesitamos un probador para validar la solución y usted es el único disponible, pero que tenía un arreglo de la cena. ¿Qué propondría usted?

Sólo en la respuesta a esa pregunta solo, se podría evaluar si el candidato:

• Es inútil ( "Lo siento, no puedo perder la cena").
• piensa restricciones externas ( "¿Hay realmente no hay otros probadores disponibles?", "¿Puedo validar que el sábado por la mañana?", "¿Puedo Bob trabajar en otro momento en el fin de semana?").
• Es adaptable ( "Yo podría poner fuera de la cena sólo por esta vez").

y así sucesivamente.

No puedo expresar también cómo las habilidades de comunicación son importantes para la relación desarrollador / probador. Haga que el probador de generar un informe de error en bruto (cualquier error que quieren) y discutir su idoneidad (pasos exactos, el comportamiento esperado, el comportamiento real, ...).

Answer 2

Además de las respuestas más profundas en este tema, no es una simple pregunta que a menudo se pasa por alto:

¿Se puede actuar como un usuario normal, o sin experiencia?

Ahora, esto parece tonto, pero da una idea muy buena. Si el candidato dice que sí, francamente, no son lo que parecen ser. Ninguna persona que trabaja en el campo de la tecnología de la información en un desarrollo (en particular), análisis o prueba de papel puede hacer esto; simplemente por el hecho de que nos hemos pasado el nivel de un usuario sin experiencia. La respuesta a continuación, debe buscar es:

No, sin embargo puedo crear casos de prueba que pueden asignar con precisión a una "llamada" comportamiento de los usuarios normales.

O un derivitive de esto. Esto demuestra una cierta información importante.

1. Son realistas
2. Se puede pensar fuera de la caja
3. Ellos están dispuestos para llevar a cabo los métodos apropiados puestos sobre en QA

Esto es lo que he encontrado por lo menos.

Espero que esto ayude de una manera u otra.

Answer 3

Mi sugerencia sería considerar cuestiones un tanto indefinidos como esta:

  

Si me acerqué a ti y dijo, "¿Podría   probar esta nueva cosa que hice?" lo   serían sus primeras preguntas?

Aquí están algunas ideas que tendría en pedir que:

1. ¿Hay mención de las especificaciones o requisitos? Si no los hay, ¿cómo que las pruebas de impacto?
2. ¿Es que quieren que me conecto con ellos para que puedan saber lo que hice?
3. es lo que quieren saber lo que hice?
4. ¿Tienen tiempo para hacer esto y preguntar cuánto tiempo creo que esto puede tomar?
5. ¿Qué tipo de pruebas son sus expectativas: Integral, prueba de humo, pasillo usabilidad
6. ¿Qué tipo de herramientas se utiliza para hacer esto?

  

En la grabación de un error, por lo que es el   información mínima que cree una   desarrollador debe tener antes de fijar   que?

Este es el tipo de pregunta, donde dependiendo de qué tipo de fondo que tienen que probablemente será un factor en su respuesta como un par de cosas a tener en cuenta se incluyen los siguientes:

• La reproducibilidad - Se puede conseguir esto de una manera predecible?
• Pasos de reproducibilidad
• ¿Es este un código, datos, red u otro tipo de error?
• ¿Qué tan grave es el error en alguna escala?
• Medio ambiente - ¿qué necesito para que esto suceda de nuevo? ¿Hay navegadores, sistemas operativos u otras cosas que debería haber?
• ¿Qué es los resultados esperados y reales que ilustran que este es un error?
• Versión de software - Este fue encontrado en lo que la acumulación del sistema
?

menciono la mayor parte de estos, porque eso es lo que estaría pensando en pedir que en términos de qué parámetros es lo que inicialmente tienen cuando se les da una vaga pregunta o solicitud que debe tener más detalles, pero que detalla la materia es el problema. También me gustaría señalar el tiempo de la pausa fue tomada en dar una respuesta en la que diría que 15-30 segundos es OK, nada menos y yo creo que era una pregunta anticipado y si se necesita más que eso no debería como una solicitud de un par de minutos a pensar en ello, ya que el punto es que cuando surge esta situación ¿cuál es la expectativa de cada lado?

Otra idea sería hablar de lo que la metodología de desarrollo de software que utiliza y luego preguntar qué retos se había relacionado con el control de calidad con el uso de este enfoque? Por ejemplo, si los desarrolladores utilizan TDD cómo afecta eso de control de calidad? ¿Y si se trata de un enfoque más cascada-como? Lo que quiere ver aquí es qué tan bien pueden pensar en sus pies, así como qué tipos de preguntas de seguimiento sobre lo que se utiliza se les pide que realmente si digo que utilizamos Scrum, ¿qué tan bien que definen la ejecución del general conceptos de Scrum, la verdad.

Answer 4

Un desarrollador puede comprobar dándole un escenario que debe comprobar lo siguiente

Actitud

¿Los tester posee una actitud de sondeo? darle un escenario y comprobar cuántos pregunta válida es que él / ella pidiendo?

Habilidades

Se requieren

Varias habilidades relacionadas con las pruebas en cada proyecto que se trabaja en. que incluye el estudio de requerimientos, diseño de pruebas, ejecución de la prueba y así sucesivamente. Comprobar lo bien que es el probador en la comprensión de la exigencia.

Conocimiento

Comprobar la amplitud y profundidad del probador en el campo donde se va a contratar el probador. Incluso si el probador no está trabajando en el campo actual, comprobar cuánto sabe el probador sobre ese campo.

accesibilidad

Dar el probador de un escenario como hay un problema de cliente y el desarrollador está de baja durante toda la semana. El tema debe ser aumentado de manera urgente y como probador se trataba de usted para encontrar la causa raíz del problema. ¿Cómo va a abordar en tal situación

Answer 5

Algunos de los elementos clave que buscamos en las personas de calidad de software:

• comunicación - puede escribir el candidato / correo / hablar de una manera clara y concisa para que otros miembros del equipo puede entender el defecto que han descubierto
• solución de problemas - Aquí es donde las preguntas del rompecabezas entrevista son útiles. Con este tipo de preguntas, es más importante aprender cómo un candidato atacar un problema en comparación con lo cerca que vienen a determinar "cuántos coches azul se encuentran en los EE.UU.".
• responsabilidad - Es importante entender si es o no el candidato seguirá adelante. Éste es más difícil de encontrar la verdadera respuesta para ya que las personas son entusiastas durante las entrevistas y pueden estar de acuerdo en muchas cosas, pero no en serio. historias pasadas de los candidatos sobre la forma en que manejan un problema o asunto pueden ser útiles. Los puntos de bonificación si el problema empeoró por el candidato y se quedaron en la parte superior de la misma.
• conocimientos técnicos - El nivel requerido por este concepto variará dependiendo del probador: ¿serán escribir pruebas automatizadas? ¿Prueba manual? Las pruebas automatizadas requieren al menos cierto grado de experiencia técnica, mientras que las pruebas manuales requeriría menos. De cualquier manera, tener un probador que es al menos familiarizados con los aspectos técnicos de una aplicación puede ser muy útil cuando se trata de trabajar sobre un tema.

Answer 6

Creo que esto realmente depende del tipo de probador que busca. ¿Está buscando a alguien para empujar los botones y le dirá que no se ve bien o está buscando a alguien que pueda entender la tecnología o incluso el código y encontrar los errores más profundos? Como desarrollador en el bucle entrevista me imagino que hay tipos de control de calidad tradicionales también disponibles. Si es así, van a pedir las preguntas de la prueba típicos. Usted tiene que estar en la forma técnica son y cómo van a interactuar. Con esto en mente, probar algunos de estos tipo de preguntas:

1. preguntas de programación. Mira la hoja de vida. Lo que no saben C #? Javascript? Pedirles que codificar algo para ti. Cuanto más sepan, mejor los errores van a ser capaces de presentar.
2. preguntas de proceso. ¿Comprenden control de código fuente? ¿Han usado? ¿Reciben el concepto de una construcción? Están familiarizados con las pruebas unitarias?
3. preguntas de desarrollo de software. ¿Comprenden lo que es un DLL / montaje / JAR es? ¿Saben cómo funciona la memoria? ¿Comprenden la diferencia entre el modo kernel de usuario y una (o lo que sea apropiado para su dominio)?
preguntas
4. Tecnología. ¿Qué tan bien entienden su dominio? ¿Comprenden lo que motiva a la industria de la aplicación? ¿Saben lo widget clientes están buscando? ¿Alguna vez han usado un widget?
5. ¿Comprenden sus errores a un nivel profundo? Pregunte acerca de su insecto favorito. La cantidad de detalles que pueden informarle sobre lo que salió mal?
6. ¿Pueden ponerse de pie para usted? ¿Es este el tipo o tester que dará marcha atrás cuando dev empuja sobre ellos o van a luchar? Preguntarles sobre una vez que trataban de hacer algo y se encontraron con la oposición. ¿Cómo reaccionaron?