The Testing Manifesto

Así como existe un Manifiesto Agile, está bueno que exista uno sobre el testing de hoy en día. Una propuesta es el que ven acá arriba. Son 5 cuestiones básicas que deben regir sobre como actuamos mientras hacemos testing y que resumen qué es, realmente, hacer Testing.

Probar durante antes que probar al final: Si estas en un proyecto bajo la metodologías ágiles y pruebas solamente cuando el desarrollo está completo, no estás siendo ágil y tampoco estas haciendo bien tu trabajo. Es mucho mejor ir testeando a medida que los desarrolladores van completando sus tareas, de manera de poder darles un feedback rápido y solucionar los problemas antes del final del sprint.

Prevenir los defectos antes que encontrar defectos: Generalmente nos contratan para encontrar defectos...pero ese no es nuestro trabajo principal. Lo que debemos lograr es prevenir que se creen esos defectos antes que lo encontremos. Como? ayudando a los desarrolladores a testear mejor sus desarrollos, a que entiendan los posibles caminos alternativos. Analizando los requerimientos, buscando fallas en los mismos o cosas asumidas y que no son claras.

Entendimiento del testing antes que chequear funcionalidad: Verificar que la funcionalidad nueva ¨funcione como se espera¨ no  es hacer testing, es solo hacer un checking manual, el cual podría automatizarse a futuro, pero no es hacer testing.
Testing es entender la funcionalidad, su contexto, quienes la pueden usar, como afectara a las viejas funcionalidades, que cosas le faltan, que cosas le sobran, y cualquier otra información necesaria que nos permitirá entender mejor qué estamos testeando y generar luego un reporte con la información obtenida a partir de nuestro trabajo, para que la gente que decide sobre la calidad del producto, pueda tomar decisiones.

Construir el mejor sistema antes que romper el sistema: aparte de encontrar defectos, los demás creen que lo que hacemos es romper el sistema, y nos ven como seres negativos y oscuros porque rompemos eso tan bonito que pensaron, diseñaron y construyeron. Pues les tengo noticias, los testers no rompen el sistema...ya estaba roto. Nuestro trabajo es ayudar a los que lo construyen a hacerlo lo mejor posible, con la mayor calidad posible, somos parte de ese proceso de construcción, no los agentes de destrucción!

Responsabilidad del equipo por la calidad antes que responsabilidad del tester: No somos los guardianes de la calidad, no somos los policías que van descubriendo los crímenes de los desarrolladores. Como testers, somos responsables de ayudar al equipo en su totalidad a comprometerse con la calidad del producto. El producto se realiza entre todos, y la calidad también. Debemos asegurarnos que el equipo desarrolle practicas que ayuden a mejorar la calidad, ya sea desde el análisis, el diseño, el desarrollo o el mismo testing. La calidad es responsabilidad de todos, si eso es entendido por todos, será mucho mas fácil mejorar.

Creen que falta algún punto? algo para mejorar? Seguramente que si, pero con estos principios básicos, la calidad del producto, y nuestro trabajo, será mucho mejor.

Bug Magnet - Pequeña herramienta para facilitar la vida

Me encanta cuando los testers que se dan mañana para programar, hacen pequeñas joyas como esta. Hoy les presento Bug Magnet, un add-on originalmente para Chrome, creado por Gojko Adzic que facilita la vida haciendo un checklist con diferentes tipos de inputs a tan solo un  click derecho de distancia.

Podemos usar Lorems, diferentes tamaños de textos, tipos de nombres, emails validos/inválidos, números, espacios en blanco, SQL injection y un largo etcétera. Muy útil para no olvidarse ningún tipo de combinación rara.

Muy fácil de usar, me encanta cuando las ideas simples se vuelven herramientas imprescindibles.

Les dejo acá bajo donde bajarlo, espero que les sea útil

Chrome: http://gojko.github.io/bugmagnet/

Firefox:  https://addons.mozilla.org/en-us/firefox/addon/bugmagnet-firefox/?src=search

Como trabajar en el interior del país y no morir en el intento

Este post está dirigido a los "porteños", los cuales nos referimos al resto del país como "El Interior", y especialmente a los que sueñan con irse de la gran ciudad y vivir mas tranquilos en alguna provincia.
Por razones personales, debo volver a Buenos Aires, es por eso que antes quiero contar mi experiencia en Mendoza y mi búsqueda previa y primeros tiempos aquí.

la dura vida en el interior...

Todos vemos normalmente en las películas y series estadounidenses, que los protagonistas se van de una ciudad a otra, ya sea por trabajo o por estudio, pero generalmente cuando es por trabajo, lo hacen ya con el trabajo conseguido desde su lugar de origen. Tal vez no sea algo tan común o fácil de hacer, pero es mas normal que en Argentina.
En nuestro país, generalmente la gente "del interior" viene a la Mega ciudad de AMBA (Area Metroplitana de Buenos Aires...o sea Capital y Gran BsAs) a vivir y tratar de conseguir trabajo, muy pocos llegan ya con un trabajo. Lo mismo sucede con los locos que nos vamos a otra provincia, la mayoría primero llega y luego consigue el trabajo. Es muy dificil conseguir el trabajo estando lejos, la mayoría de las empresas tiene procesos arcaicos en donde en un punto u otro te quieren ver en vivo y en directo. Hoy por hoy hay 2 rubros en donde se puede conseguir trabajo antes de llegar: Turismo (mayormente trabajos temporales) o en Informática, como es mi caso.

Camino al trabajo

En 2011, cuando estaban terminando mi carrera, empecé mi búsqueda de oportunidades en las provincias Argentinas. Lamentablemente, como en casi todos los rubros, la mayoría de las empresa tecnológicas se encuentran en el AMBA y en menor medida en las grandes ciudades (Córdoba, Rosario, Mar del Plata, Tucuman y Mendoza), en los polos tecnológicos (San Luis, Paraná, Tandil, Posadas, entre otros) o en el único lugar en donde se hace tecnología de punta: Bariloche (Centrales Nucleares y Satélites tambien necesitan ingenieros en sistemas).

La mejor forma de empezar es tratando de saber primero a donde queremos ir a vivir (y tener más de una opción por las dudas) y luego armar una lista con todas las empresas que están en esa zona. A veces es dificil ir hasta el lugar y conocerlo en persona, aunque es lo ideal, hay que aprovechar unas vacaciones para ir y conocer.
Hoy en día ayuda mucho Linkedin y Google, buscando palabras claves como "relocalización", "relocarse","trasladarse", etc.
Luego hay que empezar a hacer networking en Linkedin con los de RRHH y empleados de las empresas de la zona que nos interesa. Los reclutadores por razones obvias, y los empleados por que a veces te pueden dar información a cerca de la empresa que trabajan ( es solo cuestión de pedirlo amablemente)
Una vez que tenemos la ciudad donde queremos vivir, las empresas disponibles, y los contactos, hay que empezar la búsqueda. Muchas veces las empresas no publican en los medios tradicionales que usamos, como los portales de trabajo o Linkedin mismo, por eso hay que mandarles nuestro curriculum igual, uno nunca sabe.

El asadito se hace con Leña!

Lo ideal es empezar por las empresas que hacen búsquedas activas y una vez que entremos en contacto ir tanteando cuales están dispuestas a contratar gente "de afuera". La mayoría quieren al candidato en el mismo lugar para poder entrevistarlo, hay que tratar que te acepten tener una primera entrevista via skype o similar. Luego hay que tratar de reducir el grupo de empresas a aquellas que esten dispuestas a ofrecer un plus por trasladarnos hasta allí a trabajar y vivir y negociar.
En mi caso particular tuve una sola propuesta en donde me ofrecían el alquiler temporal de un departamento y un plus por mudarme y fue en Belatrix, una de las principales empresas de servicios nearshore de latinoamerica. Todo el proceso lo hicimos via skype y me facilitaron todo lo necesario para ayudarme en la transición a mi nuevo trabajo y ciudad. Belatrix tiene oficinas en Chacras de Coria, con unos hermosos jardines y otras en plena Ciudad de Mendoza, mas parecidas a cualquiera de las que se pueden encontrar en BsAs.
Finalmente, una vez que conseguimos el trabajo, lo que hay que hacer es sacarse el miedo al cambio.
Tenes hijos? te lo van a agradecer, van a vivir mas tranquilos, conseguiles una casa con jardín (generalmente cuestan menos alquilar que en AMBA). Estas casado? habla mucho con tu pareja antes de empezar la búsqueda, pero mucho, y si pueden ir juntos a conocer la ciudad en donde quieren vivir, mejor. Vas a extrañar a tu familia? cuantas veces la ves al año? skype y 1 o 2 horas de avión hacen que las distancias sean cortas. Yo he visto a mi familia al menos una semana al año en estos 3 años.
Es fácil cambiar? y no, no lo es, pero si no probas nunca vas a saber que vale la pena. Hay que dejar de tenerle miedo al "interior" y ver las oportunidades que hay mas allá del Gran Buenos Aires.
Cada día hay más empresas dispuestas a contratar gente de Buenos Aires, por que, como en todos lados, la gente de sistemas escasea. Es cuestión de buscar y ser valiente.
Ojalá mi estadía en Buenos Aires sea lo mas corta posible y pueda volver a ver estos jardines.

Vista desde mi escritorio en Chacras de Coria

Nota aclaratoria: Aunque trabajo para Belatrix, este post lo hago por que quiero. No ha sido solicitado por nadie de la empresa y es mi opinión personal.

Disipando Conceptos Erróneos - "Vamos a automatizar todo y deshacernos de todos nuestros Testers"

Hoy les traigo un post de Dan Ashby, un Analista de Testing de Londres.
Este es el 5to post de una serie, y como se trata de automatización y me estoy metiendo de lleno en estos temas, me pareció muy interesante traducirlo. Espero que les guste.

Oigo esto todo el tiempo. Incluso de gente de muy alto rango. El último de ellos fue de un gerente de desarrollo, preguntando por qué estamos "todavía necesitando tener testers probando el software, si estamos apuntando a  automatizar el 100% de todo"...

En primer lugar, la verdad es muy simple: sólo se puede automatizar lo que sabe y esperas.

Cuando pensamos acerca de los "órdenes de ignorancia", entonces se hace más claro de por qué no es posible automatizar todo. Para aquellos que no están familiarizados con las órdenes de la ignorancia, permítanme explicarlos...

Hay 5 órdenes de ignorancia:

• El orden 0 de la ignorancia es la falta de ignorancia. Esto es esencialmente conocimiento. El conocimiento que se puede demostrar en una forma tangible. Por ejemplo, yo estoy bien informado sobre el hecho de que es imposible automatizar todo.

• El primer orden de la ignorancia es la falta de conocimiento. Esto es cuando no sabes algo y sabes que no sabes eso. Un ejemplo de esto sería que no sé cómo utilizar la herramienta  OWASP Zed Attack Proxy tool, en todo su potencial. Soy consciente de que yo no sé mucho acerca de esta herramienta específica y puedo elegir entre aprender o continuar el uso de diferentes herramientas como Fiddler o Burp Suite.

• El segundo orden de la ignorancia es la falta de conciencia. Esto es cuando no sabes que no sabes algo. Así que aquí es donde yo no soy más que un ignorante sobre algo, pero yo soy ignorante al hecho de que soy ignorante respecto a eso. Obviamente no se puede dar un buen ejemplo de esto, ya que eres ignorante de ello. :)

• El tercer orden de la ignorancia es la falta de proceso del descubrimiento. Así que aquí es donde no estás enterado de ninguna forma de obtener el conocimiento que no sabes que no sabes algo. Esto significa que no se puede aprender sobre las cosas que no sabes, por que no sabes (es decir no puedes tomar conciencia de las cosas que son del segundo orden ignorancia para convertirlas en cosas del primer para la ignorancia).

• El cuarto orden de la ignorancia es un poco descarado. Se trata básicamente de no estar al tanto de los 5 órdenes de la ignorancia. :)

Entonces, al relacionarse esto a la automatización... Puedes sólo automatizar realmente las cosas que están dentro de el orden 0 de ignorancia, donde se tiene el conocimiento y la expectativa de cómo debe funcionar la funcionalidad, por lo tanto, escribes una afirmación que comprueba la salida y devuelve un "pass" o "fail", en cuanto a si la salida cumple esa expectativa inicial.

Por otro lado, cualquier cosa que se ajuste dentro del resto de los órdenes de la ignorancia (en concreto el primer y segundo orden de la ignorancia), será imposible de automatizar, ya que no tienes conocimientos previos sobre cómo funcionará la funcionalidad o función. No tienes una expectativa o no eres consciente de ciertos escenarios o variables que rodean la funcionalidad con el fin de ser capaz de formar una expectativa que sea capaz de afirmar ese chequeo.

El Pensamiento Lateral y Testing Exploratorio ayudan en la transformación de los "desconocidos" en "conocidos", también ayudan en la transformación de los "desconocidos-desconocidos" en "incógnitas conocidas". Si bien no es posible hacerlo únicamente manteniendo conversaciones previas, las conversaciones ayudan. La mejor manera de aprender adecuadamente acerca de cómo funciona realmente un sistema, es de aprender del sistema a medida que investigamos. Por lo tanto estamos aprendiendo continuamente, diseñando nuestras pruebas (pensando nuevas preguntas para hacer al software) y haciendo nuestras pruebas a medida que aprendemos más.

Un segundo punto que me gustaría resaltar es que, incluso para las cosas de orden 0 (las cosas que usted sabe, ni pensar en las cosas que usted no sabe en este momento), es:  va a ser realmente de valor en la lucha para automatizar todo en lo que usted tiene una expectativa? Por ejemplo, ¿vale la pena la automatización de un escenario que sólo tenemos que ejecutar una vez?

Al pensar en lo que hay que automatizar, tenemos que pensar en VALOR... Yo soy un gran defensor de la automatización. Es muy valiosa en los entornos ágiles de hoy, con todo moviéndose mucho más rápido y fluido, con más agilidad. Nos da repetibilidad y feedback extremadamente rápido para nuestras tareas de comprobación, tales como pruebas de regresión o sanity/smoke testing. También es muy útil para ayudar a tus actividades de ensayo pensantes, usarlo para cosas como la creación de datos o la realización de acciones para llegar a lo profundo del flujo de trabajo a la parte del sistema que necesitas para poner a prueba... 

Sin embargo, tenemos que ser conscientes para qué la automatización es útil, y cuáles son las limitaciones, para que no caigamos en este concepto erróneo y cometer algunos errores graves.

Por lo tanto, la próxima vez que escuche a alguien decir "Vamos a automatizar todo", habla con ellos acerca de por qué eso en realidad no es posible y ayuda a hacer del mundo un mejor lugar :)

Dan Ashby

Testing es...

Ayer por la noche (de Argentina), Michael Bolton escribió una serie de tuits sobre qué es el Testing, en una especie de Manifiesto.
Hice un Storify para que los puedan leer, vale la pena aunque estén en inglés.

Por qué no sirve la ISO 29119 para el Software Testing - Parte 2

Continuando con la traducción del articulo de Michael Bolton. Pueden ver la primera parte aquí.
Nuevamente pido disculpas por anticipado por la traducción, no soy un profesional :P.

P: La norma ha estado en desarrollo durante los últimos siete años; ¿por qué has esperado tanto tiempo?

Algunos de nosotros no hemos estado esperando. Por ejemplo, he dado esta presentación en 2011. Algunos de nosotros hemos estado ocupados oponiéndose a los sistemas de certificación (Sólo ahi hay tanto buscador de rentas que uno puede oponer a la vez) Varios de nosotros hemos discutido largamente y en público con algunas de las figuras más prominentes que promueven la norma en las conferencias. A veces parecen no entender nuestras objeciones. Sin embargo, como dijo Upton Sinclair: "Es difícil conseguir que un hombre comprenda algo cuando su salario depende de que no lo entienda!"Ya sea a través de terribles argumentaciones o engaño deliberado, las respuestas en esas discusiones normalmente tenían la forma de no-sequiturs: "El estándar es opcional; algo es mejor que nada; muchas personas estuvieron involucradas; lo perfecto es enemigo de lo bueno; estamos tratando de ayudar a todas aquellas pobres personas que no saben qué hacer ". Los promotores de los estándares deberían (y probablemente lo hacen) saber que esas declaraciones se aplicarían a cualquier modelo de proceso que cualquier persona o grupo podría ofrecer. La construcción de la autoridad falsa en la ISO, y luego apelar a la autoridad, se ve muy parecido a la búsqueda de rentas para mí.
Por otra parte, la deformación de creer que la norma ha sido objeto de desarrollo serio cuando algunos de los modelos básicos (por ejemplo, el modelo de la 29119 para el proceso de planificación de las pruebas) ha pasado esencialmente sin cambios durante cuatro años, un período que incluyó el auge de los smartphones y la tecnología móvil, las secuelas de la crisis financiera, y el surgimiento de la Tablet PC. Agile Testing, según se informa, granjea poco más que unas pocas referencias.
No puedo decir que estoy sorprendido de que el testing y checking no aparecen tampoco en el radar de la 29119.

P: Por qué no se opone mediante el proceso formal establecido por la ISO?

Como James Bach señala, la verdadera pregunta aquí es: ¿por qué el oficio tiene que defenderse de un proceso de estandarización que se creó para favorecer a determinados grupos bien financiados?
ISO es una organización comercial; no es un órgano de las Naciones Unidas, que emana de los gobiernos representativos electos; no es una institución académica; no es un grupo representativo de los profesionales; no esta ordenado por ninguna deidad. La responsabilidad recae sobre ISO para mostrar la relevancia del estándar, incluso en sus propios términos. Simon Morley deconstruye eso.

P: No sería bueno tener un lenguaje común internacional para las pruebas de software?

Gran idea! De hecho, sería bueno tener un lenguaje común internacional para todo. Y con el fin de ser verdaderamente internacional y representar a la mayoría de la gente en el mundo, vamos a hacer que ese idioma sea el mandarín, o el hindi.
Hay muchos argumentos para demostrar que un lenguaje común para las pruebas de software no es ni deseable ni posible. He escrito en mi blog acerca de algunos de ellos, y lo he hecho más de una vez.

P: Por qué estás siempre en contra de las cosas? ¿No quieres estar a favor de algo?

Uno no tiene que estar a favor de algo para estar en contra de algo que es odioso. Pero como cuestión de hecho, yo estoy a favor de algo que es más importante que cualquier estándar: la libertad y la responsabilidad de la calidad de mi trabajo (como espero que todos los testers estén a favor de la libertad y la responsabilidad por la calidad de su propio trabajo).
Esto incluye la responsabilidad de hacer mi trabajo capaz, creíble, abierto al escrutinio, y tan rentable como sea posible. Debo ser responsable ante mis clientes, a mi oficio, y para la sociedad en su conjunto. En mi opinión, estas responsabilidades no lo hacen y no deben incluir, el cumplimiento de unas normas preestablecidas, poco representativas, innecesarias, que consumen tiempo y creadas por documentación auto-proclamada y entusiastas de los proceso-modelo.
Algunas cosas por las que estoy a favor: las premisas del Rapid Software Testing y su framework; el estudio de las estructuras del Testing Exploratorio; el modelo de estrategia de testing basado en la heurística; un conjunto de compromisos para que los testers le hagan a sus clientes; la práctica de la habilidad  en el marco del testing; la excelencia en la presentación de informes; y una serie de otras cosas. Esto no es representativo de la amplia comunidad del Testing... así que apuesto a que te alegras de que el cumplimiento de los estándares establecidos por James y yo es voluntaria. De hecho, el cumplimiento de nuestros estándares requiere que invente las pruebas por sí mismo; a adoptar las normas que ayudan; y resistir a las que no lo hacen, incluido la nuestra. Pero si usted encuentra algo que funcione para usted, dígalo. Dígale a todo el mundo.

P: Qué pasa con las pobres personas que necesitan orientación sobre cómo testear?

Mis ofrendas (gratis)  a esa pobre gente incluyen lo mencionado arriba. Esa pobre gente puede hacer uso de estas sugerencias e investigar las alternativas que alguien más pueda ofrecerle. Eso puede ser más difícil que hacer referencia a un estándar ISO y apelando a su autoridad (Puede ser considerablemente más fácil, también) Pero mi primera pieza de orientación sobre la forma de testear es esta: aprenda acerca de las pruebas, y aprenda cómo testear, a través del estudio y la práctica. Yo sostengo que la ISO 29119 no le ayudará con eso.

Si te convenció Michael Bolton, puedes firmar la petición en contra de la ISO 29119 aquí

Por qué no sirve la ISO 29119 para el Software Testing - Parte 1

En las ultimas semanas ha ido creciendo la voz en contra de la ISO 29119, un standard de la ISO para el software testing que no va ayudar en nada.
Muchos autores han hablado al respecto y pueden encontrar todos los links al respecto en la página de la International Society for Software Testing (ISST)
Tambien pueden firmar la petición en contra de la ISO 29119 aquí (no se si sirve de mucho pero yo ya la firmé)
Pero que es la ISO 29119 exactamente? Por que están en contra? Bueno , el tema es largo y complejo, por eso prefiero traducir este FAQ realizado por Michael Bolton en su blog.
Espero que les sea útil. Si ven algún error de traducción, sepan disculpar. Lo dividí en 2 partes porque es muy largo.

Preguntas Más Frecuentes Acerca de la Controversia sobre la 29119:

Este es un primer intento de una lista de preguntas más frecuentes sobre el movimiento para detener la ISO 29119. Aquí hablo por mí mismo, y no para la comunidad. Si usted ve un "nosotros", se refiere a mi percepción de la comunidad en general, pero no necesariamente a toda la comunidad; el tamaño puede variar. Hay un montón de discusiones en la comunidad; Huib Schoots está curando una colección de recursos sobre la controversia. Si tienes una percepción diferente o una opinión diferente, por favor compártela y hágamelo saber. Mientras tanto, me apresuro a señalar que absolutamente todos son bienvenidos y alentados a compartir mis opiniones.

P: ¿Por qué molestarse con un ataque de la comunidad a la norma ISO 29119? No es relevante para la mayoría de los probadores? ¿Y por qué ahora?

Para empezar, creemos que la ISO 29119 no es pertinente a todos los Testers, en el sentido de que parece ser un sobre estructurado modelo de procesos, centrado en una implacable y pesada burocracia derrochadora y de papeleo, con un contenido insignificante sobre las pruebas reales. Si su organización está en el negocio de producir documentación inútil, que así sea, pero eso no es lo que llamamos Testing. Los enfoques sugeridos por 29119 podrían ser útiles para las personas que están más interesados en cuidarse el culo que en la cobertura de pruebas.

Los originadores y los partidarios de la petición están tratando de establecer un patrón de oposición a la norma. Esto es importante cuando los abogados o auditores preguntan "¿Por qué no sigues 'un conjunto internacionalmente acordado de normas para las pruebas de software que se pueden utilizar dentro de cualquier ciclo de vida de desarrollo de software u organización'?"
Grandes voces de la oposición -no sólo a la norma, sino también al proceso por el cual fue creada y por el cual se comercializará- ayudarán a demostrar que la sugerencia de "acuerdo internacional" no tiene sentido; que la norma tergiversa las pruebas como muchos testers prominentes lo ven; que la norma es excesivamente compleja y opaca; que es a la vez demasiado vaga aquí y demasiado específica allí para ser útil en "cualquier" organización; y que los contextos radicalmente diferentes para el testing -muy apropiadamente- requieren enfoques radicalmente diferentes para testear.

En cuanto a la pregunta "¿por qué ahora", hay otra razón por esta oleada que, creo, que estamos descubriendo a medida que avanzamos: en los últimos años, a trancas y barrancas, la comunidad de Testing guiado por el Contexto (NdT: Context-Driven testing, no tengo una buena traducción para esto, je.) se ha convertido en mucho más grande y más capaz de actuar como una comunidad. Y eso a pesar del hecho de que las personas que aspiran a ser  pensadores ferozmente independientes, pueden ser un grupo bastante rebelde.  Una comunidad que acoge serios desacuerdos tendrá serios desacuerdos, y ha habido algunos. Sin embargo, parece que, de vez en cuando, hay algunas cosas que son lo bastante odiosa para unirnos. Personalmente, estoy tratando esto como una prueba y una experiencia de aprendizaje para prepararnos para algo en serio importante.

P: Los promotores de la norma insisten en que no es obligatoria, así que ¿cuál es el alboroto?

The promoters of the standard who say that the standard is not mandatory are being disingenuous. They are well aware of this idea:
"Otro esquema de clasificación distingue entre los estandares voluntarios, que por sí mismos no implican obligaciones relacionadas con su utilización, y los estándares obligatorios. Una estandar obligatorio se publica generalmente como parte de un código, norma o reglamento por un organismo gubernamental regulador y establece la obligación de las partes especificadas a ajustarse a la misma. Sin embargo, la distinción entre estas dos categorías se puede perder cuando los estándares de consenso voluntario se referencian en las regulaciones gubernamentales, haciendolos efectivamente en estándares obligatorios ". (fuente)
Los promotores de la 29119 comienzan usando la apelación a la autoridad (en este caso, la reputación de la ISO) para declarar una estandar. Si se da la circunstancia de que un regulador o burócrata, mal informado acerca del Testing, pasa sobre "un conjunto internacionalmente acordado de normas para las pruebas de software que se pueden utilizar dentro de cualquier ciclo de vida de desarrollo de software u organización" y se refiere a ellos en las regulaciones del gobierno, bueno, entonces, tanto mejor para los aspirantes a buscadores de ganancias que podrían haber estado involucrados en la redacción de la norma.

P: Si la ISO 29119 es tan terrible, no va a desaparecer por su propio peso?

Sí, probablemente lo hará en la mayoría de los lugares. Pero durante un tiempo, algunas organizaciones (incluidas las públicas; tus  impuestos en acción, recuerda) _ coquetearán con ella a un gran costo-incluyendo los costos fácilmente previsibles de inncesario cumplimiento , desplazamiento de objetivos, la tergiversación de las pruebas, y otra ronda de comercialización de certificaciones falsas, por lo que los buscadores de rentas consiguen una oportunidad para recoger de los bolsillos de los ingenuos y los cínicos.

P: ¿No está sólo quejándose porque usted está preocupado de que su enfoque no-estándar del Testing le pondrá fuera del negocio?

Así es como yo respondí esta pregunta en un blog (con un par de ediciones menores por los errores tipográficos y claridad):
"En un sentido, no hará ninguna diferencia para mi negocio si 29119-1, 29119-2 y 29119-3 se quedan, y si 29119-4 y 29119-5 pasan de borrador a aceptarse. Rapid Software Testing es acerca de las habilidades reales de testing (exploración, experimentación, pensamiento crítico, pensamiento científico, de información articulado, y así sucesivamente). Eso no compite con la 29119, en la misma  manera que un restaurante de pescado no compite con las compañías que hacen que las conservas de atún. Nos oponemos a las personas que manipulan el mercado, y el proceso de desarrollo de las normas ISO de sugerir a todo el mundo que el atún enlatado es el único alimento apto para comer para la gente. Discuto eso aquí.
"En otro sentido, la 29119 podría ser fantástica para mi negocio. Me ofrecería una manera de extender la marca: cómo hacer testing excelente y rentable que resista al escrutinio en contextos en los que algún burócrata, muy lejos fuera del proyecto de desarrollo, se dejó engañar en la creencia de que la 29119 era importante. Por el momento, estoy feliz de referir ese tipo de negocio a colegas míos, pero sospecho que sería algo así como una mina de oro para mí. Sin embargo, todavía me opongo a la 29119, porque lo que está en mi interés puede no estar en los intereses de mis clientes y de la sociedad en general.
"Permítanme ser específico: Hay normas existentes para dispositivos médicos, para la aviónica, y similares. Estas normas son importantes, y muchos de ellos son concisos y están bien escritos, y fueron creados por una verdadera colaboración entre las partes interesadas. Testers que están trabajando en dispositivos médicos o en el software de aviación tienen un número limitado de minutos en la jornada de trabajo. Como alguien que vuela mucho, y como alguien que es probable que requiera la ayuda de dispositivos médicos en un futuro próximo, yo preferiría que los testers pasen tantos minutos como sea humanamente posible realmente investigando el software, en lugar de cumplir (auténticamente, patéticamente , o maliciosamente) una norma innecesaria para el modelado de procesos, documentación, y la estrategia (un estándar para el desarrollo de una estrategia, imagine eso!) ".

P: A usted simplemente no le gusta las normas. ¿No es verdad?

Pues no. Me encantan las normas cuando se usan apropiadamente.
Como he subrayado en una presentación de PNSQC en 2011, denominada "Estándares y desviaciones", es posible y a menudo deseable para describir y normalizar los widgets (cosas tangibles y físicas que tienen atributos cuantitativamente medibles), y que deben interactuar, relacionarse, o encajar con otras cosas. Gracias a Dios por tornillos estandarizados y los destornilladores, CDs y discos duros SATA! Bravo a la UE por ordenar que las fuentes de alimentación para Smartphones se estandarice a USB! Sin embargo, incluso con los widgets, hay cuestiones relacionadas con la tensión entre los estándares y un estado de avance de la técnica. Aquí está uno de los mejores artículos de la historia sobre problemas con los estándares.
Es más difícil describir los procesos, ya que la descripción es, por necesidad, un modelo del proceso. Es difícil para muchas personas evitar cosificar el modelo, es decir, evitar tratar al modelo, la idea, como si fuera una cosa. Para un ejemplo de sobrecosificación del Testing, tómese un momento para reflexionar sobre la noción de lo que representa el trabajo de pruebas en términos de casos de prueba; lea luego "Los Casos de prueba no son Testing: Hacia una Cultura de Test Performance" por James Bach & Aaron Hodder.
Más en general, el enfoque de la 29119 en los artefactos y el modelo de proceso
desplaza y descentra de la parte más importante de cualquier esfuerzo de pruebas: el conjunto de habilidades y la mentalidad del tester individual.

P: De verdad creen que la norma ISO 29119 puede ser detenida?

No, claro que no lo creemos. Curtis Stuehrenberg lo pone perfectamente en una discusión en LinkedIn: "La petición no se trata de detener la publicación más de lo que una marcha contra la guerra es acerca de una expectativa razonable de poner fin a una guerra a través de un desfile. El punto de la petición y la charla general es para asegurarse de que al menos algunas personas escuchan que hay una parte importante de la comunidad del Testing que no estuvo representada y que defienden diferentes puntos de vista y prácticas para las pruebas de software como una disciplina profesional ". Si no podemos conseguir detener el estándar por los mecanismos de la ISO, por lo menos podemos demostrar que hay una ausencia de consenso fuera de los grupos de trabajo de la 29119.