domingo, 21 de febrero de 2016
domingo, 7 de febrero de 2016
Código deontológico
La participación en las pruebas de
software permite a las personas obtener información confidencial y privilegiada
Un código de ética es necesario,
entre otras razones para asegurar que la información no sea objeto de un uso
inapropiado.
Reconociendo el código de ética para
ingenieros de software de la ACM (Association for Computing Machinery) y del
IEEE (Institute of Electrical and Electronics Engineers), el ISTQB
(International Software Testing Qualifications Board) establece el siguiente
código de ética:
- Público
Los probadores de software certificados actuarán en coherencia con el interés público.
- Cliente y Empleador
- Producto
- Criterio
- Gestión
- Profesión
- Compañeros
Los probadores de software certificados serán equitativos y apoyarán a sus compañeros fomentando la cooperación con los desarrolladores de software.
- Nivel Individual
Webgrafia:
http://formacionticweb.blogspot.com.co/2013/03/codigo-de-etica-del-istqb-istqb-code-of.html
Psicología en el proceso de Pruebas
El éxito de las pruebas está
influenciado por factores psicológicos, es importante tener objetivos claros,
un balance entre testear uno mismo y las pruebas las realice alguien
independiente, tener buenos canales de comunicación.
La
persepción durante el ciclo de desarrollo del software es que el desarrollador
construye y el tester destruye, pero ambas actividades son constructivas, ya
que si bien llevan a cabo distintos caminos, al final, ambos buscan lograr la
calidad del software.
La relación entre el desarrollador y
tester normalmente no es una tarea fácil debido a que:
- Los Tester suelen señalar los problemas con el software. Son considerados siempre como portadores malas noticias. Los fallos durante las pruebas pueden ser percibidos como una crítica contra el producto y en contra del autor.
- Los desarrolladores tienden a pensar que su código es impecable. Hay un afecto emocional donde los desarrolladores no quieren encontrar defectos.
- Los testers son percibidos como los culpables de retrasar el proyecto buscando fallas en el sistema.
Por esto tenemos que aprender a
lidiar con los defectos de forma constructiva:
- Aceptar y esperar errores / defectos
- Los errores son naturales – hagamos un plan para ellos
- Centrarse en el problema a resolver – no en la búsqueda de los culpables
- Aprender de los errores / defectos
Para poder trabajar de la mejor
manera como equipo los resultados se deben comunicar de manera objetiva, no
subjetiva. Si hay errores, defectos o fallos se comunican de una manera
constructiva, los malos sentimientos entre los testers y los analistas,
diseñadores y desarrolladores se pueden evitar. Por lo general, el caso es
que alguien se molesta con la otra persona, especialmente cuando están bajo presión
de tiempo.
https://josepablosarco.wordpress.com/2011/09/28/istqb-cap-1-fundamentos-del-testing-ii/
Los siete principios generales del proceso de pruebas de software
- Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos
Probar reduce la probabilidad de que
existan bugs pero nunca se puede asegurar que no quede ninguno oculto.
Además, cada tipo de pruebas que
realicemos (de sistema, de integración, añadir auditorías de código…) son más
efectivas para detectar un tipo de bug.
- Principio 2: Es imposible probarlo todo
El flujo de control de un sistema
software no trivial como los que acostumbramos a utilizar en el día a día
contiene miles de decisiones. Estas decisiones se pueden combinar entre ellas
para dar lugar a una infinidad de posibles caminos. De entrada, probar todos
los caminos es un problema inabordable.
Y eso si no tenemos en cuenta la
prueba de requisitos no funcionales, como el rendimiento de un sistema ante una
exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo,
en un sistema bancario) para protegerse de usuarios malintencionados.
Todo esto hace necesaria una
estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos
de calidad y de proyecto.
- Principio 3: Cuanto antes se comience a probar…mejor
Corregir un bug con una revisión en
la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho
menor a lo que costará corregir este bug cuando se detecte en una prueba de
sistema, o peor aún, en una prueba de aceptación por el cliente.
En demasiadas ocasiones existe una
confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando
existe) se reduce a estas. Se confía en que todos los componentes que no se
probaron con una estrategia de pruebas unitarias y de integración se puedan
entender bien a unos días del hito de entrega (cuando corregir un bug ya es
demasiado caro, en lo que se denomina una prueba de integración “big-bang”).
Curiosamente estas malas prácticas se
realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las
tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos (con
caídas de la productividad del 50% según Capers Jones).
- Principio 4: Las aglomeración de defectos. ¡Los bugs siempre van en conjunto!
Entender esto es muy importante para
plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se
concentran en determinados puntos de un sistema software, no manteniendo una
distribución uniforme a lo largo del mismo.
Conclusión: si se encuentra un bug en
un componente, es muy probable que haya más. Con lo que una posible estrategia
sería centrarse en mejorar las pruebas de aquellos componentes para los que se
han reportado un número mayor de bugs, para ser más eficaces a la hora de
cazarlos en fases tempranas.
- Principio 5: La paradoja del pesticida
La necesidad de ajustar continuamente
el plan de pruebas… porque según este principio un plan de pruebas va perdiendo
efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a
encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el
primer principio). Se habla de paradoja del pesticida ya que estos matabichos
usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del
tipo específico que mata el pesticida… ¡nadie dice que no hayan otros bichos
campando a sus anchas!
- Principio 6: Las pruebas se deben adaptar a necesidades específicas
Esto viene a enlazar con lo que he
comentado antes. Si el producto se centra en el ámbito de la seguridad se deberán
adaptar los casos de prueba para intentar forzar situaciones o posibles
escenarios no amistosos. Si se quiere probar una intranet donde los servicios
más vitales son los de imputación de horas y el de vacaciones, es lógico
centrarse en estos servicios y no invertir tiempo en otros componentes
infrautilizados. Además, hay que tener
en cuenta que los recursos en los proyectos son siempre escasos, con lo que en
el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para
encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor
valor para nuestros usuarios.
- Principio 7: La falacia de la ausencia de errores
Para terminar, nos encontramos con la
satisfacción del usuario y con el hecho de que los usuarios elijan tu software
para resolver sus necesidades. Que se hayan corregido muchos bugs no significa
que finalmente el software sea un éxito. En ocasiones hay que primar un buen
time to market, para luego corregir los problemas de calidad que quedaron por
el camino. Y esto si se hace de manera consciente y con una buena estrategia, a
priori, no debe ser un problema.
Suscribirse a:
Entradas (Atom)