Bueno la verdad el tema de Control de Calidad del software no se lo ve mucho (sino es nada) en la Universidad. Pero en el mundo real los testers (QE) son parte importante del desarrollo para asegurar la calidad de un producto de software.
Ahora bien que tiene que ver un developer con un tester, pues mucho. La verdad que muchas veces tienes que sermuy bueno para detectar errores (especialmente los rebuscados), entonces para ser un buen developer, previamente deberias conocer muchas cosas de las que verifican los testers en tus programas, asi te adelantas y envias a control de calidad la menor cantidad de errores, de tal forma que se tenga un producto de mejor calidad.
Sin embargo ya lo deciamos con mi compañeros desde primer semestre, un software nunca va a terminarse, y siempre, pero siempre tiende a tener errores, nunca un developer puede ser perfecto. Algo que me llamo mucho la atención es lo que menciona Manfred Ratzmann, Clinton de Young [1] , en cuanto al proceso que debe seguir el control de calidad: planificacion de testeo, diseño, especificación, procesos, ejecucion, reportes, regresion y bueno ahi regresa al developer, o sea el ser un buen tester tampoco es tarea tan sencilla, aunque supongo que sigue siendo más sencilla que la de un developer, quizás cuando pruebe ser tester o alguien de automatización :).
Algunos puntos para las empresas que deben considerar para el control de calidad de sus propios productos, los desarrollados en la misma empresa:
1. Ese software no debe ser testeado dentro la misma empresa.
2. La comunicación entre análisis de negocio, developers y testeo es sumamente importante, de vida o muerte.
3. Un desarrollador no es el indicado para asegurar que su producto tiene calidad. (Asi de duro :) )
4. No se debe testear aquello que no ha sido implementado.
5. Donde se encontraron errores, es más probable que luego existan mas.
De donde saco el punto 4 que no parece tener sentido, como voy a probar algo que no ha sido implementado ?. Bueno esto puede suceder por la falta de comunicación, sucede en la vida real que, yo developer tengo un documento de especificación de requerimientos, analizo, diseño, implemento, y hago la entrega de mi programa a los de control de calidad. Sucede que cuando estoy haciendo la entrega a control de calidad, análisis de negocio me dice: "Bueno hace unos días surgieron cambios en los requerimientos aprobados por el cliente" (ese documento Control de Calidad ya lo tiene desde hace "algunos dias"). Entonces supondra que el programa que entregue contempla dichos cambios, entonces sucede que, control de calidad muy enojado dice "El programa no sirve" (critica nada constructiva), entonces todos se enojan y bueno .. se desencadena en un montón de situaciones (estoy exagerando un poco mi experiencia para mostrar las cosas que podrian pasar :) ).
Bueno espero les sirva un poquito todo esto que lo saque de un libro, la parte que comenta Manfred Ratzmann, Clinton de Young y el resto de mi experiencia :).
PD. Ahora entiendo porque muchos developers muchas veces tienen que pasar primero por control de calidad, aunque no sea una regla, lo puedo comprender mejor. Pero a veces hacemos las cosas al revés :( , pero bueno .. ahora estoy informándome y viviendo al respecto.
[1] : Software Testing and Internationalization: Manfred Ratzmann, Clinton de Young
Palabras clave: Control de calidad, developers, testers
Comentarios
Apoyo a Cristian: TDD es la clave. Sin embargo, no es test! Es especificacion!!!!! Entonces TDD no garantiza la ausencia de problemas.
Por otro lado: error solamente es una forma de deficiencia de un programa. Los hay muchos mas y un QE tiene que conocer todas las deficiencias posibles.
Microsoft piensa que todos son QEs. El software libre piensa que todos son programadores. El mundo esta loco.
Bueno TDD, da mayor fiabilidad a tus programas como developer (algo que tampoco se practica mucho en la U :(, aunque habian algunos docentes que ya estaban inculcando eso a sus alumnos ;), también auxiliares ).
Pero la habilidad de un QE es importante para una entrega final, puede que un desarrollador no vea muchas cosas que un QE puede ver, para eso pienso que es importante poder ver un tanto de ese mundo.
Dr Pablo, muy buena su apreciación, sobre el mundo
Hola Marcelo, control de calidad para mi en el mundo del software es:
1. Asegurarse que el producto cumpla con las expectativas del cliente (los requerimientos) ... definicion tradicional
2. Asegurarse que el software cumpla con las caracteristicas que DEBE tener un sistema, errores inesperados que pueden suceder a momento de ponerlo en marcha, cosas que como sistematicos/informáticos conocemos mejor que un usuario final.
Luego puede que un "tester " pruebe el programa en bae a algo establecido por el cliente, en realidad lo que se hace es un check list, donde se tiene todo lo que se debe probar para asegurar la calidad del producto, donde se pueden incluir caracteristicas que todo sistema debe tener en cuanto a su funcionamiento, cosas que van relacionadas a lo que menciono en el punto 2.
Mis comentarios sobre algunos de tus puntos:
"1. Ese software no debe ser testeado dentro la misma empresa."
No estoy de acuerdo con eso... aunque no nos guste, el software de Microsoft tiene muuy gran calidad y todo el proceso de QA se hace dentro de la misma empresa. Es mucho más fácil y una experiencia mucho más "rica" si los testers y los programadores están en contacto muchísimo más directo. Muchas veces se toma a los equipos de QA como enemigos de los equipos de desarrollo, cuando lo cierto es que ambos apuntan hacia lo mismo: Que el producto salga con un alto nivel de calidad... (no creo que hayan programadores que quieran que su software se tire en producción cada 5 minutos)....
"2. La comunicación entre análisis de negocio, developers y testeo es sumamente importante, de vida o muerte."
Si el software es grande, el análisis de negocio tendría que estar desprendido del proceso de creación del software (que incluye desarrollo y testeo).
"3. Un desarrollador no es el indicado para asegurar que su producto tiene calidad. (Asi de duro :) )"
Eso depende de muchos factores...
1. el primordial... del programador... es casi seguro que la calidad del software creador por un programador capo y con experiencia es bastante superior a la calidad del software creado por un programador sin experiencia o por uno no muy capo.
2. si el programador hace pruebas de unidad, su producto tiene mucha más calidad que si no las hace.
3. si se ha usado un enfoque orientado al testeo (TDD), entonces la calidad del software es aún mayor.
Ernesto:
Por ejemplo:
Antes de discrepar me gustaria entender tus criterios. Hay muchas cosas diferentes en la misma bolsa, al parecer tratadas todas desde una misma perspectiva.
Pablo, creo que tienes razón, estoy usando "calidad" en montón de contextos diferentes.... pero a ver:
Mi "disclaimer" primero: No soy un "Microsiervo" [uso Gentoo en mi casa aunque trabajo programando sobre windows] y mi comentario aquí no es nada político sobre MS.
"1. ... el software de Microsoft tiene muuy gran calidad ..."
La verdad es que si bien Windows 95 era bien conocido por las famosas "pantallas azules de la muerte", desde que el kernel del Windows "hogareño" está basado en el de Windows NT, la estabilidad del sistema operativo es increíble... hay montón de aplicaciones que se cuelgan [en userland, obviamente], pero que con su "muerte" no afectan al sistema operativo... y tener esos altos niveles de estabilidad es sinónimo de calidad. Otro ejemplo es la Win32 API; aunque es bastante feita también es una muestra de calidad por su "backward compatibility" (lograr eso en C ó C++ no es tarea fácil y peor viendo el tamaño de dicha API) y por el número bajo de bugs que tiene (de nuevo, dada la complejidad y tamaño de dicha API).
El diseño de la API del .NET Framework [aunque está basado fuertemente en la API de Java] es igual bueno. C# y el CLR corrigen muchos problemas de diseño que Java tiene...
3. ... calidad del software creado por un programador muy capo ....
generalmente un programador muy capo:
a) DISEÑA sus cosas de una forma mucho más elegante
b) Programa con muuuuuchos menos bugs
c) Su código es mucho más limpio y legible
d) Piensa a futuro
e) Piensa en muchas condiciones extremas y las controla adecuadamente.
... todo eso es calidad.
... programador que hace pruebas de unidad su producto tiene mucha mas calidad ...
1. Si el programador hizo pruebas de unidad, quiere decir que pensó también en un conjunto de condiciones que es muy probable que no las hubiera pensado si sólo hubiera escrito sus métodos/clases para que funcionen.
2. Obvio, supongo que el programador ejecutó sus pruebas de unidad y no "commiteó" su código hasta que todas sus pruebas se hubieran ejecutado exitosamente.
3. Si los métodos se comportan como el programador espera que se comporten, el número de bugs debido a condiciones no pensadas disminuye drásticamente (incrementando la calidad del producto).
... enfoque orientado al testeo (TDD) ... calidad mucho mayor ...
Lo mismo que el punto anterior... si el programador ve las condiciones extremas y piensa casos de prueba antes de pensar en el código verdadero, entonces el producto final cubrirá muchos más "escenarios" que recién serían vistos por los equipos de QA ó, en el peor de los casos, por los clientes.
Supongo que calidad incluye montón de cosas, algunas pueden ser validadas por los equipos de QA: interfaz de usuario fácil de usar, consistente, etc...; número de bugs pequeño; consistencia en el funcionamiento; recuperación ante fallos; funcionamiento correcto dadas condiciones límite, no "memory leaks", etc.
Pero hay asuntos que un equipo de QA no puede ver y que yo también tomaría como calidad: elegancia del código, "code guidelines compliance", diseño elegante, extensibilidad, soporte de backward compatibility en APIs y ABIs, etc.
Ernesto, todo lo que mencionas es cierto, pero no estoy del todo de acuerdo, de lo que yo hablo es de mejorar la calidad, estoy seguro que ningún programador, por más capo que sea (no se a que le llamas capo, para mi es otra percepción) nunca va a poder asegurar que todo este funcionando bien, nadie es perfecto, y siempre tendremos fallas, cuantas veces nos tropezamos al caninar, a pesar de que ya caminamos por muchos años, siempre tropezamos, no es porque queramos, sino son fallas sin querer (por supuesto), por eso se llaman bugs, errores ... lo que se quiere es buscar mecanismos con los cuales un "buen" programador pueda mejorar la calidad de sus productos, por supuesto que un buen programador hace lo que dices:
a) DISEÑA sus cosas de una forma mucho más elegante
b) Programa con muuuuuchos menos bugs
c) Su código es mucho más limpio y legible
d) Piensa a futuro
e) Piensa en muchas condiciones extremas y las controla adecuadamente.
Hoy en día no cualquiera se puede dar el lujo de hacer un buen diseño, y por supuesto programar con bugs por todo lado ..mmm .. eso para mi ya no es un buen programador, codigo limpio, es lo primero para un programador, a futuro .. eso va en el diseño, lo de controlar y condiciones extremas, son más cualidades de experiencia :) .. ahora un programamod CAPO ... es pues eso .. un capo ;), es otra mi percepción de un capo :) ... pero ese no es el objetivo del post.
Cómo es Wilfredo...
Noo, ¡¡si de bugs yo soy la persona que más te puedo hablar de cómo escribirlos!! :) sobre lo de "capo"... conozco a caaaapos y conozco a rajoooooooones... y aunque los que se rajan siempre alcanzan buenísimos resultados (por algo se rajan), los capos... no sé, hacen 2 ó 3 cosas supersimples.... y ya está... elegante, extensible, con pocos bugs (tienes toda la razón, CERO BUGS no existe), bien hechito, etc. etc....
Software Quality Assurance es mucho mas que solo testear, me parece que muchos en el medio pensamos que uno entra de QE y se acaba el mundo ahi y solo podemos ser SQTesters :).
Una tarea muy esencial es la de encontrar fallas en todo lo que engloba el proceso de desarrollo, en todas las etapas, en distintos noveles. Por ejemplo en el solo echo de no tener una deficion clara de algo puede causar que un dev desarrolle lo que piensa, el QE no lo da por valido por que el piensa que esa palabra significa otra cosa, y asi podria ser mucho mas servero.
Tambien reportar bugs de inconsistencia de diseño es muy interesante, y en elo el ad-hoc cuando uno lo aprovecha y ademas conoce a fondo el sistema puede llegar a detectar fallas que ni los arquitectos los hallarian facilmente.