Por todos es sabido que todo proyecto tiene un ciclo de vida, desde la iniciativa, hasta su cierre. Lo que no necesariamente se sabe es que para los evaluadores de este proyecto, uno de los temas estratégicos a considerar es el enfoque de las pruebas. Debe haber al menos cuatro enfoques:
a) Al inicio del proyecto, evaluaciones amistozas, se debe respetar que la criatura está en crecimiento y que pueden haber muchas omisiones o fallos
b) En la mitad del proyecto, las evaluaciones deben ser agresivas, es allí en donde debe dar peso a la evaluación a efecto de que el equipo a cargo tenga tiempo y posibilidades de enmendar.
c) Cerca del final las pruebas deben ser diversificadas, es decir con varias herramientas, varios enfoques, etc a efecto de verificar que se está listo para la liberación
d) Al final las pruebas deben ser meticulosas, es decir, es aqui en donde se debe concentrar en los detalles finales que son los que harán que el producto se diferencie.
En general la combinación de estas estrategias es mucho mejor que planear un único plan de pruebas, sin tener claro el enfoque.
jueves, 31 de marzo de 2011
lunes, 28 de marzo de 2011
El mal de "oir" y el "pero"
Yo creo que por todos es conocido que hay una significativamente diferencia entre oir y escuchar, lo ideal es obviamente escuchar, pero encuentro que aún hay un mal peor: oir y ya tener el pero en la mente. A veces los seres humanos con solo unas pequeñas palabras que se nos dicen, articulamos ya una posición ante la primera persepción sin haber tomado tiempo de razonar, para tener ya el pero listo, esperando unicamente que el interlocutor termine de hablar.
Ojala y todos aprendieramos a escuchar, y si nos da por oir, al menos debemos de evitar tener el pero en la mente.
Ojala y todos aprendieramos a escuchar, y si nos da por oir, al menos debemos de evitar tener el pero en la mente.
Documentación en exceso.
Gracias al curso de pruebas de software, ahora veo las cosas un poco menos confusas de lo que antes estaban. Soy un fiel creyente de los sistemas de calidad y de los estándares. Reconozco que lo que no está documentado es muy difícil de mejorar, pero de allí a tratar de implementar los más altos estandares documentales en una organización, que tal vez no los necesita del todo, es un acto irresponsable si se obliga a hacer, sin econtrarle ningún valor agregado.
Lo primero que debe hacerse es un costo beneficio a la documentación que cualquier sistema de aseguramiento de la calidad requiere. Estoy seguro que ningún auditor inteligente se deja llevar por volumen. Lo que realmente les preocupa a los auditores es qué se haga y se validen los productos a entregar, con algún criterio previamente establecido y verificable.
Mucho documento más bien refleja que hay mucho ocio y que se dedicó más tiempo a escribir que ha hacer lo que esta escrito. Como dijo el jefe, nuestro sistema esta gordo de documentos y hay que ponerlo a dieta. El tener documentos sucintos refleja que se tiene claro el norte y que se ha alacanzado algún nivel de execelencia documental.
Lo primero que debe hacerse es un costo beneficio a la documentación que cualquier sistema de aseguramiento de la calidad requiere. Estoy seguro que ningún auditor inteligente se deja llevar por volumen. Lo que realmente les preocupa a los auditores es qué se haga y se validen los productos a entregar, con algún criterio previamente establecido y verificable.
Mucho documento más bien refleja que hay mucho ocio y que se dedicó más tiempo a escribir que ha hacer lo que esta escrito. Como dijo el jefe, nuestro sistema esta gordo de documentos y hay que ponerlo a dieta. El tener documentos sucintos refleja que se tiene claro el norte y que se ha alacanzado algún nivel de execelencia documental.
domingo, 27 de marzo de 2011
Diario de aprendizaje: un primer balance
Si bien es cierto como proyecto este blog representa realmente mi diario de aprendizaje, es bueno consignar en él primer balance a unos días de su confección.
En primer lugar debe dejarse claro que lo que realmente te puede ayudar a aprender, como ya lo dije desde las primeras entradas, es estar expuesto y esto en mi caso es posible por medio de la lectura. Por suerte he estado teniendo acceso a bueno autores que por medio de sus ideas me han ayudado a interiorizar las mias.
En segundo lugar el esfuezo de redactar unos cuantos párrafos es realmente una ayuda para la mente, aparate de fortalecer las competencias de comunicación escrita, es relevante porque fuerza a la mente a coordinar ideas y expresión.
Lo tercero y más importante es tener la capacidad de discrepar, aunque hasta ahora no he tenido mucho que aportar en este punto, el poder elegir dentro de todas las posibilidades y defenderlas teniendo que enfrentar mentes brillantes para poder alcanzar acuerdos es algo a lo que todos deberiamos estar más expuestos.
En primer lugar debe dejarse claro que lo que realmente te puede ayudar a aprender, como ya lo dije desde las primeras entradas, es estar expuesto y esto en mi caso es posible por medio de la lectura. Por suerte he estado teniendo acceso a bueno autores que por medio de sus ideas me han ayudado a interiorizar las mias.
En segundo lugar el esfuezo de redactar unos cuantos párrafos es realmente una ayuda para la mente, aparate de fortalecer las competencias de comunicación escrita, es relevante porque fuerza a la mente a coordinar ideas y expresión.
Lo tercero y más importante es tener la capacidad de discrepar, aunque hasta ahora no he tenido mucho que aportar en este punto, el poder elegir dentro de todas las posibilidades y defenderlas teniendo que enfrentar mentes brillantes para poder alcanzar acuerdos es algo a lo que todos deberiamos estar más expuestos.
martes, 22 de marzo de 2011
Probar un software vs revisarlo
Conforme el investigador va cambiando su fuente de información de google o wikipedia a documentos más especializados, éste se va dando cuenta que los detalles comienzan por hacerse cada vez más relevantes. Tomemos un ejemplo. Pídale a una persona que pruebe algo y luego dígale que lo revise. Observe bien. ¿Hizo algo diferente? Mi intuición me indica que en la mayoría de los casos no hay mayor diferencia en lo que se haga en una u otra solicitud. Sin embargo a nivel formal hay un mundo de diferencia entre ambas definiciones, y aún las hay más cuando se asocian a un tema de software.
Leyendo el libro de Lewis (Software testing and continuous quality improvement) encuentro la reveladora aclaración de que "probar" es una acción que busca encontrar errores, mientas que "revisar" lo que pretende es verificar la calidad asociada a los estándares del producto. Pese a que la persona del ejemplo del párrafo anterior haya hecho prácticamente lo mismo, nótese como en el software los resultados esperados cumplen objetivos no semejantes.
Por supuesto que ambas acciones guardan varias similitudes. Buscan mejorar el software, reducen las futuras complicaciones y costos reputacionales y económicos de no aplicarse, siguen metodologías de diagnóstico equiparables, pero en última instancia su objetivo es diferente.
Si partimos de los modelos de desarrollo estándares, en donde primero surge un levantamiento de requerimientos, luego viene un diseño lógico de la aplicación, luego un diseño físico que da lugar a una programación y finalmente a un código utilizable, cada una de estás etapas tiene asociado un tipo particular de pruebas: pruebas de aceptación, pruebas de sistema, pruebas de integración y en un inicio pruebas unitarias. Lo que Lewis plantea es que cada etapa del desarrollo debe tener su correspondiente prueba, de manera que no se pueda pasar a la siguiente etapa con errores.
Por su parte la parte de la revisión puede que ni siquiera llegue a ejecutar el programa. Se concentra más bien en verificar los estándares seguidos por las partes involucradas en el desarrollo, pudiendo hacerse formal o informalmente. Las revisiones surgen para complementar las pruebas. Es importante notar que establecer que un software tiene errores puede ser una tarea titánica e infinita, con lo cual revisar las prácticas seguidas puede ser una forma operativamente más sencilla de garantizar que las condiciones para que el producto final salga bien se hayan dado.
Como pueden notar ambas, pruebas y revisiones, son necesarias y pueden hacerse en simultáneo. Lo relevante y lo que persigo con esta publicación es que entendamos, cuando alguien nos requiera una de ellas en particular, saber diferenciar lo que se nos ha pedido y no pecar de manejar un vocabulario tecnológico light.
Leyendo el libro de Lewis (Software testing and continuous quality improvement) encuentro la reveladora aclaración de que "probar" es una acción que busca encontrar errores, mientas que "revisar" lo que pretende es verificar la calidad asociada a los estándares del producto. Pese a que la persona del ejemplo del párrafo anterior haya hecho prácticamente lo mismo, nótese como en el software los resultados esperados cumplen objetivos no semejantes.
Por supuesto que ambas acciones guardan varias similitudes. Buscan mejorar el software, reducen las futuras complicaciones y costos reputacionales y económicos de no aplicarse, siguen metodologías de diagnóstico equiparables, pero en última instancia su objetivo es diferente.
Si partimos de los modelos de desarrollo estándares, en donde primero surge un levantamiento de requerimientos, luego viene un diseño lógico de la aplicación, luego un diseño físico que da lugar a una programación y finalmente a un código utilizable, cada una de estás etapas tiene asociado un tipo particular de pruebas: pruebas de aceptación, pruebas de sistema, pruebas de integración y en un inicio pruebas unitarias. Lo que Lewis plantea es que cada etapa del desarrollo debe tener su correspondiente prueba, de manera que no se pueda pasar a la siguiente etapa con errores.
Por su parte la parte de la revisión puede que ni siquiera llegue a ejecutar el programa. Se concentra más bien en verificar los estándares seguidos por las partes involucradas en el desarrollo, pudiendo hacerse formal o informalmente. Las revisiones surgen para complementar las pruebas. Es importante notar que establecer que un software tiene errores puede ser una tarea titánica e infinita, con lo cual revisar las prácticas seguidas puede ser una forma operativamente más sencilla de garantizar que las condiciones para que el producto final salga bien se hayan dado.
Como pueden notar ambas, pruebas y revisiones, son necesarias y pueden hacerse en simultáneo. Lo relevante y lo que persigo con esta publicación es que entendamos, cuando alguien nos requiera una de ellas en particular, saber diferenciar lo que se nos ha pedido y no pecar de manejar un vocabulario tecnológico light.
domingo, 20 de marzo de 2011
Segunda genereración de la gestión de conocimiento
Todo parece indicar que ha habido dos etapas o generaciones de la gestión del conocimiento, la primera ligada a la ya famosa frase de Albin Tofel "el dueño de la información es el dueño del poder", en donde las empresas y organizaciones centraron sus recursos en almacenar la información. Estos mega repositorios, caros y difíciles de mantener ordenados, pasaron a dar lugar a la inteligencia de negocio, que es la que da pie a la segunda generación de la gestión del conocimiento en donde se reconoce que es más bien el nuevo conocimiento que surja, a partir de los datos almacenados lo que dará lugar a la verdadera generación de valor agregado de las organizaciones a partir del reconocimiento de conocimiento como un activo estrátegico.
Esta segunda generación tiene un difícil reto por delante, descubrir cómo se genera información a partir de los datos. No creo que sea con una orden de las autoridades que le diga a los empleados inicien la generación del conocimiento y éste como si fuera una linea de producción al final de unos ciclos de operación empezará a surgir. Por el contrario encuentro tendencias que más bien buscan crear las condiciones para que el conocimiento surja, cuando, no se sabe, pero al menos se potencia.
La primera condición que encuentro que se utiliza para potenciar el conocimiento es reconocer que deben existir espacios para las criticas, es decir, se partir de la sabia idea de que lo que tenemos por conocimiento dado, puede que no esté del todo bien. Se recurre a la critica, la cual a veces es más sencilla que la creación nueva es el motor de revisión de lo que se cree es el stock de conocimiento de las organizaciones.
La segunda condición tiene que ver con identificar a que tipo de conocimiento se le debe prestar atención. Existen muchas disciplinas a las cuales darles recursos para el desarrollo, pero es un hecho que no ha todas es una buena decisión dársela. Debe por lo tanto existir un proceso de selección de las jefaturas que dirijan los esfuerzos creativos de nuevo conocimiento, declarando expresamente cuales son las líneas a las cuales es de interés de la organización que se documenten e inicie su proceso de mejora.
La tercera condición tiene que ver con fortalecer la demanda de nuevo conocimiento. Los puntos anteriores buscaban fortalecer la oferta. Por el lado de las necesidades es necesario crear los incentivos necesarias y la flexibilidad para que todo lo nuevo que se vaya generando empiece a ser aprovechado cuanto antes. De la valoración de los que lo utilizan, los creados obtendrán la primera y más importante remuneración, el recocimiento.
La cuarta condición necesaria tiene que ver con los repositorios de conocimiento, portales de conocimiento o como se les quiera llamar. Existen dos tipos de conocimiento, el tácito y el explícito, y para las empresas el mejor es segundo pues permite su fácil transmisión y revisión. Estable un piso sobre el cual es difícil descender y en teoría solo mejoras pueden existir.
La segunda generación de que estamos hablando trae consigo una distinción entre tres tipos de conocimiento según su fuente. Hay un conocimiento individual, uno colectivo y uno organizacional. en buena teoría el conocimiento trae sinergias, es decir el conocimiento de uno individualmente más otro más es mayor al individual de las partes debido a que la revisión conjunta mejora el de cada uno individualmente. A su vez el conocimiento colectivo, por ejemplo de un departamento dentro de una empresa puede entrar en relación con el de otras partes y de igual forma autoperfeccionarse y darle un mayor valor agregado.
El reto en este punto es crear los canales de comunicación entre las partes y crear la madurez para un proceso de mejora colectiva que de pie a crear las bases de un crecimiento sostenible de la innovación en la organización.
Quien dice que en estos días no estoy aprendiendo :)
Esta segunda generación tiene un difícil reto por delante, descubrir cómo se genera información a partir de los datos. No creo que sea con una orden de las autoridades que le diga a los empleados inicien la generación del conocimiento y éste como si fuera una linea de producción al final de unos ciclos de operación empezará a surgir. Por el contrario encuentro tendencias que más bien buscan crear las condiciones para que el conocimiento surja, cuando, no se sabe, pero al menos se potencia.
La primera condición que encuentro que se utiliza para potenciar el conocimiento es reconocer que deben existir espacios para las criticas, es decir, se partir de la sabia idea de que lo que tenemos por conocimiento dado, puede que no esté del todo bien. Se recurre a la critica, la cual a veces es más sencilla que la creación nueva es el motor de revisión de lo que se cree es el stock de conocimiento de las organizaciones.
La segunda condición tiene que ver con identificar a que tipo de conocimiento se le debe prestar atención. Existen muchas disciplinas a las cuales darles recursos para el desarrollo, pero es un hecho que no ha todas es una buena decisión dársela. Debe por lo tanto existir un proceso de selección de las jefaturas que dirijan los esfuerzos creativos de nuevo conocimiento, declarando expresamente cuales son las líneas a las cuales es de interés de la organización que se documenten e inicie su proceso de mejora.
La tercera condición tiene que ver con fortalecer la demanda de nuevo conocimiento. Los puntos anteriores buscaban fortalecer la oferta. Por el lado de las necesidades es necesario crear los incentivos necesarias y la flexibilidad para que todo lo nuevo que se vaya generando empiece a ser aprovechado cuanto antes. De la valoración de los que lo utilizan, los creados obtendrán la primera y más importante remuneración, el recocimiento.
La cuarta condición necesaria tiene que ver con los repositorios de conocimiento, portales de conocimiento o como se les quiera llamar. Existen dos tipos de conocimiento, el tácito y el explícito, y para las empresas el mejor es segundo pues permite su fácil transmisión y revisión. Estable un piso sobre el cual es difícil descender y en teoría solo mejoras pueden existir.
La segunda generación de que estamos hablando trae consigo una distinción entre tres tipos de conocimiento según su fuente. Hay un conocimiento individual, uno colectivo y uno organizacional. en buena teoría el conocimiento trae sinergias, es decir el conocimiento de uno individualmente más otro más es mayor al individual de las partes debido a que la revisión conjunta mejora el de cada uno individualmente. A su vez el conocimiento colectivo, por ejemplo de un departamento dentro de una empresa puede entrar en relación con el de otras partes y de igual forma autoperfeccionarse y darle un mayor valor agregado.
El reto en este punto es crear los canales de comunicación entre las partes y crear la madurez para un proceso de mejora colectiva que de pie a crear las bases de un crecimiento sostenible de la innovación en la organización.
Quien dice que en estos días no estoy aprendiendo :)
Tips para el uso de latex
Guía de memoria para incluir cosas en latex, de las que uso frecuente:
Paquete para poner link en internet: \usepackage{url}
Paquete para cambiar el interlineado: \usepackage{setspace}
Por ejemplo \begin{onehalfspace}...\end {onehalfspace}
Paquete para poner imagenes: \usepackage{graphicx}
Cambiar de ingles a español la palabra Figura: \renewcommand\figurename{Figura}
Cambiar de ingles a español la palabra Referencias: \renewcommand\refname{Referencias}
Por ejemplo
\begin{thebibliography}{99}
\bibitem{Autor} XXX
\end {thebibliography}
Paquete para poner link en internet: \usepackage{url}
Paquete para cambiar el interlineado: \usepackage{setspace}
Por ejemplo \begin{onehalfspace}...\end {onehalfspace}
Paquete para poner imagenes: \usepackage{graphicx}
Cambiar de ingles a español la palabra Figura: \renewcommand\figurename{Figura}
Cambiar de ingles a español la palabra Referencias: \renewcommand\refname{Referencias}
Por ejemplo
\begin{thebibliography}{99}
\bibitem{Autor} XXX
\end {thebibliography}
Responder lo que se pregunta!!!
Esta semana tuve una comprobación de lectura que me dejó la difícil de superar nota de un 6 de 10. La retroalimentación dada por el docente fue clara, la razón de mi bajo desempeño (menos que aceptable) fue "Tu respuesta no responde de forma explícita a lo que se pedía". Esta lección aprendida la quiero extrapolar a lo que debe esperarse en todo momento de un ser racional: estar focus en lo que uno se está haciendo, no dejar que tus ideas te distraigan.
Mi intención no es justificar, es más bien auto hacerme la pregunta de cúantas veces por dejar seguir la mente con una idea, se pierde la capacidad de seguir la conversación o de prestar atención a lo que se esta haciendo. Me es normal leer párrafos, y al darme cuenta no recordar lo leído. La razón, cuando una frase de las leídas me captó, la mente inmersa en el deseo de razonar se vuela y no hay nadie que la detenga.
La única solución que se me ocurre es leer con más detenimiento lo que se le está pidiendo, usar las energías mentales para razonar, usando argumentos de lógica (premisas, conclusiones, inferencia, etc), en las cuales en el pasado no lo he hecho tan mal.
A está focus con lo que viene....
Mi intención no es justificar, es más bien auto hacerme la pregunta de cúantas veces por dejar seguir la mente con una idea, se pierde la capacidad de seguir la conversación o de prestar atención a lo que se esta haciendo. Me es normal leer párrafos, y al darme cuenta no recordar lo leído. La razón, cuando una frase de las leídas me captó, la mente inmersa en el deseo de razonar se vuela y no hay nadie que la detenga.
La única solución que se me ocurre es leer con más detenimiento lo que se le está pidiendo, usar las energías mentales para razonar, usando argumentos de lógica (premisas, conclusiones, inferencia, etc), en las cuales en el pasado no lo he hecho tan mal.
A está focus con lo que viene....
miércoles, 16 de marzo de 2011
El arte de probar el software
Siguiendo con el mismo patín de la entrada anterior, Glenford J. Myers en su libro sobre el arte de probar el software, desarrolla en su capítulo 2 una interesante guía o marco conceptual, por medio del cual entender en que consiste la responsabilidad de emitir criterio sobre una determinada aplicación.
En primer lugar el autor nos señala que puede existir un enfoque equivocado al definir qué es un test, es decir un pecado de origen. Si le pidiéramos al evaluador que "demostrará que no hay errores presentes" obtendríamos un resultado significativamente diferente de si pedimos "que encuentren todos los errores que pueda". Varias son las razones para esta diferencia. Primero, tomemos como ejemplo un enfermo que va a un Laboratorio, si el análisis indica que no hay nada mal en la persona, pero esta se siente mal, la prueba habrá sido un fracaso. El plantear como objetivo buscar que algo esté bien, no presenta oportunidades de mejora a las cuales aprovechar, es decir al paciente le interesa que le encuentren algo que lo guíe para sentirme mejor. La segunda razón por la cual la definición es importante es porque demostrar que algo está bien puede ser una tarea titánica de nunca acabar, con lo cual el costo de encontrar el error adicional puede ser tal que haga que la prueba tenga un mayor costo que la aplicación. Finalmente, la tercera razón que es relevante es la definición debe solventar el problema de demostrar no solo que el programa hace lo que debe hacer, sino que además no haga lo que se espera que no haga y esto solo es posible en un marco más flexible de buscar la mayor cantidad de errores posibles.
La segunda idea relevante que plantea el autor en su artículo es la existencia de dos tipos de pruebas: las de caja negra y las de caja blanca. Respecto de las primeras se menciona que parten del hecho de solo preocuparse de lo que entra y sale de la aplicación, sin que sea relevante la parte interna. En este tipo de pruebas deben plantearse un universo de casos exhaustivos, con inputs válidos y no validos a efecto de verificar que las salidas tenga razonabilidad. Ahora bien el universo de entradas y las correspondientes salidas pueden dar origen a infinidad de combinaciones. Respecto al segundo tipo de pruebas, el autor menciona que éstas se concentran en el interior de la aplicación, es decir en su lógica. Esto representa dos grandes retos. El primer reto consiste en identificar todas las posibles rutas por las componentes del software que se pueden presentar, para verificar que las interrelaciones ante determinadas circunstancia estén previstas en la aplicación y funcionen adecuadamente. El segundo reto tiene que ver con la prueba individual de los componentes internos, la verificación de si los componentes son todos los necesarios o si es que hacen falta y si cada uno de estos componentes es sensible a datos y como pudieran manejar las distintas excepciones. Como podrá darse cuenta el lector esta también es una tarea titánica. La conclusión acerca de cuál de los dos tipos de pruebas es más favorable no es definitiva, más bien dado el amplio espectro es que se recomienda combinarlas y tratar de aprovechar al máximo sus beneficios.
Finalmente el autor nos menciona algunos principios que toda evaluación de software debiera respetar:
1. Definir de previo los resultados esperados
2. No revisar el software que uno hace
3. Las organizaciones deberían buscar que un tercero también pruebe su software.
4. Los resultados de las pruebas deben inspeccionarse a fondo
5. Las pruebas deben contener escenarios inesperados o inválidos
6. Las pruebas deben llevarse a cabo en diferentes momentos y sobre los mismos.
7. Evitar improvisar al momento de realizar la prueba para poder repetirla posteriormente
8. Debe partirse del hecho de que hay errores
9. Al hacer la prueba en las partes, errores en un componente es proporcional a errores en el resto
10. Hacer pruebas es un trabajo creativo e intelectual.
Definitivamente estamos aprendiendo de las pruebas, cierto??
En primer lugar el autor nos señala que puede existir un enfoque equivocado al definir qué es un test, es decir un pecado de origen. Si le pidiéramos al evaluador que "demostrará que no hay errores presentes" obtendríamos un resultado significativamente diferente de si pedimos "que encuentren todos los errores que pueda". Varias son las razones para esta diferencia. Primero, tomemos como ejemplo un enfermo que va a un Laboratorio, si el análisis indica que no hay nada mal en la persona, pero esta se siente mal, la prueba habrá sido un fracaso. El plantear como objetivo buscar que algo esté bien, no presenta oportunidades de mejora a las cuales aprovechar, es decir al paciente le interesa que le encuentren algo que lo guíe para sentirme mejor. La segunda razón por la cual la definición es importante es porque demostrar que algo está bien puede ser una tarea titánica de nunca acabar, con lo cual el costo de encontrar el error adicional puede ser tal que haga que la prueba tenga un mayor costo que la aplicación. Finalmente, la tercera razón que es relevante es la definición debe solventar el problema de demostrar no solo que el programa hace lo que debe hacer, sino que además no haga lo que se espera que no haga y esto solo es posible en un marco más flexible de buscar la mayor cantidad de errores posibles.
La segunda idea relevante que plantea el autor en su artículo es la existencia de dos tipos de pruebas: las de caja negra y las de caja blanca. Respecto de las primeras se menciona que parten del hecho de solo preocuparse de lo que entra y sale de la aplicación, sin que sea relevante la parte interna. En este tipo de pruebas deben plantearse un universo de casos exhaustivos, con inputs válidos y no validos a efecto de verificar que las salidas tenga razonabilidad. Ahora bien el universo de entradas y las correspondientes salidas pueden dar origen a infinidad de combinaciones. Respecto al segundo tipo de pruebas, el autor menciona que éstas se concentran en el interior de la aplicación, es decir en su lógica. Esto representa dos grandes retos. El primer reto consiste en identificar todas las posibles rutas por las componentes del software que se pueden presentar, para verificar que las interrelaciones ante determinadas circunstancia estén previstas en la aplicación y funcionen adecuadamente. El segundo reto tiene que ver con la prueba individual de los componentes internos, la verificación de si los componentes son todos los necesarios o si es que hacen falta y si cada uno de estos componentes es sensible a datos y como pudieran manejar las distintas excepciones. Como podrá darse cuenta el lector esta también es una tarea titánica. La conclusión acerca de cuál de los dos tipos de pruebas es más favorable no es definitiva, más bien dado el amplio espectro es que se recomienda combinarlas y tratar de aprovechar al máximo sus beneficios.
Finalmente el autor nos menciona algunos principios que toda evaluación de software debiera respetar:
1. Definir de previo los resultados esperados
2. No revisar el software que uno hace
3. Las organizaciones deberían buscar que un tercero también pruebe su software.
4. Los resultados de las pruebas deben inspeccionarse a fondo
5. Las pruebas deben contener escenarios inesperados o inválidos
6. Las pruebas deben llevarse a cabo en diferentes momentos y sobre los mismos.
7. Evitar improvisar al momento de realizar la prueba para poder repetirla posteriormente
8. Debe partirse del hecho de que hay errores
9. Al hacer la prueba en las partes, errores en un componente es proporcional a errores en el resto
10. Hacer pruebas es un trabajo creativo e intelectual.
Definitivamente estamos aprendiendo de las pruebas, cierto??
martes, 15 de marzo de 2011
Probar software sin especificaciones
Estoy leyendo un artículo del señor Michael Bolton, ojo no es el cantante, publicado en junio del 2005 en http://www.stickyminds.com/, en donde desarrolla la idea de que es es posible probar el software sin tener las especificaciones desde el origen. Situación que obviamente comparto.
Lo que el señor Bolton nos plantea es que por medio de la experiencia y las destrezas personales es posible hacer un primer viaje exploratorio por la aplicación y a partir de este, formar un criterio acerca de su desempeño.
¿Por qué en un inicio no es necesario recurrir a las especificaciones? La respuesta es muy sencilla. En primer lugar, son muy pocos los casos en que tenemos acceso a todas las especificaciones, es decir, probablemente tengamos acceso a una parte del proyecto, pero no necesariamente a todo. En segundo lugar, si el software ya ha sido desarrollado hace algún tiempo, es probable que las especificaciones que encontremos no estén o se encuentren desactualizadas, y en tercer lugar los proyectos tecnológicos cambian constantemente y no necesariamente la documentación de las especificaciones se muevan al mismo ritmo.
¿Lugar de las especificaciones? El señor Bolton también nos llama la atención acerca de la fuente de las especificaciones, es decir de donde el responsable de las prueba las obtendrá, en el mejor de los casos estarán documentadas, pero puede darse el caso de que haya que recurrir a entrevistas, correos, etc, y deberán considerarse como oficiales o requerir que se oficialicen.
Técnicas de probar. Según el autor existen dos posibles categorías para agrupar las pruebas: las de oráculo y las heurísticas. La primera categoría alberga el criterio experto, el que es capaz de ver más allá de un documento con especificaciones y se deja llevar por su persepción del lugar donde el software presentará pulgas. La segunda categoría plantea que debe existir una guía provisional que facilite la exploración, la cual debe estar lista de previo.
Tips para el "tester". (Regla HIC-CUPPS) Para los que quieren obtener tips para llevar adelante una evaluación, el autor recomienda según un acrónimo, por donde entrarle al tema.
Historia: Revisar como la aplicación se ha comportado en el pasado.
Imagen: Fijarse en como el producto luce y a partir de su imagen evaluar el comportamiento.
Comparación: Buscar otros productos con funcionalidades similares para inferir las que el evaluado debe tener.
Claims: Revisar lo que se ha ofrecido que el producto haga.
Usuarios: Revisar lo que los usuarios han pedido que haga.
Producto: Verificar que lo que el producto dice que hace, lo haga.
Propósito: Verificar el propósito primario de cada función.
Statutes: Verificar lo que la regulación espera que el producto haga.
Con esto creo que somos casi unos expertos en llevar adelante una primera exploración a una determinada aplicación y estaríamos casí listos para hacer un test.
Lo que el señor Bolton nos plantea es que por medio de la experiencia y las destrezas personales es posible hacer un primer viaje exploratorio por la aplicación y a partir de este, formar un criterio acerca de su desempeño.
¿Por qué en un inicio no es necesario recurrir a las especificaciones? La respuesta es muy sencilla. En primer lugar, son muy pocos los casos en que tenemos acceso a todas las especificaciones, es decir, probablemente tengamos acceso a una parte del proyecto, pero no necesariamente a todo. En segundo lugar, si el software ya ha sido desarrollado hace algún tiempo, es probable que las especificaciones que encontremos no estén o se encuentren desactualizadas, y en tercer lugar los proyectos tecnológicos cambian constantemente y no necesariamente la documentación de las especificaciones se muevan al mismo ritmo.
¿Lugar de las especificaciones? El señor Bolton también nos llama la atención acerca de la fuente de las especificaciones, es decir de donde el responsable de las prueba las obtendrá, en el mejor de los casos estarán documentadas, pero puede darse el caso de que haya que recurrir a entrevistas, correos, etc, y deberán considerarse como oficiales o requerir que se oficialicen.
Técnicas de probar. Según el autor existen dos posibles categorías para agrupar las pruebas: las de oráculo y las heurísticas. La primera categoría alberga el criterio experto, el que es capaz de ver más allá de un documento con especificaciones y se deja llevar por su persepción del lugar donde el software presentará pulgas. La segunda categoría plantea que debe existir una guía provisional que facilite la exploración, la cual debe estar lista de previo.
Tips para el "tester". (Regla HIC-CUPPS) Para los que quieren obtener tips para llevar adelante una evaluación, el autor recomienda según un acrónimo, por donde entrarle al tema.
Historia: Revisar como la aplicación se ha comportado en el pasado.
Imagen: Fijarse en como el producto luce y a partir de su imagen evaluar el comportamiento.
Comparación: Buscar otros productos con funcionalidades similares para inferir las que el evaluado debe tener.
Claims: Revisar lo que se ha ofrecido que el producto haga.
Usuarios: Revisar lo que los usuarios han pedido que haga.
Producto: Verificar que lo que el producto dice que hace, lo haga.
Propósito: Verificar el propósito primario de cada función.
Statutes: Verificar lo que la regulación espera que el producto haga.
Con esto creo que somos casi unos expertos en llevar adelante una primera exploración a una determinada aplicación y estaríamos casí listos para hacer un test.
domingo, 13 de marzo de 2011
Conocimiento: mi definición
Estoy llevando un curso de gerencia del conocimiento y la primera pregunta del profesor me dejo "picado": ¿qué es el conocimiento?.
Por mucho tiempo deje este tipo de preguntas al apoyo de la RAE, Wikipedia o cualquier otro que haya hecho el trabajo por mi de recabar información. Sin embargo, hoy quise entrar de lleno en conocer qué es conocimiento. Adelanto que ya Platón, San Agustín o Nonaka y Takeuchi han hecho un aporte al estado del arte, del que yo jamás intentaré mejorar con este post. Mi única intensión es comentar, sólo comentar.
Conocimiento para mi tiene que ver con "capacidad de asombro". El ser humano esta expuesto durante su vida a una serie de datos, emociones y experiencia que por el simple hecho de haberlas enfrentado no entran a formar parte de un selecto grupo de "lecciones aprendidas" que llamamos conocimiento. Pienso en este momento en la experiencia de un niño recién nacido al que se le acerca una sonaja (chilindrín) y maravillado conoce el sonido, pienso en el joven médico que en su primera operación ve latir un corazón y descubre la vida y pienso en el enamorado que al dar un beso descubre el amor.
Mi hipótesis es que todo aquello que te ha asombrado ha entrado, en ese mismo momento a ser parte de tu conocimiento.
¿Como aumentar el conocimiento? Según mi hipótesis bastaría con iniciar experiencias que a cada uno lo lleven al asombro, es decir estar expuesto. Como antítesis a esta afirmación aquellas personas que no estén expuestas a situaciones de asombro verán limitadas sus posibilidades de aumentar el conocimiento.
La especialidad. Como corolario a lo dicho la innegable consecuencia de ligar el asombro al conocimiento sería que habrá especialistas, es decir personas cuyas experiencias de asombro los hayan condicionado a llegar a un determinado nivel. Será por lo tanto una persona con mucho conocimiento en música quien haya estado expuesta a las mayores emisiones de las ondas haciendo vibrar su sistema auditivo, igualmente será un chef con mucho conocimiento el que haya experimentado en su papilas gustativas los distintos sabores y texturas que este mundo puede ofrecer. Agregue el lector por favor las situaciones de asombro que los hayan hecho poseedores del más importante tesoro que siempre podrán poseer, el conocimiento.
Todos nos hemos asombrado, todos tenemos conocimiento y todos podemos mejorarlo, fundamentalmente con una receta: estar expuestos al asombro, busque cada uno en donde obtenerlo.
Por mucho tiempo deje este tipo de preguntas al apoyo de la RAE, Wikipedia o cualquier otro que haya hecho el trabajo por mi de recabar información. Sin embargo, hoy quise entrar de lleno en conocer qué es conocimiento. Adelanto que ya Platón, San Agustín o Nonaka y Takeuchi han hecho un aporte al estado del arte, del que yo jamás intentaré mejorar con este post. Mi única intensión es comentar, sólo comentar.
Conocimiento para mi tiene que ver con "capacidad de asombro". El ser humano esta expuesto durante su vida a una serie de datos, emociones y experiencia que por el simple hecho de haberlas enfrentado no entran a formar parte de un selecto grupo de "lecciones aprendidas" que llamamos conocimiento. Pienso en este momento en la experiencia de un niño recién nacido al que se le acerca una sonaja (chilindrín) y maravillado conoce el sonido, pienso en el joven médico que en su primera operación ve latir un corazón y descubre la vida y pienso en el enamorado que al dar un beso descubre el amor.
Mi hipótesis es que todo aquello que te ha asombrado ha entrado, en ese mismo momento a ser parte de tu conocimiento.
¿Como aumentar el conocimiento? Según mi hipótesis bastaría con iniciar experiencias que a cada uno lo lleven al asombro, es decir estar expuesto. Como antítesis a esta afirmación aquellas personas que no estén expuestas a situaciones de asombro verán limitadas sus posibilidades de aumentar el conocimiento.
La especialidad. Como corolario a lo dicho la innegable consecuencia de ligar el asombro al conocimiento sería que habrá especialistas, es decir personas cuyas experiencias de asombro los hayan condicionado a llegar a un determinado nivel. Será por lo tanto una persona con mucho conocimiento en música quien haya estado expuesta a las mayores emisiones de las ondas haciendo vibrar su sistema auditivo, igualmente será un chef con mucho conocimiento el que haya experimentado en su papilas gustativas los distintos sabores y texturas que este mundo puede ofrecer. Agregue el lector por favor las situaciones de asombro que los hayan hecho poseedores del más importante tesoro que siempre podrán poseer, el conocimiento.
Todos nos hemos asombrado, todos tenemos conocimiento y todos podemos mejorarlo, fundamentalmente con una receta: estar expuestos al asombro, busque cada uno en donde obtenerlo.
Inicio de una nueva aventura
Debo confesar que ya antes había tenido otros blogs, básicamente por curiosidad, pero los abandone, básicamente por poca disciplina y por no tener claro el norte.
Ante la solicitud que se me hiciera en un curso de la Universidad de crear nuevamente un blog encuentro muy interesante replantear la experiencia y formalizarla en este proyecto. La universidad me está plateando dos importantes paradigmas: el primero tiene que ver con tener un repositorio ordenado en donde poder almacenar "el conocimiento". El segundo, claro está, es llenar este repositorio con lo que vaya llegando que valga la pena compartir.
En lo personal voy a agregar un tercer paradigma que tiene que ver con la convivencia en estos espacios virtuales, en donde no sólo se vayan llenando los bytes de los servidores con temas académicos, sino que sea un diario personal en donde este proyecto tenga, a mi criterio un poco más de valor agregado en el sentido de que el conocimiento no sólo lo da la academia sino la vivencia. No sé con que periodicidad lo iré completando, pero espero que cada vez que llegue a mi mente algo relevante lo pueda publicar y así poder compartirlo con ustedes, quienes amablemente se toman su tiempo para leer mis publicaciones.
Felicito a todos los que ya han logrado avanzar en estos menesteres, pues es sin duda un trabajo muy retador.
Como en todo inicio son muchos los sueños y quien sabe hasta donde esto llegará...
Ante la solicitud que se me hiciera en un curso de la Universidad de crear nuevamente un blog encuentro muy interesante replantear la experiencia y formalizarla en este proyecto. La universidad me está plateando dos importantes paradigmas: el primero tiene que ver con tener un repositorio ordenado en donde poder almacenar "el conocimiento". El segundo, claro está, es llenar este repositorio con lo que vaya llegando que valga la pena compartir.
En lo personal voy a agregar un tercer paradigma que tiene que ver con la convivencia en estos espacios virtuales, en donde no sólo se vayan llenando los bytes de los servidores con temas académicos, sino que sea un diario personal en donde este proyecto tenga, a mi criterio un poco más de valor agregado en el sentido de que el conocimiento no sólo lo da la academia sino la vivencia. No sé con que periodicidad lo iré completando, pero espero que cada vez que llegue a mi mente algo relevante lo pueda publicar y así poder compartirlo con ustedes, quienes amablemente se toman su tiempo para leer mis publicaciones.
Felicito a todos los que ya han logrado avanzar en estos menesteres, pues es sin duda un trabajo muy retador.
Como en todo inicio son muchos los sueños y quien sabe hasta donde esto llegará...
Suscribirse a:
Entradas (Atom)