Se trata de e-Valid de una compañia llamada Software Research.

A grandes rasgos e-Valid es una solución de automatización de pruebas y pruebas de performance para apliaciones Web.(si… Solo web )

El manejo de la herramienta es sencillo y no depende de un gran conocimiento técnico, viene con un tutorial incluido con la aplicación, esta te permite conocer el uso básico de la aplicación y familizarizarte con ella.

La primer característica de ser “Record and Play” con lo que la primer prueba de uso sencillo es superada.

En cuanto a su interfaz se compone de 4 componentes por separado: 4 ventanas, lo cual puede ser un poco molesto si eres de los que gustan de tener pocas ventanas abiertas(Mi caso). Esto también hace un poco mas complicado su uso pero nada que te pueda detener.

Cuenta con checkpoints y puntos de sincronización, features que en mi opinión son escenciales para cualquier aplicación de automatización. El primer problema que encontré es que no existe un estado o checkpoint que sea del tipo WebPageLoaded por lo que se deben de anexar varios puntos de sincronización en cada pagina si se requiere que la pagina cargue por completo o bien identificar cual es el último elemento que se cargue. Lo cual puede presentar problemas cuando usas varios frames. También cuenta con parametrización de variables con lo que nuestras ejecuciones pueden ser dinámicas, cosa que también es necesario para una buena herramienta de automatización.

Otro feature importante es la grabación analógica, la cual permite a la aplicación grabar los clicks de mouse y keystrokes en cualquier momento que lo requiramos. Esto es un buen elemento cuando contamos con elementos flash o active X, los cuales pueden llegar a ser complicados o imposibles de manejar con otro tipos de herramientas (WatiN :’(). Aunque este es un buen feature sugiero no depender de este, ya que al ser solo una macro, esta puede fallar si se hacen algunos cambios en la interfaz.

Otro problema que se me presentó fue insertar datos en campos validados o “influenciados” por algun tipo de Javascript, por ejemplo en una aplicación tenia un campo de “precio” el cual se formatea autómaticamente con decimales mientras lo vas capturando, al momento de grabar eValid no fue capaz de detectar la modificación de este control por lo que al reproducir la prueba esta se quedaba trabada. Entonces es para este tipo de situaciones que ocupamos el feature de grabación analógica, de tal manera que al enfocarse en el campo de “precio” la aplicación simule las keystrokes.

Dentro de los elementos de eValid también tenemos un sistema de comparación de imagenes, la cual nos resalta las diferencias entre dos imagenes, esto nos sirve cuando queremos verificar que el sistema esta cargando las mismas imagenes, cabe notar que no son comparaciónes entre las imagenes de lo grabado y lo reproducido, no del tipo print screen o una imagen de toda la página. Este sistema de comparación es entre archivos de imagenes, es decir que podemos comparar las diferencias de dos archivos. De esta forma si queremos ver que la imagen de bienvenida es la mista debemos grabar analógicamete el “Save image as…”, parametrizar le nombre del archivo y depués manualmente correr la comparación de las dos imagenes. A mi gusto no es un super feature pero es algo diferente que a alguién le puede ser de utilidad.

También contamos con un aplicación de administración de Scripts que sirve de repositorio de los mismos asi como un organizador que permite tener suites de scripts de pruebas, por lo que podemos ejecutar cierto conjunto de pruebas dependiendo de lo que necesitemos. Este manager cuenta también con la capacidad de recopilar los resultados, errores y alertas de las pruebas que ejecuta y esto lo inserta en diferentes reportes. También tiene la característica de poder ejecutarse desde linea de comandos.

Otra característica muy importante es aparte de pruebas funcionales el sistema puede ejecutar pruebas de performance, usando los mismos scripts de pruebas funcionales, lo cual es una ventaja de la que muchas otras herramientas de automatización carecen, este feature los presentan grandes herramientas de Performance como QALoad(compuware) o Load Runner(HP) con la diferencia que esas opciones son solo de soporte y no son tan recomendadas de implementar, en cambio para eValid tenemos un cambio tranaprente y nativo entre las pruebas automatizadas y de performance una característica muy importante. Pero como todo también tenemos un punto en contra, eValid al ser una aplicación de pruebas que se ejecuta directamente sobre el front end las sesiones que se pueden crear son pocas a comparación de una aplicación de performance, por poner un ejemplo lo que hace eValid es abrir N ventanas de Internet Explorer, una ventana por cada usuario. Eso hace que un equipo de 2 GB en RAM y procesador Centrino Duo a 2Ghz pueda ganerar un máximo recomendable de unos 200 usuarios. De cualquier forma se puede trabajar en paralelo poninedo varias maquinas a estresar el servidor al mismo tiempo, pero eValid no tiene una opción para esto.

Otro gran punto a favor fue que me encontre con un gran soporte por parte del proovedor, quien en 24 horas máximo me respondian mis dudas y de una manera atenta y directa, poniendo sus respuesta a un nivel que un usuario pudiera entender e incluso ofreciendo a contactarme vía telefónica en caso de no quedar clara la duda (igual estaban muy interesados en vender su herramienta :p).

En resumén califico de “buena” mi experiencia con eValid, a pesar de presentar una interfaz muy sencilla nos da la funcionalidad suficiente para tener un buen framework de automatización y por lo tanto también buenos resultados, puede ser una muy buena entrada para pruebas de performance. En cuanto a la facilidad de programación la herramienta se queda un poco corta, ya que el script que nos genera es muy simple, aunque me comentaron que en la versión 8 (La cual ya esta liberada en su sitio) mejorarian considerablente el scripting y la edición del mismo.

Saludos y gracias por leer.

Chale… Tengo que buscarme un slogan…

RSE

Hay testers (de los que tanto se quejan los devs con malas experiencias) que se esfuerzan desequilibradamente en reportar errores de diseño. Para ellos, la compatibilidad entre browsers debe representar una ardua tarea, pues estarían revisando lo mismo en cada navegador listado desde la fase de arquitectura.

Otra clase de testers,  para los que la funcionalidad las pruebas normales representan arduo trabajo cuando los tiempos de espera son largos y la cantidad de pasos excesiva, existe la automatización.

Pero que pasa cuando la funcionalidad está muy ligada a tecnologías client-side? Y lo peor ocurre: despues de probar infinidad de funcionalidades y sortear con maromas las contorsiones de algunas interfaces, nos damos cuenta que el comportamiento es distinto en cada uno de los browsers ‘soportados’.

En el caso concreto de Internet Explorer, antes, los STEs debían usar un equipo (físico) para cada versión del navegador (no es posible tener varias versiones instaladas). Los mas avispados usaban máquinas virtuales. Incluso había ‘trucos’ para lograr las versiones anteriores. Pero todo ésto acaba con MutlipleIE, creado por la gente de TredoSoft, que lograron poner en un mismo ‘instalador’ 5 exes, algunas librerías y otras llaves de registro para que en unos segundos tengamos en el mismo OS, IE 3.0, 4.01, 5.01, el famoso 5.5 y 6.0 (el 7 corre por nuestra cuenta).

Solo esperamos incluyan en el paquete al IE7 cuando lancen el, por fín antiácido, IE8. Pero ésa será otra historia.

Todos se instalarán en una carpeta distinta, compartirán la configuración del navegador realmente instalado. Desde las versiones antiguas no se podrá modificar la configuración.  No he tenido la oportunidad, pero sería interesante probar como se comporta cada versión ejecutando un mismo script automatizado, se los dejo de tarea.

And remember to rock your world!

luistoledo

Bueno en este momento yo estoy en camino a la bella ciudad de Oaxaca, después de aventarme dos super películas en el camión recordé que a mi lap top le queda toda la pila y el blog para variar está un poco descuidado, una diculpa por eso, pero aún no agarró el ritmo.

En estos dias de harto trabajo y muy entretenido, he tenido que ver una gran variedad de herramientas y suites de testing. Y lo que se me ha hecho curioso es que cada uno de los diferentes proovedores dicen tener el mejor producto.

La verdad es que de aquellos productos que he revisado (de los cuales espero poco a poco ir sacando reviews) no he encontrado ninguno que en mi opinión sea la mejor solución para el área de pruebas.

Esto es una realidad, lo que opino de todas las herramientas es que merecen su oportunidad y cada una de ella puede aportar mucho a un proceso de pruebas pero en mi humilde opinión siempre la elección de la herramienta dependerá del cliente, sistema, infraestructura, capacidades técnicas y otras circusntacias que nos limitan.

Por esto quiero compartir con ustedes una receta que espero les ayude su elección de la mejor herramienta para sus necesidades (aunque lo mejor seria mandarnos un correo y buscar nuestro apoyo profesional jejeje , pero son libres de hacerlo por su cuenta).

1.- Opinión Imparcial: En primer lugar debemos de llevar a cabo la elección con un punto de vista objetivo, sin tomar en cuenta preferencias personales si no teniendo en mente que no seremos los únicos usuarios de la herramienta o suite, de tal forma que tenemos que ponernos en los zapatos de los usuarios y elegir lo que seria mejor para ellos.

2.- Costo de la herramienta: Esto puede ser algo obvio pero vale la pena mencionarlo, debemos de considerar el costo de la herramienta tanto la inversión inicial como su mantennimiento, quizá la herramienta requiera de un costo anual, o de muchos complementos lo cual puede llevar a una mayor inversión después, también hay que considerar que recursos con un buen conocimiento de la herramienta pueden llegar a ser muy caros. Desde luego que también tenemos que ver la relación costo/beneficio, de esta forma una fuerte inversión puede ser de lo mejor.

3.- Recursos Técnicos: Se tiene que evaluar también el nivel técnico requerido para la operación de la herramienta, y esto conlleva a evaluar el nivel técnico que se tiene en el personal también, de esta forma se debe de seleccionar una herramienta que pueda ser explotada correctamente, es decir no puedes poner una herramienta de automatización tipo WatiN a un grupo de usuarios que en su vida han programado, o poner una aplicación record and play sin opción de “scripting” a programadores de hueso colorado. En el primer ejemplo la herramienta tiene gran probabilidad de nunca ser utilizada y en la segunda posiblemente los programadores teminen adquiriendo (o haciendo… Vease la entrevista con Jeroen) otra herramienta.

4.- Necesidad de soporte: Otro punto importante a evaluar es ver si tu empresa o cliente requiere del soporte que ofrece una herramienta, muchas veces por políticas o forma de trabajo de una empresa requiren de tener un contacto directo con los proovedores en soporte técnico de las herramientas y muchas otras prefieren tener a un experto en su personal que se encargue de todo esto. De igual forma existen herramientas que te ofrecen un gran soporte y otras que por su naturaleza de licenciamiento no pueden darse esos lujos.

5.- Integración con otras herramientas: Este punto es básico cuando ya contamos con ciertas herramientas o aplicaciones. Si tenemos un producto que nos ofrece una integración con lo que ya contamos puedo decir que se le pueden dar muchos puntos, ya que implica una mejora extra(Un plus) a todo nuestro proceso de pruebas o desarrollo.

6.- Complejidad del proyecto de automatización: Para nuestra elección también debemos de tomar en cuenta la aplicación y proyecto motivo de la automatización, al final de cuentas esta es la que nos impone las necesidades de la automatización. Entre las necesidades que hay que tomar en cuenta estan plataforma de la aplicación, reconocimiento de controles de la aplicación, complejidad de los módulos o flujos, entregables requeridos. Un ejemplo puede ser la necesidad de automatizar un proceso de alta extremadamente complejo que puede variar entre 10 y 100 campos… Esto con una aplicación tipo record and play es sumamente díficil, ya que los elementos para programar(si los tiene) son muy pobres con lo que hacer capaz al script de manejar todas las variantes es muy díficil, lo que nos pondrá en la necesidad de crear N cantidad de Scripts para N cantidad de variantes, los que nos puede volver locos al administrarlos. En cambio una herramienta de automatización que se puede combinar con un ambiente de desarrollo nos puede traer el beneficio de que con un solo script se puedan contemplar todas las variantes. Pero de igual forma si nuestas pruebas son muy simples no vale la pena crear un super script para automatizar el alta en un catálogo que cuenta solo de 5 campos.

7.- Afinidad a la herramienta: Como último punto y muy importante es considerar que a pesar de todo debemos de trabajar con la herramienta con la que estemos mas cómodos, es un hecho que existe una herramienta que nos puede ajustar perfectamente a nuestra necesidad pero muchas veces simplemente no hay esa química entre la aplicación y el equipo de automatización (Ojo hablo del equipo, no solo un individuo, no me estoy contradiciendo con el punto 1). Cuando esto sucede es bueno mirar al segundo lugar y posiblemente nos demos cuenta que aunque presenta algunos inconvenientes existe un buen trabajo con le herramienta, con lo que el equipo estará agusto, cosa que considero vital para que se saque adelante cualquier proyecto.

Pues bueno ya hace dos semanas que empecé esta entrada y hoy me senté a terminar los puntos 6 y 7, y el cierra de la entrada. Espero que lo que les puse en esta entrada les sea útil para elegir.

Por el momento los dejo y pronto espero postear nuevamente, ultimamente ha habido mucho mas trabajo lo cual es muy bueno por que ya hay mas ideas pal blog :p…

Sean Felices!!!

RSE

Versión en español aquí.

RSE: Aló
Jeroen: Hi there
RSE: how r u doing?
Jeroen: I’m fine and you?
RSE: doing good thx, are you ready?
Jeroen: Yep, lets start the party!
RSE: cool, ok, my friend couldnt make it, he is with a client right now
Jeroen: ok
RSE: so he left me in charge of everything
Jeroen: that is a great responsibility
RSE: ha ha ha, Ok, Well i guess for start is good to ask, who is Jeroen Van Menen?, i tried to check your web page but no spanish nor english , i also tried to google you but u only apear at forums and blog comments
Jeroen: Well, I’m a guy from the Netherlands living near Amsterdam, you can find my on my website www.vanmenen.nl, I’m 36 at the moment having 2 kids and a lovely women!
RSE: nice, you sound you are having a nice life, glad to hear it
Jeroen: it is
RSE: i tried to check your website but no spanish or english
Jeroen: Yep, all dutch. I have not thought that info would have any interest for people outside the netherlands, maybe I should add some bio somewhere in english
RSE: yep thats a good idea , and what is you proffesional career? or what are you into at work?
Jeroen: I am a senior developer working for a company called LinkiT. We are currently working on an agile project for ING Bank in the Netherlands, i joined LinkiT in july of this year and I’m very happy I made the move, they are one of the small number off firms who are practising (real) scrum/agile in the Netherlands, i was always under the impression that I would have to go to the US to do something agile projects, but now I can stay in the Netherlands, which is fine by me.:)
RSE: cool, Thanks for the presentation , now, we get to know you from WATIN, how did the idea of WATIN born?
Jeroen: It my previous company we were starting up test automation to help the tester do a regression test faster on a big enterprise application, it was completely build in ASP.Net so we needed a way to automate this. We first used a commercial tool to set this up. In the beginning this worked fine but when we got really into it we wanted more and the tool hold us down, it had also many bugs causing the nightly builds to fail often. So that was not the way to go. I looked around on the net to see what was there, since the script language in the tool was the main problem I wanted a tool that offered the freedom I was used to as a developer, so i searched and found many options but non that offered automation using .Net, i really liked the Watir API but since using Ruby as a language in that company wasn’t an option (management…) I started porting Watir over to .Net… And that is how WatiN started.
RSE: Ooh, can u tell me wich commercial tool were you using?
Jeroen: Now I have to think hard, let me look it up, Yes now I know, Seapine has a tool called QA Wizard, they just bought that to compliment there product suite
RSE: Oh i have tried it.
Jeroen: but it wasn’t at the same quality as TestTrack Pro or Surround SCM, which we where also using. Since then the product has evolved but I never have taken a look at it (cause WatiN was doing the job very well )… What was your opinion about it?
RSE: well like i told u, i tried it and in my point of view the tool stills need some improvements, and WATIN can give better results, the difference is that for WATIN we need a greater Technical aproach than QA Wizard, so that is one of the advantage of the commercial tool.
Jeroen: I agree, that is a big difference and it also explains why WatiN is more used by developers then by people from a QA department with a non or less technical background.
RSE: yep, well thats something we want to change
Jeroen: WatiN Test Record tryed to fill that void and did a great job I think
RSE: yep indeed, we have tried it and is one of the complementary tools to build a automation test project, i guess the IE Dev Toolbar is our other tool
Jeroen: IE Dev toolbar is NEEDED!
RSE: lol, yep, but any way has some issues, for example it never gives you the “Value” tag, so u have to look for it at the code , so, talking about QA Department, What do u think or whats your point of view about The Tester and The Testing Practice?
Jeroen: Could you explain some more?
RSE: mm ok, what is a tester for you? what does he have to do? is he necessary to the Software engineering project?, would you like to them to have some other skills?
Jeroen: I think testers are very much needed, it is amazing how they can contribute to the quality of a product, even in agile projects where every one writes tests for their code, the still show value, doing the tests manually or (partially) automated, they see things developers have a blind spot for. So yes they should be on the team and I like them to take part during all fases of the development cycle, mostly they are the ones that know the system best from the functional perspective, and that way they can add value to the functional design and spot bugs urly during development
RSE: Ok you sound very like we are trying to talk about in our blog, because at least here in mexico we deal with a lot of people that sees the tester as a little annoying bug, or an unneccesarry resource… Is you vision or point of view common at netherlands?
Jeroen: Hmmm, for what I have seen, management seems to think anybody can test…
RSE: Good point, here we have that problem also
Jeroen: … But I have met some great testers here in the Netherlands and they really do something else then just checking if the button click goes to the next screen , So I think tester are under rated but they should always stay in the role of an advisor and not become (too) religious about it. That it probably what is part of seeing as annoying people.
RSE: Wise words , havent you being tempted to be a tester?
Jeroen: thanks, i have been for half a year but I liked writting code more , I got this role because of tester shortage and me being the guy who did the test automation for the app was a logical choice to help to fill this void (= anybody can be a tester ??)
RSE: so you were once a fellow tester, lol
Jeroen: yep!
RSE: In my opinion i dont think anybody can be a tester (you could be a great one, but like the dark side better ), and now, talking about what you like, what are your hobbies or your passions?
Jeroen: Hmm, WatiN support, WatiN development, WatiN in general, but for real. My kids (2, 5 years and 3 months) are much fun to be with, my digital camera is one thing I use a lot, and I make wine
RSE: i didnt get the “WatiN support, WatiN development, WatiN in general but for real”, lol i could see that on your website, you make wine?
Jeroen: WatiN *.* is my passion and a big hobby. Since it is open source I do the development mainly during the evening and nights. So that basically rules out many other things
RSE: oooh i get it now
Jeroen: But that sounds like I’m always behind my laptop, but I do have a private live as well, don’t worry.
RSE: lol, yep you sound like you like to stay with your kids and wife better than in front your laptop, mm how do you make wine?, im curious about it
Jeroen: Here are the (very)basic steps: You take a lot of grapes (even for just 5 liter) and extract the juise from them, Then you add some special wine leaven(?) and put everything in a big glass bottle. Then it will start to bubble and the sugar from the juice (or the added sugar) is transformed into alcohol with enough sugar you can create a nice wine from 11,5% till 14%. The tast of the wine heavily depends on the type of grapes you used, after some month the wine is finished and it can go into a bottle(s), to be drunk after a year or more..
RSE: lol, i have to try to make wine sometime, ill be asking you
Jeroen: No problem!
RSE: ok i gotta ask: Do you like videogames? or what do you think about them?:P
Jeroen: Sorry, I’m not a game guy.
RSE: no worries, im a gamer so i felt the need to ask
Jeroen: I haven’t seen enough of a game to even have a opinion about it :$
RSE: lol
Jeroen: OK
RSE: ill be introducing some for you later then
Jeroen:
RSE: ok so, you are all focused on WATIN, you don have any other project or ideas on your mind?
Jeroen: At the moment all ideas are focussed at WatiN. Adding FireFox support is something we (Edward Wilde and me) are working on. A page/controler framework contributed by Jeff Brown (from MBUnit) is also in the works.
Jeroen: That is it basically., moving to .Net 3.5 is another thing that should be done in the next year
RSE: mm exatclty whats the pag/controller framework for?
Jeroen: That might upon up the posibility for LINQ for WatiN and using UIAutomation
RSE: Adding Fire Fox is a nice feature
Jeroen: The page/controler framwork is an best practise to set up your test framework
RSE: talking about integration, havent you think about a VSTS Integation?
Jeroen: We all have pages with controls on it we need to automate. Some use no abstraction and put all code to run the test in one method but we think a framework would help WatiN users in creating a reusable test framework, VSTS integration for WatiN Test Recorder you mean? One of the next versions will add integrated help to the installation
RSE: mmm yep or create WATIN Tests with the VSTS tools for testers tools, cool
Jeroen: I’m a VS Pro user so I’m not very familiar with the tester edition, but I will have a look at it and see how WatiN could fit in.
RSE: nice, anyway we have some ideas around here, so we will telling you if we get something
Jeroen: hmmmm….. Love to hear them!
RSE: mm ok another question: whats your WATIN Develpment enviroment?, i mean what you OS, Browser version , IDE
Jeroen: OK, here it comes….. VS 1.1 with resharper, windows xp pro, IE7, Test Driven.Net, NUnit, Nant, Cruise control.Net, Notepad++, and some nice add-ins for VS like: gostdoc and copy as html, last week I got my new laptop (Intel Core2 duo 2,6 Ghz, 4 GB memory and 125 GB hard drive). It is amasing! I have a virtual machine running with VS2008 and resharper3 (all preview versions. Anybody like to sponsor me?) and if possible this will become me next dev system. For the .Net 2.0 stuff in WatiN I use SharpDevelop, an open source IDE with some great features!
RSE: wooow, i want that , Ok just wrote it down (and wanting a new laptop). So, for the end, would you like to say something to the testers or WATIN users of the world?
Jeroen: Well, I think everybody should take the tool they like or which suites them best. I’m not the guy who would say WatiN has it all (but ofcourse I would hear what is missing or even better receive a contribution). also testers and developers should talk more to better understand where both are adding value to the app. Unit tests can become even better with the input of a tester and a tester probably gets a better feeling about the developers taking testing seriosly. So these are my wise words I guess
RSE: Nice endind words Jeroen, well i guess this is it for now, thank you very much for your time, now everyone who reads this interview will now more about the “WatiN support, WatiN development, WatiN in general” Answering machine . Thx again for the interview and ill close telling you im a WATIN fan and keep with the awesome work, and also hope to contribute soon
Jeroen: Thank you too, it was fun doing a chatview (chat interview) and keep spreading the word!
RSE: lol, ok ok Thx for the ChatView
Jeroen: Yeah, really enjoyed it
RSE: I enjoyed it too, well i have to go or i dont get my bus to my hometown . Hope to cya later and ill be asking thing at the forums
Jeroen: have a nice weekend and chat u later !
RSE: thx, you too have fun with our kids and wife

Well, that was the interview with Jeroen, we hope you enjoy it as much as we do. Hope to publish another thing soon. Happy New Year!!!

-RSE

Non spanish readers, you will find the original english version of the intwerview here.

RSE: Aló.
Jeroen: Hola.
RSE: ¿Como estas?
Jeroen: ¿Estoy bien y tu?
RSE: Tambien bien gracias, ¿listo para empezar?
Jeroen: Si, que empiece la fiesta!
RSE: Bien, bueno mi amigo no pudo venir, esta con un cliente ahora.
Jeroen: ok
RSE: Entonces me dejó a cargo de todo :p
Jeroen: Esa es una gran responsabilidad
RSE: jajaja, Ok, supongo que es bueno empezar preguntando, ¿Quién es Jeroen Van Menen?, Traté de checar tu pagina web y también traté de buscarte en google, pero solo apareces en foros y comentarios de blog.
Jeroen: Bien, Soy un hombre proveniente de Paises Bajos, viviendo cerca de Amsterdam, pueden encontrarme en mi website: www.vanmenen.nl, tengo 36 años y actualmente tengo tres hij@s y un amor de mujer.
RSE: Que bien, suenas como que tienes una buena vida, me alegra escucharlo
Jeroen: Asi es.
RSE: Traté de ver tu website, pero no ingles o español
Jeroen: Sip, todo holandés, no había pensado que la información podría ser de interés afuera de Paises Bajos, debería añadir un poco de información en ingles.
RSE: Sip, esa es buena idea , ¿y cual es tu carrera o a que te dedicas?
Jeroen: Soy un desarrollardor senior trabajando para una compañia llamada LinkiT. Estamos trabajando en un proyecto de agile para ING Bank en Paises Bajos. Me uní a LinkiT en Julio de este año y estoy muy contento de haberlo hecho, ellos son una de las pocas firmas que practican(realmente) scrum/agile en Paises Bajos, siempre tuve la impresion que tenia que mudarme a los Estados Unidos para estar trabajando en proyectos de agile, pero ahora puedo quedarme en Paises Bajos, lo cual esta bien para mi
RSE: Buena onda, gracias por la presentación , ahora, nosotros te conocemos por WatiN, ¿Cómo nació la idea de WatiN?
Jeroen: En mi compañia anterior, estabamos empezando la automatización de pruebas para ayudar al tester a hacer pruebas de regresion mas rapidoas en una aplicación de una empresa grande, completamente construida en ASP.Net, entonces necesitabamos una forma de automatizar esto. Primero usamos una herramienta comercial para solucionar ésto, en un pricipio nos funcionó muy bien, pero nos metimos bastante en la automatización y queriamos mas, y la herramienta nos detuvo, tambien tenia muchos bugs que causaban que los builds nocturnos fallaran muy seguido. Entonces, esa no era nuestra opción, busqué en la red para ver que habia. Como el lenguage de Script era el problema pricipal busqué una herramienta que me ofreciera la libertad a la que estaba acostumbrado como desarrollador, entonces busqué y encontré varias ocpiones pero ninguna que ofreciera automatización usando .NET, realmente me gustó la API de WatiR, pero Ruby como lenguaje no era una opcion en mi compañia (Políticas) empece a migrar WatiR a .Net… Y asi es como empezó WatiN.
RSE: Ooh, puedes decirme ¿Qué herramienta comercial estaban usando?
Jeroen: Ahora tengo que pensar bastante, dejame checarlo, si, ahora recuerdo, Seapine tiene una herramienta llamada QA Wizard, ellos la compraron para completar su suite.
RSE: Oh, yo la he probado.
Jeroen: Pero esta herramiento no tenía la misma calidad que TestTrack Pro o Surround SCM, las cuales también usabamos. Desde entonces el producto ha evolucionado, pero nunca la he checado nuevamente (por que WatiN ha hecho el trabajo muy bien)… ¿Cuál es tu opinión acerca de la herramienta?
RSE: Bueno, como te dije, yo la probé y en mi opinión la herramienta aun necesita algunas mejoras, y WatiN puede darnos mejores resultados, la diferencia es que necessitamos un mayor perfil técnico para WatiN que con QA Wizard, y esa es una ventaja de las herramientas comerciales.
Jeroen: Estoy de acuerdo, esa es una gran diferencia y tambien explica por que WatiN es usado mas frecuentemente por desarrolladores que por gente del área de QA con un perfil técnico mas bajo, o sin perfil alguno.
RSE: Sip, Bueno eso es algo de lo que queremos cambiar
Jeroen: WatiN Test Record intentó llenar ese vacio, y creo que hace un gran trabajo.
RSE: Si, asi es, lo hemos usado y es una de las herramientas de soporte para un proyecto de automatización de pruebas, supongo que nuestra otra herramienta es la IE Dev Toolbar
Jeroen: IE Dev toolbar es NECESARIA!
RSE: jajaja, sip, pero de cualquier forma tiene algunos problemas, por ejemplo nunca te da la etiqueta “Value”, por esto de todas formas tenemos que checar el código. Bueno, hablando del área de QA, ¿Qué piensas o que opinión tienes acerca de el tester y la practica de testing?
Jeroen: mmm, ¿puedes plantearme de nuevo la pregunta? porfavor.
RSE: mm ok, ¿Qué es el tester para tí?, ¿Qué es lo que hace?, ¿Es necesario para el proceso de ingeniería de software?, ¿Te gustaría que tuviera otras habilidades?
Jeroen: Yo creo que los testers son muy necesarios, es sorprendente como pueden contribuir a la calidad de un producto, incluso en proyectos agile, donde cada quien escribe las pruebas para su código, ellos aun muestran valor, ejecutando las pruebas manualmente o automatizadas(parcialmente), ellos ven cosas donde los desarrolladores no. Por lo tanto, si, los testers deberían estar en el equipo, y me gusta que tomen parte durante todas las fases del ciclo de desarrollo, generalmente son ellos los que conocen el sistema desde una perspectiva funcional, y de esta forma ellos pueden añadir valor al diseño funcional y detectar errores tempranamente durante el desarrollo.
RSE: Ok, tu suenas mucho sobre lo que intentamos hablar en nuestro blog, por que al menos en México tenemos que enfrentarnos con mucha gente que ve al tester como un pequeño y molesto bicho, o bien un recurso innecesario… Es en tu opinión un punto de vista común en Paises Bajos?
Jeroen: Hmmm, por lo que he visto, administración (management) piensa que cualquiera puede probar…
RSE: Buen punto, nosotros aqui(México) tenemos el mismo problema
Jeroen: … Pero también he conocido grandes testers aqui en Paises Bajos, y ellos realmente van mas alla del checar que el botón nos lleva a la pantalla siguiente , entonces pienso que el tester esta subestimado y ellos deberian tener un rol de consejero pero no convertirse(no mucho) en alguién meramente crítico. Probablemente esa parte lleva a verlos como “personas molestas”.
RSE: Sabias palabras , ¿No has estado tentado a ser un Tester? :p
Jeroen: Gracias, lo fuí por año y medio pero me gusta mas escribir código , obtuve el rol por escases de testers y yo era el tipo que hizo la automatización de pruebas para la aplicación, lo cual se les hizo la respuesta logica para llenar el vacio (= ¿Cualquiera puede ser Tester?).
RSE: entonces, tu alguna vez fuiste un colega tester, jajaja.
Jeroen: Sip!
RSE: En mi opinión, yo no creo que cualquiera pueda ser un Tester(tu podrias ser uno muy bueno, pero prefieres el lado oscuro , y ahora, hablemos sobre ¿qué es lo que te gusta?, ¿cuáles son tus hobbies o tus pasiones?
Jeroen: Hmm, soporte WatiN, desarrollo WatiN, WatiN en general, pero de verdad. Mis niñ@s (2, 5 años y 3 meses), es muy divertido estar con ellos, mi cámara digital es algo que uso muchisimo y hago vino.
RSE: No entendí lo de “soporte WatiN, desarrollo WatiN, WatiN en general, pero de verdad”, lol me di cuenta de eso(cámara digital) en tu website, ¿haces vino?
Jeroen: WatiN *.* es mi pasión y gran hobby. Como es open source generalmente desarrollo en las noches, y basicamente esto rige sobre otras cosas.
RSE: oooh ya entiendo.
Jeroen: Eso suena como que siempre estoy detrás de mi laptop, pero tambien tengo vida privada, no te preocupes.
RSE: jajaja, si también me doy cuenta que te gusta más estar con tu esposa e hijos que en frente de tu laptop, mmm ¿cómo haces el vino?, tengo curiosidad al respecto
Jeroen: Aqui estan los pasos básicos (muy básicos): Tomas muchas uvas (aún para 5 litros) y extraes su jugo, después añades una levadura especial para vino, y pones todo en una gran botella de vidrio. Entonces va a comenzar a burbujear y la azucar del jugo (o la azucar añadida) se transforma en alcohol, con azucar suficiente puedes hacer un vino con 11.5% a 14% de alcohol. El sabor del vino depende en gran medida de las uvas que uses, despues de algunos meses el vino esta listo y puede ir a botellas, para emborracharse despues de un año o mas.
RSE: lol, lo tengo que hacer vino algún día, te estaré preguntando
Jeroen: No hay problema!
RSE: ok, tengo que preguntar: ¿Te gustan los videojuegos? ¿Qué piensas acerca de ellos?
Jeroen: Sorry, no soy del tipo gamer.
RSE: No hay problema, yo soy un gamer, entonces tenia la necesidad de preguntar :p
Jeroen: No he visto lo suficiente de un juego como para siquiera tener una opinión al respecto :$
RSE: lol, entonces te mostraré algunos después
Jeroen: OK.
RSE: Ok entonces, tu estas completamente enfocado en WatiN, ¿Tienes algún otro proyecto o ideas en tu cabeza?
Jeroen: Actualmente todas las ideas se centran en WatiN. Añadir soporte a FireFox es algo en lo que estamos (Edward Wilde y yo) trabajando. Un framework controlador, contribución de Jeff Brown (de MBUnit) también también se esta tratando. Éso es básicamente, migrar a .Net 3.5 es otra meta que será terminada en el siguiente año.
RSE: mm exactamete ¿para qué es el framework controlador?
Jeroen: Eso abre la posibilidad de trabajar con LINQ y WatiN y usar UIAutomation
RSE: Soporte a FireFox es un buen feature también
Jeroen: El framewok controlador es una mejor practica para crear tu framework de pruebas.
RSE: Hablando de integración, ¿no han pensado en una integración con VSTS?
Jeroen: Todos tenemos páginas con controles en ellas, que necesitamos automatizar. Algunos no abstraen y ponen todo el código en un método, pro eso pensamos que el framework ayudará a los usuarios de WatiN acrear un framework de pruebas reusables. ¿Te refieres a una integración de WatiN Test Recorder con VSTS?, en una de las siguientes versiones se añadirá ayuda en la instalación.
RSE: mmm sip, o mas bien crear pruebas de WatiN con las herramientas de testing de VSTS, me parece muy bueno lo que estan haciendo.
Jeroen: Yo soy un usuario de VS Pro, por eso no estoy muy familiarizado con la edición de testing, pero le daré un vistazo y pensaré como podemos acoplarlo con WatiN.
RSE: perfecto, de cualquier forma tenemos algunas ideas, entonces te estaré informando si hacemos algo
Jeroen: hmmmm….. Me encataria oirlo!
RSE: ok, otra pregunta: ¿Cuál es tu ambiente de desarrollo para WatiN?, quiero decir ¿Qué SO, Browser, IDE?
Jeroen: Ok, ahi te va… VS 1.1 con resharper, windows xp pro, IE7, Test Driven.Net, NUnit, Nant, Cruise control.Net, Notepad++, y algunos buenos add-ins para VS como: gostdoc y copy as html, la semana pasada obtuve my nueva laptop (Intel Core2 duo 2,6 Ghz, 4 GB memory y 125 GB hard drive). Es sorprendete! tengo una maquina virtual corriendo con VS2008 y reshaper3 (todas preview version, ¿alguién gusta patrocinarme?) y es posible que éste sea mi siguiente sistema de desarrollo. Para .Net 2.0 en WatiN uso SharpDevelop, un IDE open source con grandes características.
RSE: wooow, quiero esooo , Ok, ya quedó apuntado (y yo quiero una nueva laptop). Bueno, para finalizar, ¿Te gustaría decir algo a los testert o usuarios de Watin del mundo?
Jeroen: Bueno, yo creo que todos deberian probar la herramienta que les guste y les acomode mejor. Yo no soy del tipo que dice “WatiN lo tiene todo” (pero desde luego que me gustaria oir que le falta o mejor aún recibir algun contribución). Tambien los testers y desarrolladores deben de comunicarse mas para entender mejor que ambos le dan valor a la aplicación. Las pruebas unitarias puedesn ser mejores con la entrada de un tester, y los testers puedesn sentirse mejor sabiendo que desarrollo esta haciendo sus pruebas seriamente. Y supongo que esas son mis sabias palabras.
RSE: Buenas palabras para finalizar Jeroen, bueno supongo que eso es todo por ahora, muchisimas gracias por tu tiempo, ahora quien lea esta entrevista conocerá un poco mas de la maquina contestadora de “WatiN support, WatiN development, WatiN in general” . Gracias de nuevo por la entrevista y la termino diciendote que son un fan de WatiN y continua con el estupendo trabajo, esperamos que podamos contribuir en algo pronto.
Jeroen: Gracias a ti también, fue divertido hacer la “chatview” y continuen corriendo la voz!
RSE: jajaja, ok ok Gracias por la “Chatview”
Jeroen: Si, realmente la disfruté
RSE: yo también, bueno tengo que irme o si no no alcanzó el autobus para mi casa :p . Espero verte después y seguiré preguntando cosas en los foros
Jeroen: Ten un buen fin de semana y chateo contigo luego!
RSE: Gracias, diviertete con tus hij@s y esposa

Bueno esa fue la entrevista con Jeroen, esperamos que la hayan disfrutado tanto como nosotros. Esperamos publicar algo muy pronto, y Feliz Año!!!

-RSE

Pues bueno esta vez como segunda entrada (a partir de esta ya no contaré), quiero hablar de un tema que por lo general crea conflictos a lo largo de todo el proyecto y que suelen poner en riesgo al mismo: Los requerimientos del sistema.

A grandes rasgos podriamos definir a los requerimientos como la guía que dicta que es lo que tiene que hacer el sistema que se va a crear.

Por esto desde luego que los requerimientos siempre son claros como el agua y cubren hasta el mas minimo detalle… … Siiiiii Seguro O.o … Desde luego que lo que acabo de decir previamente NO ES REAL, ni siquiera es algo cercano a la realidad. Lamentablemente por la naturaleza de la ingenieria de software los requerimientos nunca podrán cubrir el 100% de todo un proyecto, tomando en cuenta factores como funcionalidad, usabilidad, performance o seguridad. A esto tenemos que añadir que al analizar y diseñar los requerimientos lo único que tenemos es documentación y una IDEA de lo que será la aplicación, que en el mejor de los casos se traduce en un prototipo (Que muchas veces cuando comparas la versión final con el prototipo no tienen absolutamente NADA que ver).

Entonces, aquí a nosotros los testers se nos presenta un gran problema cuando después de arduas y difíciles semanas de pruebas, el producto final pasa a las manos de los usuarios para que ellos, indiscriminadamente y si n tocarse el corazón, comiencen a levantar miles de defectos… En ese preciso momento uno quiere que se lo trague la tierra y nunca haber sido asigando al proyecto… Y ni que decir cuando llegue el momento de hacer métricas y presentarlas a la corte celestial y te pregunten “¿Entonces que probaste!!!??“.

Yo considero que esta situación puede tener dos orígenes: El tester apesta o bien que las herramientas y fuentes de información que se tuvieron durante el análisis y diseño de las pruebas no fueron suficientes para cubrir todos los requerimientos reales del sistema.

Para el primer origen pues no hay mucho que hacer (o se tiene o no la madera para Testing), para el segundo aquí les dejo unos consejos para el análisis de requerimientos y evitar problemas como los mencionados anteriormente, para no tener otro post gigantesco (que este no es nada chiquito pero aún no puedo condensar mas mis ideas, pero ya aprendere) solo mencionaré estos y algún quizás detallaré cada uno de ellos, o bien si hay dudas los puedo aclarar en las respuestas de este post:

• Comenzar el Análisis y diseño de las pruebas previo a la finalización del desarrollo.
• Presentarse ante todo el equipo del proyecto, TODOS, no solo al área de sistema.
• Pedir toda al documentación existente y analizarla.
• Preguntar al equipo de desarrollo que hace su aplicación o módulo que desarrollaran o estar desarrollando.
• Preguntar al Project Manager de que trata el proyecto o aplicación.
• Conocer quienes son los usuarios involucrados.
• Pedir sesiones de capacitación si la aplicación ya existe
• Ir con los usuarios involucrados y aclarar que es lo que esperan del proyecto.
• Conocer la operación actual del negocio y como se verá afetada con el nuevo proyecto.
• “Traducir” a lenguaje de usuario la solución que se esta desarrollando: Este si merece descripción :p, es muy importante que ambas caras de la moneda (usuario y sistemas) esten enfoncados a la misma meta, y desde luego que ambos tengan la misma idea de meta. Por esta razón nosotros nos debemos de asegurar que lo que se esta programando sea lo que se esta pidiendo, una forma sana es platicando al usuario cual es la solución a nivel negocio que se esta proponiendo con el nuevo sistema, o quizas ser un poco mas profundo pero sin dejar de tomar en cuenta que posiblemente las personas con las que estas platicanod no tengan una gran conocimiento técnico.
• Levantar la mano apenas se encuentra alguna diferencia entre lo que el usuario espera y lo que se esta haciendo.
• Si se encuentra algo que no estaba contemplado definirlo claramente con desarrollo para ver si se puede corregir mucho antes de su desarrollo.
• En caso de no saber si esta bien o mal lo que hace la aplicación pedir a los usuarios y sistemas su opinión, muchas veces se presentan casos que ninguno de ellos habian considerado y en lugar de criticarte por no saber te van a dar una palmadita en la espalda (Yo digo que nos deberian de dar medio salario, por que pues los salvamos de una broncototototota, pero bueno como hacemos esto por amor al arte, la palmadita esta bien, siempre y cuando sea en la espalda, si no AGUAS!!)
• Vuelvete un metiche en todo lo que respecta al proyecto pero sin llegar a ser molesto, tienes que aprender a identificar muy bien esta linea, si crees que estas sobrepasandote, detente.
• Una vez que tengas tu diseño básico de prueba, vuelve a analizar los documentos pero ahora enfocado a ver “¿Que es lo que no estan contemplado? ¿Que se les escapó?”

• MANTEN TU CURIOSIDAD EN ALTO!!

Estos son algunos consejos que me vienen a la mente por el momento, si ustedes tienen algunos otros mas porfavor sientanse libres de listarlos, sería bueno hacer una guía sobre todos los puntos que aquí se obtengan.

Muchas gracias por leer y Sean felices!!! :p

RSE

El objetivo de la herramienta es facilitar la identificación de tamaños en cajas de textos, para agilizar las pruebas de dominio y boundary testing. Solo es necesario presionar su botón [Get Size], seleccionar el textbox y presionar [F5]. Así empezará un ciclo de keystrokes que termina cuando el textbox alcance a su límite.

Hecho con el genial AutoHotkey, el código fuente está disponible en la misma página.

Claramente, por ahora no es muy asombrosa, pero tengo ideas para versiones futuras (el código ya incluye funciones que utilizaré despues). Espero que alguien le encuentre tanta utilidad como yo.

-luistoledo

El día de hoy hablare del tester.

Quizás a varios que forman parte del mundo de ingenieria de software les puede resultar extraño pensar en el área de pruebas como un área donde se pueda tener beneficios, reconocimiento o opotunidad de crecer, incluso se que existen personas que ven a testing como un hoyo, en el cual si no sales nunca serás un buen profesional.

Yo llegue al mundo de testing por pura casualidad, como algunos ya saben (si es que leyeron la primer entrada) yo salí de tierras oaxaqueñas, donde pues la verdad no hay mucho futuro en el area de sistemas y telecomunicaciones, con sus contadas excepciones desde luego. Yo tuve una oportunidad de ser candidato a irme a Monterrey de desarrollador, la consultoria que me iba a contratar se veia convencida de perfil y habilidades. Me llamaron y me dijeron que ya todo estaba listo y solo me confirmarían el dia del viaje(no mas de una semana), entonces deje todo en orden en mi trabajo anterior y resulta que el proyecto no salió, entonces… en ese momento era un desempleado bajo la protección de mi mama (bueno al final de cuentas ya neceistaba vacaciones).

Pero asi pasaron 4 semanas sin que hubiera un proyecto ni señales de moverme a Monterrey proximamente, entonces debido a mi presión tipo “Oigan… Ya renuncie a mi trabajo anterior, llevo 4 semanas esperando, se supone que ya era seguro, ¿Que fue lo que paso?… DENME TRABAJO MALDITA SEA!!!!!”. El chavo de la empresa que era mi contacto directo con la empresa(desde ahora se llamara Ranulfo para futuras referencias) me habló por telefóno y me dijó: “Pues mira, hay chamba… pero… de tester…”; al oir eso por mi mente cruzó la idea de game testing, ya que para los que no saben tengo una graaaaan debilidad por esas cosas del diablo que se llaman videojuegos(adquirí autonomia para jugar desde los 4 años), entonces le dije “osea, probar las aplicaciones no?” y el me dijo algo como “exacto, pues solo hay de eso”; entonces yo acepte sin dudarlo (para ser sincero no evalue en que me metia en ese momento ni nada, digo no tenia trabajo y me sabia que seria una buena experiencia).

Esa fue mi entrada hacia la disciplina de testing.

El dia de hoy puedo decir que estoy contento de haber tomado esa decisión, de eso no tengo duda alguna (aunque DBA aún me llama, alguién se arriesga? :p).

Lo que llamó mi atención fue la forma en que Ranulfo me dijo con cierta reserva que solo habia puesto para testing, incluso recuerdo que cuando llegué a Monterrey tuve una platica con Ranulfo, y recuerdo que me dió un discurso de que el chiste era que le echara ganas para que pudiera saltar a un proyecto ya de desarrollo, con esto me di cuenta que el no veia de forma positiva el rol de tester, con el paso del tiempo me di cuenta que la impresión de Ranulfo era compartida por la mayoria de las personas involucradas en los proyectos en los que he estado.

Entonces me puse a pensar: “Si la mayoria de la gente piensa que testing es una disciplina menor a las demas, por que demonios llevo 2 años y medio aquí, ya me tarde para volverme dev… mis mejores tiempos se pueden estar perdiendo y todo por que yo sigo como un mortal tester”.

La respuesta fue simple: Yo no veo a un tester como el resto de esas personas lo hace, es decir como la persona que solo va a probar que la aplicación funcione como debe y se encarga de quejarse con el desarrollo si no es asi.

Para mi el tester es una persona que debe de tener la habilidad para demostrar que una aplicación tiene bugs pero tambien demostrar la auscencia de estos.

Encontes podemos ver que no solo es probar y quejarse, ya comenzamos a hablar de una demostración, la cual requiere de un buen análisis y un diseño de pruebas que nos ayude a obtener esos resultados.

Este análisis y diseño debe de tomar en cuenta los puntos de vista de todas las partes involucradas en el proyecto, es decir: Usuarios, Analistas, Arquitectos, Desarrolladores, etc. Esto conlleva a hablar el mismo idioma de cada uno de los roles, por ejemplo, al hablar con un usuario este por lo general te hablará en terminos de negocio, de lo que debe de pasar en la operación sin importarle (o entender) como esta por dentro la aplicación, en cambio un desarrollador hablará en terminos a la lógica que siguió para construir lo que se le pidió. Con esto tenemos la necesidad de entender lo que cada uno nos presenta y hacer que nuestro análisis y diseño contenga toda la información que obtuvimos de las distintas áreas.

Como consecuencia del punto anterior un buen tester ademas debe de saber mantener una buena comunicación con el resto del equipo pero esta no solo se da cuando estamos diseñando nuestras pruebas, de hecho se debe mejorar conforme se avanza en el proyecto, ya que el tester se debe de enterar de los cambios que se efectuen, asi como dar a conocer oportunamente los resultados de las pruebas y verificaciones de errores realizadas.

Hasta este momento espero que quienes han asimilado y comprendido los 3 parrafos anteriores ya no tengan la idea que un tester puede ser cualquier persona que pruebe la aplicación, y que al menos debe de cumplir con ciertos requisitos.

Complementando la respuesta a mi pregunta sobre “¿Por que soy un tester?” puedo decirles que creo que estamos en los inicios de una evolución de la disciplina de pruebas, esta crecerá rapidamente y el testing funcional será tan solo una parte de todo el proceso de pruebas. Con lo que las técnicas avanzadas de testing dejarán de ser un “nice to have a un “must be”.

Esto implica que “yo, tester” tengo la oportunidad en estos momentos de marcar mi propio paso, de inovar en metologias y procesos, crear y definir las especialides de testing, implementar nuevas formas de probar, en resumen contar con libertades que en otras áreas es mas dificil lograrlo.

Para cerrar esta entrada una vez platicando con Luistoledo salió una frase mas o menos asi: “Testing es algo que ya lleva años en la teoria de ingenieria de software, a la fecha actual testing al fin se esta poniendo en practica, se esta convirtiendo en la moda del dia, y el mundo ya lleva medio dia en ella y en México son las 2 de la mañana”.

Sean Felices!!!

RSE

El dungeon: una aplicación web con mas de 50 campos distintos debian ser llenados a lo largo de 5 formularios, y varias bifurcaciones dependiendo del las deciciones tomadas.

Los NPC’s: Inputs con Id’s repetidos, con onClicks que los identificaban. Popups de ventana que desaparecian justo al rellenar algún campo, divs ocultos a manera de ‘popups’. Objetos en celdas, dentro de divs de IFrames. Checkboxes que habilitaban menús.

My weapons: MS Visual C# Express Edition, IE Dev Tool Bar, WatiN 1.1.2 y excel.

Con tal escenario, tomé código de RSE (que combinaba excel y watiN), y diseñe un interprete. En una hoja de excel donde manualmente (ayudado por el IE Dev Toolbar) capturé los id de los campos de todos los formularios, el div, y frame en que se encontraba, el ‘tab’ del formulario y algún otro identificador extra. Despues y horizontalmente, una fila con los nombres de los campos. Debajo, todos los datos a utilizar en la prueba. Debo admitir que despues de 18 horas de trabajo deseché el 80% del código, pues mi diseño de código era muy malo -peor que ahora, creo que ya aprendí algo. Hubo hardcode para resolver algunas trampas del dungeon, lo admito, pero con buenas intenciones.

Casi terminaba mi countertime, y no pude probar el código que evaluaba el resultado, así que lo probé conceptualmente y lo encomendé a Crom. En ese momento dejé el proyecto y RSE se quedó a cargo de todo mi código (pobre de él). Pero un par de semanas despues la presentación fué un éxito. Según entiendo, RSE rehizo evaluación de resultados que mencioné, saltaron problemas menores con la interpretación del spell en PCs usuarias, un par de goblins nuevos aparecieron en los formularios y mas… Pero todo OK.

Con los puntos de experiencia ganados subió el nivel de mi subclase: tester. Y le di puntos a mis skills: C# & watiN spells, HTML taunt. Además de ganar recidencia en Promiced City, y creo que compraré un backpack de 120g para mis handcrafted tools (spoiler).

-Detalles técnicos en próximos posts.-

- luistoledo

Victimas de esta moda somos Luis Toledo y Raul Sanchez, quienes compartimos el objetivo de crear este blog para mostrar nuestra vision, opinion y descubirimientos en las areas relacionadas con Testing. En conjunto decidimos hacer ésta primera entrada en el blog. Las siguientes ya serán a discreción de cada uno.

Hasta hoy se han creado un significante número de metodologías, conceptos, y técnicas de pruebas de software. En particular, nosotros hemos crecido con el Proceso T™, desarrollado por la empresa donde actualmente trabajamos. A nuestro entender, el proceso es bastante flexible y adaptable a cualquier metodología de desarrollo de software que encontramos hoy en día (Nota: No estamos haciendole la barba a nadie, que quede claro). Sabemos que aun no podemos considerarnos grandes conocedores en el ámplio mundo del testing, pero estamos gustosos por compartir en éste blog, lo que vayamos descubriendo. Ese es el propósito de éste espacio, asi como recibir de nuestros lectores todas las críticas, consejos y experiecias posibles con el fin de mejorar nuestros contenidos..

Acerca de NNIX (no, no significa Newbridge Nanotechnology Index), no hay gran complejidad tras el nombre de este blog, NNIX significa: “probar” en Zapoteco, y por que en zapoteco? pues por que somos de Oaxaca (dato: los Zapotecas fueron una cultura prehispanica que, junto con los mixtecos, dominó la región de Oaxaca antes de la colonización española en México). Con este nombre pretendemos mostrar que la cultura de software con QA se encuentra en expansión y no está restringida por idioma o cultura. Y a la vez, el nombre distingue nuestra visión de las del resto.

Sobre Because Your Son Could Be a Tester…Primero: se supone que es gracioso (si no lo encuentra así, no lo diga, solo riase en confidencia). Pues bueno, con el tiempo que llevamos en pruebas nos hemos dado cuenta que a pesar del desarrollo de la disciplina de testing aun hay muchas personas en el área de IT que no comprenden|dimencionan el rol que ésta desempeña; es decir, que las pruebas de software van mas alla del simple “Pon a un Dev novato a probar”, también queremos opinar acerca de que aptitudes y habilidades ayudan a un tester en su trabajo, y las necesidades de Técnicas avanzadas de pruebas. Todo ésto con un fin claro: Poner el alto el nombre del área de pruebas y ayudar al resto de las personas a entender que somos sus amigos… :p

Asi que esperamos que este blog sea de su agrado, por ultimo les dejamos otros títulos que en algún momento propusimos para este blog acompañado de algún dato curioso:

- Because your son could be a tester: Idea original—> Luis Toledo (LT), pues que puedo decir? el ganador supremo de la competencia del nombre
- Testing To Evolve: Idea original—> Raúl Sánchez (RS): Buena idea pero pues sin mucha gracia, el título intenta mostrar al testing como una necesidad.
- We Also Hate Testers: Idea original—> RS: Antes que nada no me malinterpreten aquellos testers que lean esto, me caen muy bien y si los llegara conocer me caerian mucho mejor, solo fue un titulo para crear simpatia hacia las otras áreas de IT asi como dejar claro que a los “testers” que odiamos son esos que solo buscan probar lo básico, el camino facil, sin metologia, ni gracia, ni estilo. Testing puede dar grandes beneficios, muy buenos como para ser tomado a la ligera.
- Sumo Tester: Sacado de un generador de nombres de canciones (que ya no encuentro[LT], jajajaja[RS]).
- Testing Attitude: Sacado del mismo generador.