TDD en test de aceptacion de usuario
268 views
Skip to first unread message
Oscar
Jan 9, 2012, 10:45:08 AM1/9/12
to agile-spain
Hola a todos,
En mi empresa queremos introducir TDD para test de aceptacion de
usuario. Sabemos bien los beneficios que esto nos puede aportar, pero
tenemos dudas en el como implementarlo.
Os pongo primero en situacion dando algun dato relevante sobre la
forma en la que trabajamos.
Usamos Scrum desde hace un par de anios, aunque en algunas partes
digamos q tenemos nuestra propia interpretacion. En la parte que
queremos introducir ATDD, tenemos 2 aplicaciones,
una web + webservices + backend, y una aplicacion Swing. Para la
aplicacion web usamos Selenium + Rspec + Ruby y para la aplicacion
Swing usamos Marathon + JRuby.
Hace un anio refactorizamos toda la suite de selenium tests, de modo
que ahora tenemos una DSL interna, y todos los tests son escritos con
vocabulario de negocio. Por tanto queremos
empezar por esta parte. Tenemos dudas sobre como hacer el proceso, ya
que esto es nuevo para nosotros. Esto es lo que llevamos idea de
hacer:
- Sprint planning: Entre todo el equipo definir y estimar todas las
features a incluir, definiendo claramente los criterios de aceptacion,
al menos los de alto nivel (Con esto me refiero a que los
criterios de aceptacion de bajo nivel (que pasa si el campo en null,
vacio, etc) o mas tecnicos pueden realizarse despues, aunque siempre
antes de implementar la funcionalidad)
- QA escribe los tests de aceptacion en selenium basandose en la
criterios de aceptacion. En esta parte pueden intervenir tanto el
Product Owner para responder preguntas asi como los desarrolladores.
- Los desarrolladores implementan la funcionalidad, pudiendo modificar
los tests de aceptacion en colaboracion con el Product Owner y QA.
- Una vez que los test pasan, se hace una revision a los tests por
parte de QA
- A su vez se hacen revisiones de codigo (java) por parte de los
desarrolladores.
Algo que hemos pensado es tener dos build plans en nuestro servidor de
integracion continua (Bamboo). Uno para el Sprint en curso, y otro
para el resto de test. De modo que al acabar el Sprint todos los test
del Sprint en curso pasaran, y los podremos fusionar con el resto de
test. Para esto hemos pensado en tener los tests en diferentes
directorios, y asi poder tener diferentes build plans.
- Tambien estamos pensando en usar una herramienta como Cucumber o
Concordion para centralizar la definicion de historias de usuario de
forma que esten en el mismo lenguaje para todo el mundo y as uvez
accesible para
cualquiera. De otro modo tenemos: Requerimientos definidos en
Confluence por el product Owner, esto es traspasado al Product Backlog
en forma de historias de usuario (JIRA). A su vez QA usa TestLink que
es una herramienta
de gestion de test. Asi que actualmente tenemos 3 diferentes
herramientas para practicamente definir lo mismo, asi que este seria
un de los grandes beneficios de usar Cucumber o Concordion.
Y despues de el ladrillo que os he metido, espero que alguien haya
llegado hasta aqui sin cambiar de pagina. Ahi os lanzo una serie de
preguntas, y si alguna quiere contar su experiencia mejor que mejor.
Como implementais ATDD? Que cambios hariais al proceso que os he
contado? Que problemas veis?
Usais alguna de las herramientas mencionadas (Cucumber, Concordion,
Fitnesse)? Realmente aportan valor?
Gracias y saludos,
Oscar
En mi empresa queremos introducir TDD para test de aceptacion de
usuario. Sabemos bien los beneficios que esto nos puede aportar, pero
tenemos dudas en el como implementarlo.
Os pongo primero en situacion dando algun dato relevante sobre la
forma en la que trabajamos.
Usamos Scrum desde hace un par de anios, aunque en algunas partes
digamos q tenemos nuestra propia interpretacion. En la parte que
queremos introducir ATDD, tenemos 2 aplicaciones,
una web + webservices + backend, y una aplicacion Swing. Para la
aplicacion web usamos Selenium + Rspec + Ruby y para la aplicacion
Swing usamos Marathon + JRuby.
Hace un anio refactorizamos toda la suite de selenium tests, de modo
que ahora tenemos una DSL interna, y todos los tests son escritos con
vocabulario de negocio. Por tanto queremos
empezar por esta parte. Tenemos dudas sobre como hacer el proceso, ya
que esto es nuevo para nosotros. Esto es lo que llevamos idea de
hacer:
- Sprint planning: Entre todo el equipo definir y estimar todas las
features a incluir, definiendo claramente los criterios de aceptacion,
al menos los de alto nivel (Con esto me refiero a que los
criterios de aceptacion de bajo nivel (que pasa si el campo en null,
vacio, etc) o mas tecnicos pueden realizarse despues, aunque siempre
antes de implementar la funcionalidad)
- QA escribe los tests de aceptacion en selenium basandose en la
criterios de aceptacion. En esta parte pueden intervenir tanto el
Product Owner para responder preguntas asi como los desarrolladores.
- Los desarrolladores implementan la funcionalidad, pudiendo modificar
los tests de aceptacion en colaboracion con el Product Owner y QA.
- Una vez que los test pasan, se hace una revision a los tests por
parte de QA
- A su vez se hacen revisiones de codigo (java) por parte de los
desarrolladores.
Algo que hemos pensado es tener dos build plans en nuestro servidor de
integracion continua (Bamboo). Uno para el Sprint en curso, y otro
para el resto de test. De modo que al acabar el Sprint todos los test
del Sprint en curso pasaran, y los podremos fusionar con el resto de
test. Para esto hemos pensado en tener los tests en diferentes
directorios, y asi poder tener diferentes build plans.
- Tambien estamos pensando en usar una herramienta como Cucumber o
Concordion para centralizar la definicion de historias de usuario de
forma que esten en el mismo lenguaje para todo el mundo y as uvez
accesible para
cualquiera. De otro modo tenemos: Requerimientos definidos en
Confluence por el product Owner, esto es traspasado al Product Backlog
en forma de historias de usuario (JIRA). A su vez QA usa TestLink que
es una herramienta
de gestion de test. Asi que actualmente tenemos 3 diferentes
herramientas para practicamente definir lo mismo, asi que este seria
un de los grandes beneficios de usar Cucumber o Concordion.
Y despues de el ladrillo que os he metido, espero que alguien haya
llegado hasta aqui sin cambiar de pagina. Ahi os lanzo una serie de
preguntas, y si alguna quiere contar su experiencia mejor que mejor.
Como implementais ATDD? Que cambios hariais al proceso que os he
contado? Que problemas veis?
Usais alguna de las herramientas mencionadas (Cucumber, Concordion,
Fitnesse)? Realmente aportan valor?
Gracias y saludos,
Oscar
Daniel Ceillan
Jan 9, 2012, 1:15:55 PM1/9/12
to agile...@googlegroups.com
Primero creo que hay que diferenciar que, dentro de MVC, TDD es a nivel Modelo y ATDD es a nivel Vista y Controlador.
Mas avanzado que esto seria el testeo en capas, pero eso ya es materia de otro hilo.
No me parece muy bueno separar tanto a los de QA de los desarrolladores. Lo ideal seria que sean un mismo equipo.
Sobre como empezar te recomendaría que lo hagas de a poco. El system coverage no es indicador de calidad de testeo, ni de agilidad. Que tengas muchos tests no dice nada, aun mas vale mas la calidad que la cantidad.
¿conoces el concepto de proceso de aproximación? es lo que yo aplicaría en tu lugar.
Bueno no he visto que hablaras del Scrum Master, ¿como se relaciona con el equipo?
Yo he usado cucumber, pero tambien uso a veces una libreria que hice, la puedes chusmear aqui:
http://js-tdd.sourceforge.net/
para poder testear los javascripts. Esta verde, pero funciona!
Si claro que aportan valor, las buenas herramientas siempre cambian la experiencia de la gente.
Saludos!
--
Daniel Ceillan
I'm available to be Hired ! Please feel free to download my CV and share with others:
http://dcin.com.ar/daniel_ceillan.pdf
Carlos Ble
Jan 9, 2012, 4:12:22 PM1/9/12
to agile-spain
Hola!
Mi experiencia con tests selenium (webdriver) es que son muy fragiles.
No basaria los tests de aceptacion en tests que atacan la interfaz
grafica directamente de punta a punta. Los criterios de aceptación no
deben llevar información sobre "cómo" se usa la aplicación sino sobre
"qué" tiene que hacer, con lo cual no precisais entrar por la UI.
A nosotros nos parece fundamental escribir los criterios de aceptacion
en las historias de usuario, pero no nos compensa automatizarlos en
forma de tests. Los tests son para el equipo de desarrollo y para QA,
pero no los revisa el dueño de producto.
Ya nos contareis que tal la experiencia.
Mi experiencia con tests selenium (webdriver) es que son muy fragiles.
No basaria los tests de aceptacion en tests que atacan la interfaz
grafica directamente de punta a punta. Los criterios de aceptación no
deben llevar información sobre "cómo" se usa la aplicación sino sobre
"qué" tiene que hacer, con lo cual no precisais entrar por la UI.
A nosotros nos parece fundamental escribir los criterios de aceptacion
en las historias de usuario, pero no nos compensa automatizarlos en
forma de tests. Los tests son para el equipo de desarrollo y para QA,
pero no los revisa el dueño de producto.
Ya nos contareis que tal la experiencia.
Dougals Orlando Castro Barreto
Jan 10, 2012, 8:44:01 AM1/10/12
to agile...@googlegroups.com
En mi particular, enfoco las pruebas de aceptación en
documentos que apoya al usuario requirente del sistema para el
uso del mismo, garantizando la ejecución de los flujos esenciales con datos probables de su elección.
Antes del apoyo con esta documentación resulta favorable el enfrentamiento del sistema ante el usuario en interacción libre con el objetivo de medir la usabilidad del mismo.
Dougals Castro
سلام عليكم
+584166188295
+582122744784
Caracas - Venezuela
dougals...@hotmail.com
dca...@seniat.gob.ve
سلام عليكم
+584166188295
+582122744784
Caracas - Venezuela
dougals...@hotmail.com
dca...@seniat.gob.ve
Chat 
Google Talk: dougals.castro 
MSN: dougals.castro
Google Talk: dougals.castro MSN: dougals.castro--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Oscar
Jan 10, 2012, 10:01:48 AM1/10/12
to agile-spain
Hola Daniel,
Gracias por tu respuesta. Te respondo por partes.
"Primero creo que hay que diferenciar que, dentro de MVC, TDD es a
nivel
Modelo y ATDD es a nivel Vista y Controlador. "
Creo q hablamos de cosas distintas. Para empezar no tienes porque
tener tu arquitectura como MVC. En mi opinion, el testing se define en
varios niveles (unidad e integracion, funcional/aceptacion ususario,
performance..). Desde mi punto de vista, los test de aceptacion de
usuario o funcionales deben hacerse desde el punto de vista del
usuario, y son los q te aseguran q el sistema hace lo q se espera de
el. Por tanto no veo tests de aceptacion testeando el controlador, o
diferentes capas, para mi lo logico es tener test de unidad o
integracion en tus controladores, e incluso en tu javascript de la
vista. El test de aceptacion de usuario o funcional consiste en probar
el sistema end-to-end lo mas cerca posible a un sistema real, y
haciendo lo q el usuario (o cliente si es un servicio web o API...)
haria.
En cuanto a la estructura del equipo scrum, somos 9 personas, 3 QA, 6
desarrolladores (uno de los cuales es el scrum master) y un product
owner. Estamos en el limite de personas y a veces depende del producto
separamos el equipo en dos. QA esta integrado completamente en el
equipo aunque quizas no ha quedado claro.
Mi pregunta iba mas por saber el como implementar el proceso de ATDDy
tambien conocer experiencias de gente usando Cucumber, Concordion y
demas, y como anadir esas herramientas al proceso. Algo similar a lo
que puedes ver aqui. http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Como he dicho, usamos Selenium para automatizar los test de aceptacion
de usuario o funcionales, y para empezar con ATDD queremos simplemente
cambiar el orden y hacer los tests primero, para obtener los
beneficios que creemos q esto tiene. Una vez tengamos el proceso bien
definido, probablemente anadiremos Cucumber o Concordion o Fitnesse
por las razones q comento en el post.
Saludos,
Oscar
On Jan 9, 6:15 pm, Daniel Ceillan <codigodan...@gmail.com> wrote:
Gracias por tu respuesta. Te respondo por partes.
"Primero creo que hay que diferenciar que, dentro de MVC, TDD es a
nivel
Modelo y ATDD es a nivel Vista y Controlador. "
tener tu arquitectura como MVC. En mi opinion, el testing se define en
varios niveles (unidad e integracion, funcional/aceptacion ususario,
performance..). Desde mi punto de vista, los test de aceptacion de
usuario o funcionales deben hacerse desde el punto de vista del
usuario, y son los q te aseguran q el sistema hace lo q se espera de
el. Por tanto no veo tests de aceptacion testeando el controlador, o
diferentes capas, para mi lo logico es tener test de unidad o
integracion en tus controladores, e incluso en tu javascript de la
vista. El test de aceptacion de usuario o funcional consiste en probar
el sistema end-to-end lo mas cerca posible a un sistema real, y
haciendo lo q el usuario (o cliente si es un servicio web o API...)
haria.
En cuanto a la estructura del equipo scrum, somos 9 personas, 3 QA, 6
desarrolladores (uno de los cuales es el scrum master) y un product
owner. Estamos en el limite de personas y a veces depende del producto
separamos el equipo en dos. QA esta integrado completamente en el
equipo aunque quizas no ha quedado claro.
Mi pregunta iba mas por saber el como implementar el proceso de ATDDy
tambien conocer experiencias de gente usando Cucumber, Concordion y
demas, y como anadir esas herramientas al proceso. Algo similar a lo
que puedes ver aqui. http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Como he dicho, usamos Selenium para automatizar los test de aceptacion
de usuario o funcionales, y para empezar con ATDD queremos simplemente
cambiar el orden y hacer los tests primero, para obtener los
beneficios que creemos q esto tiene. Una vez tengamos el proceso bien
definido, probablemente anadiremos Cucumber o Concordion o Fitnesse
por las razones q comento en el post.
Saludos,
Oscar
On Jan 9, 6:15 pm, Daniel Ceillan <codigodan...@gmail.com> wrote:
Oscar
Jan 10, 2012, 10:20:43 AM1/10/12
to agile-spain
Hola Carlos,
Gracias por tu respuesta.
Estoy de acuerdo en q los tests con Selenium son muy fragiles, pero
hay formas de conseguir evitar esto. Los veo muy muy fragiles cuando
usas selenium grabando los tests con el plugin del nvegador, ademas de
q es muy limitado. Tambien los veo fragiles cuando usas Selenium
Remote Control, y te creas tus propios scripts "a pelo" llamando a los
metodos de la selenium API en el lenguaje correspondiente (nosotros
usamos ruby y rspec). Deja de ser tan fragil cuando implementas tus
tests siguiendo el Page Object Pattern o defines "activities" (http://
gojko.net/2009/10/06/putting-selenium-in-the-right-place/), o cuando
extraes toda la complejidad del lenguaje, selenium, XPATH, ids, etc
fuera de los tests y lo pones todo debajo de una API o DSL interna q
es lo q nosotros tuvimos que hacer. Quiero decir, q si, escribir
Selenium tests sin cuidado se puede convertir en algo muy fragil y
dificil de mantener muy facilmente, pero usado adecuadamente no tiene
por que.
Cuando dices "Los criterios de aceptación no
entiendo muy bien lo que quieres decir. Como puedes escribir un tests
de aceptacion de usuario de un sistema q tiene una interfaz web, sin
testear desde la UI?
En cuanto a lo que dices de que no os compensa automatizar los test de
aceptacion no estoy de acuerdo. En mi experiencia, nada te da mas
seguridad que tener una suite de test de aceptacion automatizada. Los
test de unidad y de integracion te garantizan la calidad interna del
producto, pero tener test de aceptacion automatizados te permite saber
si tu sistema se comporta como deberia en cualquier momento. Nosotros
(QA antes de usar Scrum) antes teniamos que pasar todos los test
manualmente, de modo que eran 5 dias para terminarlo. Ahora tenemos
automatizado el 80% de esos tests, de modo que podemos tener un fix
pack release por ejemplo muchisimo mas rapido y seguro contra posibles
fallos manuales.
Por supuesto, tratare de contar en otro post como va el proceso en un
par de meses.
Gracias y saludos,
Oscar
Gracias por tu respuesta.
Estoy de acuerdo en q los tests con Selenium son muy fragiles, pero
hay formas de conseguir evitar esto. Los veo muy muy fragiles cuando
usas selenium grabando los tests con el plugin del nvegador, ademas de
q es muy limitado. Tambien los veo fragiles cuando usas Selenium
Remote Control, y te creas tus propios scripts "a pelo" llamando a los
metodos de la selenium API en el lenguaje correspondiente (nosotros
usamos ruby y rspec). Deja de ser tan fragil cuando implementas tus
tests siguiendo el Page Object Pattern o defines "activities" (http://
gojko.net/2009/10/06/putting-selenium-in-the-right-place/), o cuando
extraes toda la complejidad del lenguaje, selenium, XPATH, ids, etc
fuera de los tests y lo pones todo debajo de una API o DSL interna q
es lo q nosotros tuvimos que hacer. Quiero decir, q si, escribir
Selenium tests sin cuidado se puede convertir en algo muy fragil y
dificil de mantener muy facilmente, pero usado adecuadamente no tiene
por que.
Cuando dices "Los criterios de aceptación no
deben llevar información sobre cómo se usa la aplicación sino sobre
qué tiene que hacer, con lo cual no precisais entrar por la UI. " No
entiendo muy bien lo que quieres decir. Como puedes escribir un tests
de aceptacion de usuario de un sistema q tiene una interfaz web, sin
testear desde la UI?
En cuanto a lo que dices de que no os compensa automatizar los test de
aceptacion no estoy de acuerdo. En mi experiencia, nada te da mas
seguridad que tener una suite de test de aceptacion automatizada. Los
test de unidad y de integracion te garantizan la calidad interna del
producto, pero tener test de aceptacion automatizados te permite saber
si tu sistema se comporta como deberia en cualquier momento. Nosotros
(QA antes de usar Scrum) antes teniamos que pasar todos los test
manualmente, de modo que eran 5 dias para terminarlo. Ahora tenemos
automatizado el 80% de esos tests, de modo que podemos tener un fix
pack release por ejemplo muchisimo mas rapido y seguro contra posibles
fallos manuales.
Por supuesto, tratare de contar en otro post como va el proceso en un
par de meses.
Gracias y saludos,
Oscar
Néstor Salceda Alonso
Jan 10, 2012, 10:48:55 AM1/10/12
to agile...@googlegroups.com
Hola Óscar,
Te respondo justito debajo del párrafo en el que creo que puedo aportar
algo.
On Tue, 2012-01-10 at 07:20 -0800, Oscar wrote:
> Hola Carlos,
>
> Gracias por tu respuesta.
>
> Estoy de acuerdo en q los tests con Selenium son muy fragiles, pero
> hay formas de conseguir evitar esto. Los veo muy muy fragiles cuando
> usas selenium grabando los tests con el plugin del nvegador, ademas de
> q es muy limitado. Tambien los veo fragiles cuando usas Selenium
> Remote Control, y te creas tus propios scripts "a pelo" llamando a los
> metodos de la selenium API en el lenguaje correspondiente (nosotros
> usamos ruby y rspec). Deja de ser tan fragil cuando implementas tus
> tests siguiendo el Page Object Pattern o defines "activities" (http://
> gojko.net/2009/10/06/putting-selenium-in-the-right-place/), o cuando
> extraes toda la complejidad del lenguaje, selenium, XPATH, ids, etc
> fuera de los tests y lo pones todo debajo de una API o DSL interna q
> es lo q nosotros tuvimos que hacer. Quiero decir, q si, escribir
> Selenium tests sin cuidado se puede convertir en algo muy fragil y
> dificil de mantener muy facilmente, pero usado adecuadamente no tiene
> por que.
>
> Cuando dices "Los criterios de aceptación no
> deben llevar información sobre cómo se usa la aplicación sino sobre
> qué tiene que hacer, con lo cual no precisais entrar por la UI. " No
> entiendo muy bien lo que quieres decir. Como puedes escribir un tests
> de aceptacion de usuario de un sistema q tiene una interfaz web, sin
> testear desde la UI?
Yo creo que lo que quiere decir Carlos es que pongas la atención en la
acción y no en el cómo se lleva a cabo esa acción. Con un ejemplo lo
verás más claro :)
Vamos a suponer el hacer login en una aplicación, para ello:
* QUÉ: Es la acción a realizar, que es entrar al sistema
* CÓMO: Es el cómo se lleva a cabo esa acción, que será rellenar el
nombre de usuario, la contraseña y enviar el formulario.
La idea clave creo que está en el lenguaje, cuanto más cercano al dueño
de producto (o sucedáneo) más fácil será poder escribirlos y
mantenerlos, para ello trata de referirte a este paso como la
abstracción "entrar al sistema" y si utilizas una herramienta tipo
Cucumber (supongo que otras te permitirán esto también) puedes
reutilizar los pasos e ir variando la implementación si lo necesitas,
pero la abstracción prevalece.
Finalmente supongo que lo conocerás, pero puedes encontrar estas cosas
en el "Specification by Example" de Gojko Adzic.
Espero haber ayudado.
Néstor
Oscar
Jan 10, 2012, 11:57:22 AM1/10/12
to agile-spain
Hola Nestor,
Gracias por el aporte.
Si es asi, creo q estamos hablando de lo mismo, o al menos muy
parecido.
Para mi entonces, el "que" se trata de la historia de usuario, q
normalmente (al menos nosotros) se expresa con la plantilla: As a XXX
I want to XXX so that XXX
Pero en mi opinion, para definir la historia de usuario como completa
ha de tener adjuntos los criterios de aceptacion, que es lo que le va
a dar la definicion de hecha o terminada. Y es ahi donde los criterios
de aceptacion o condiciones de satisfaccion se traducen en tests de
aceptacion. Creo q con cucumber estos se llama scenarios, aunque no
estoy seguro porque no conozco bien cucumber.
En el ejemplo del login que pones, la historia de usuario representa
el "que", pero debe ser refinada para obtener los escenarios q
posteriormente se traducen a test de aceptacion, y ahi si que te
tienes que referir a la lU. Puedes ver un ejemplo muy bueno de lo que
digo en este link. http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Total, como te digo creo q hablabamos de lo mismo. Gracias por la
aclaracion :)
Conozco el libro que mencionas de oidas, si que he consultado el blog
de Gojko Adzic, me parece un recurso muy interesante.
Gracias y saludos,
Oscar
On Jan 10, 3:48 pm, Néstor Salceda Alonso <nestor.salc...@gmail.com>
wrote:
Gracias por el aporte.
Si es asi, creo q estamos hablando de lo mismo, o al menos muy
parecido.
Para mi entonces, el "que" se trata de la historia de usuario, q
normalmente (al menos nosotros) se expresa con la plantilla: As a XXX
I want to XXX so that XXX
Pero en mi opinion, para definir la historia de usuario como completa
ha de tener adjuntos los criterios de aceptacion, que es lo que le va
a dar la definicion de hecha o terminada. Y es ahi donde los criterios
de aceptacion o condiciones de satisfaccion se traducen en tests de
aceptacion. Creo q con cucumber estos se llama scenarios, aunque no
estoy seguro porque no conozco bien cucumber.
En el ejemplo del login que pones, la historia de usuario representa
el "que", pero debe ser refinada para obtener los escenarios q
posteriormente se traducen a test de aceptacion, y ahi si que te
tienes que referir a la lU. Puedes ver un ejemplo muy bueno de lo que
digo en este link. http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Total, como te digo creo q hablabamos de lo mismo. Gracias por la
aclaracion :)
Conozco el libro que mencionas de oidas, si que he consultado el blog
de Gojko Adzic, me parece un recurso muy interesante.
Gracias y saludos,
Oscar
On Jan 10, 3:48 pm, Néstor Salceda Alonso <nestor.salc...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages