Cómo aprender/enseñar pepinillo para pepino

StackOverflow https://stackoverflow.com/questions/1704641

Pregunta

Me gustaría permitir que los analistas de negocios puedan escribir todas sus especificaciones para características, escenarios y pasos que sean compatibles con Cucumber usando Gherkin.

Leí parte de la información básica en el sitio de github para Cucumber y hice una búsqueda rápida en Google, pero quería saber si había recursos recomendados para que personas sin conocimientos técnicos pudieran escribir BDD completo usando Gherkin (supongo que es el idioma preferido para crear las pruebas de Cucumber).

Gracias.

¿Fue útil?

Solución

Lo que hice con los analistas de negocios de nuestra empresa fue enseñarles la estructura dándoles las palabras clave: Dado, Cuando, Entonces, Y para escenarios y Con el fin de, Como un y Yo quiero para Funciones.

Luego les di un ejemplo sencillo y les dije que escribieran sus propias características como pensaban que debían escribirse.Sorprendentemente, la estructura se explica por sí misma y las características que escribieron se convirtieron en un gran comienzo.
El único gran problema era que contenían demasiada lógica en cada paso del escenario.Lo resolví al preguntar iterativamente "¿Por qué?" que en la mayoría de los casos reveló la funcionalidad central que buscaban y reescribimos los escenarios de acuerdo.

Al darles las pautas y dejarles escribir ellos mismos los artículos, se ensuciaron las manos y se vieron obligados a pensar en lo que escribieron.Hoy tienen una comprensión mucho mejor y el "¿Por qué?" Las iteraciones ya no son tan comunes.

Por supuesto, es necesario que los analistas de negocios y los desarrolladores trabajen en estrecha colaboración y las características que escriban los analistas sólo deberían servir como un comienzo.Recuerde que las funciones de Cucumber son solo un lenguaje común entre analistas y desarrolladores.Todavía necesitan sentarse juntos con frecuencia para poder hablar entre ellos :)

Otros consejos

http://cukes.info es un gran recurso para enseñar a la gente cómo escribirlas. Ben Mabey también hizo una gran presentación en Pepino al oeste de la montaña rubí Conferencia de 2009.

Tras haber trabajado en un proyecto ágil usando el pepino por primera vez creo que la mejor manera de aprender pepino y pepinillo es a ensuciarse las manos.

Puede que me equivoque, pero me da la impresión de su pregunta se desean formar a sus BA escribir pepinillo; entonces van a escribir un montón de características y entregarlos a los desarrolladores.

Esto definitivamente no es el camino a seguir. Es mucho mejor tener desarrolladores y usuarios (si es posible) que trabajan juntos para escribir sus escenarios y construir sobre la marcha de BA. A continuación, todos juntos aprender lo que funciona y lo que no.

Intentamos tener una licenciatura escribir funciones enteras y entregarlos. Nosotros (los desarrolladores) Terminamos tener que hacer grandes reescrituras porque la implementación terminó diferente a la prevista originalmente por el BA. También tuvimos que cambiar la sintaxis de los pasos y no buscar y reemplazar a través de todo el archivo.

Haga un escenario a la vez, conseguir que funcione a continuación, pasar a la siguiente. Un enfoque iterativo reduce el esfuerzo desperdiciado y se asegura de que todos entendemos cómo desea que la aplicación se comporte.

En cuanto a la forma de escribir los pasos que lo mejor es empezar con los que vienen con pepino y copiar y adaptar a medida que trabaja en su proyecto para adaptarse a su aplicación particular. No hay bien o mal, es lo que funciona para usted. La documentación sobre los sitios de pepino en general es bueno y será un recurso valioso a medida que aprende más.

Estamos enseñando pepinillo (por SpecFlow) de una manera similar, la forma MRD ha descrito.

Creo que es muy importante, sin embargo, que el público está familiarizado con la intención principal de "Especificación con el ejemplo", análisis de requisitos ágil y BDD, por lo que normalmente empezar a discutir el fondo primero. También mostramos un escenario pepinillo muestra y explica los conceptos básicos (como el Dada / Cuando / Then / Pero y tablas).

que no se toma una historia simple ejemplo (que es muy familiar para todo el mundo), así como "añadir artículos al carrito" (con un poco de orientación, por supuesto) y dejar a formular los criterios de aceptación en pequeños grupos.

Después de que los espectáculos cada equipo / explica sus soluciones y se discuten las buenas y malas prácticas que estaban presentes. Después del segundo equipo, se puede ver casi la totalidad de las prácticas más importantes (bueno o malo) que aparecen.

También escribo en la solución concluido, y muestro aquí formas alternativas de describir los escenarios (fondo, contorno escenario, etc.). Si hay suficiente tiempo, también a mostrar cómo automatizar y poner en práctica la funcionalidad imaginado basado en eso. Esto también ayuda a entender algunas reglas importantes a seguir, que hace que la automatización mucho más fácil.

Aunque, nunca sé qué va a pasar upfront, por lo general este ejercicio es la mejor parte de nuestra formación BDD.

El libro RSpec tiene un par de capítulos en los mismos que son relevantes para los analistas de negocios:
http://pragprog.com/book/achbd/the-rspec-book

Creo que la mejor manera de aprender es empezar a escribir.El pepinillo y el pepino son fáciles de aprender pero difíciles de dominar, por lo que es importante llegar a ejemplos prácticos lo antes posible.

Si bien es importante comenzar escribiendo sus primeros escenarios, también necesita algunos recursos para establecer buenos hábitos y comprender las prácticas clave.Escribí un libro que podría ayudar. "Escribir excelentes especificaciones" Espero que sea una buena manera de aprender pepinillo y pepino.Cubre patrones y antipatrones, así como técnicas clave para escribir grandes escenarios.:) Si tienes alguna pregunta, siempre puedes contactarme Gorjeo.

Si está interesado en comprar "Escribir excelentes especificaciones", puede ahorrar un 39% con el código de promoción 39nicieja2 :)

Otros grandes recursos:

  • “Especificación con ejemplo” de Gojko Adzic si está interesado en los procesos de desarrollo de software y las prácticas de ingeniería de alto nivel.
  • "BDD en acción" de John Smart si no le importa leer el código de prueba en Java.Es una vista integral de extremo a extremo sobre la definición y prueba de requisitos de software.
  • “Desarrollo impulsado por el comportamiento” de Liz Keogh si las pruebas automatizadas no le suenan, pero desea comprender cómo las especificaciones con ejemplos afectan sus procesos de análisis de negocios.
  • “El libro del pepino:Desarrollo impulsado por el comportamiento para probadores y desarrolladores” por Matt Wynne y Aslak Hellesøy
  • “El libro RSpec:Desarrollo impulsado por el comportamiento con RSpec, Cucumber y Friends” por David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, ​​Dan North
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top