QAustral

Un Blog de QAustral SA – Calidad de Software y Negocios

Home » Posts tagged "fallas"

Fallas en el iPhone 4: “hacen fila” para responderle a Steve Jobs

Clarin.com
El líder de Apple había asegurado que los problemas de recepción de señal del iPhone 4 también los sufren teléfonos de otros fabricantes. Nokia, RIM (Blackberry), Samsung, Motorola y HTC salieron a desmentir a Apple.

Fallas

Fallas

Clarin.com
19/07/10 – 17:36 El enfrentamiento entre Apple y otros fabricantes de smartphones escaló este fin de semana después de que Steve Jobs dijese en una conferencia de prensa que los problemas que afectan al iPhone 4 son comunes a todos los teléfonos inteligentes. Jobs nombró concretamente a los fabricantes RIM, Nokia, Samsung y HTC. La respuesta no se hizo esperar por parte de todas esas empresas nombradas.

El fabricante de BlackBerry, RIM, hizo público un comunicado firmado conjuntamente por Mike Lazaridis y Jim Basilie, los máximos dirigentes de la empresa, en el que calificaron de “inaceptables” las manifestaciones de Jobs. “Las declaraciones de Apple sobre los productos de RIM son intentos deliberados de desviar la atención de la difícil situación por la que está pasando Apple”, dice el comunicado de RIM. El fabricante de BlackBerry recordó que RIM es “líder mundial en diseño de la antena” y recomendó a Apple que asuma responsabilidades en lugar de intentar perjudicar a RIM y otros fabricantes.

En un comunicado similar, Nokia enfatizó su papel como “pionero en las antenas internas” y que durante décadas ha sido uno de los puntos claves en la fabricación de sus productos. “Como es de esperar de una compañía que se preocupa por la gente, nosotros priorizamos el correcto funcionamiento de la antena por encima del diseño si estos dos factores entran en conflicto”, comunicó la compañía finlandesa.

La taiwanesas HTC, que fabrica smartphones con el sistema operativo Android de Google, la coreana Samsung y la estadounidense Motorola también salieron a aclarar que sus productos nunca tuvieron problemas de recepción de señal.

Fallas de Software (parte XIII)

Falla de la computadora del Centro de Control de Tráfico Aereo de Nueva York (1996)

El 20 de mayo de 1996 falló la computadora del Centro de Control de Tráfico Aereo de Nueva York (ARTCC) que controlaba el tráfico aéreo sobre los estados de Nueva York, Connecticut, Nueva Jersey, Pennsylvania, y parte del oceáno Atlántico. La computadora, con siste años de operación, perdió la capacidad de servicio efectivo ( digase “fallo”) dos veces la tarde del lunes 20 de mayo, la primera durante 20 minutos y la segunda alrededor de una hora, una hora más tarde. Se regresó al sistema anterior, con procedimientos de control de tráfico aéreo menos eficientes, ocasionando mayor saturación de tráfico y retrasos en los despegues de alrededor de una hora en los aeropuertos principales en el área, además de un incremento en la carga de trabajo de los controladores y menor seguridad, incluyendo la desactivación de la “alerta automática de conflictos”

Fallas en el software (parte XI)

Error en un sistema de autenticación de tarjetas de crédito (1995)

Según un artículo del 4 de noviembre de 1995 en el periódico Guardian del Reino Unido, los dos sistemas más grandes en ese país para la autorización de crédito ( Barclay´s PQD y NatWest´s Streamline) fallaron el sábado 28 de octubre de 1995 imposibilitando que los comercios verificaran las tarjetas de crédito de sus clientes. En el caso de Barclay, más de 40% de las transacciones fallaron por un error en el sistema de software. Para NatWest, el problema fue ocasionado por una gran cola de llamadas, que obstruyo la comunicación por razones desconocidas, y que retraso la autentificación de tarjetas. Aunque ambos sistemas estaban preparados para afrontar este tipo de contingencias, lo cual lo lograban mediante llamadas por teléfono para autentificar las solicitudes ( como lo hace American Express), el volumen de llamadas fue tal que ocasiono que las líneas se saturaran rápidamente y trono de nuevo.

Fallas en el software (parte VII)

El 31 de enero de 1990 un error de software en la estación de nuclear de Bruce en Canadá ocasionó la liberación de miles de litros de agua radiactiva, los cuales escaparon en forma de vapor. Los encargados de seguridad en la industria nuclear describieron la situación como muy “inusual y también muy significativa”. Por suerte la situación se controló rapidamente causando unicamente la pérdida de dinero y tiempo, manteniendo la estación fuera de operación por varias semanas.

Fallas en el software (parte IV)

Muertes por el Terac-25 ( 1985-1987)

El acelerador lineal médico Therac-25, producido por Atomic Energy of Canadá Limited ( AECI), fue diseñado para tratamientos de radiación de dos tipos (1) tratamiento de rayo directo de bajo poder y (2)tratamiento de rayo indirecto reflejado de alto poder. Entre 1985 y 1987 esté sistema ocasionó la muerte de varios pacientes en diferentes hospitales de Estado Unidos y Canadá debidó a las radiaciones de alto poder aplicadas sin control. A partir de ciertas secuencias de comandos del operador de la máquina, los controles de la computadora lo llevaban a un estado interno erróneo muy peligroso, generado por una sobredosis masivá de radiación. Después de una amplia publicidad de estos accidentes, se descubrio que la Federal Drug Agency (FDA) no especificaba requisitos, ni hacía revisiones sobre las prácticas de desarrollo o control de calidad del software en dispositivos médicos. La FDA informó en 1987 que comenzaría a exigir controles de software integrados a ciertas clases de dispositivos médicos. Lamentablemente, en muchos de estos sistemas el operador también juega un papel crítico, como en el caso de Panamá en 2001, donde datos insertados incorrectamente por los operadores durante tratamientos de cáncer mediante radiación ocasionaron la muerte de 5 personas en esté país. Aunque la falla no fue directamente atribuida al software, se supone que el sistema de radicación contaba con protección para prevenir la radiación de tejido sano.

Fallas en el software (parte I)

Estos son algunos ejemplos de fallas directas e indirectas que se han registrado en el paso de la historia en los sistemas de software.

Fracaso de Mariner I ( 1962)

La primera mision del sistema mariner ( cuyo costo total, desde la misón Mariner I hasta la Mariner 10 fue de 554 millones de dólares) fracasó por un carácter incorrecto (” ˜ “) en la especificación del programa de control para el cohete de propulsión Atlas, lo cuál causó que finalmente se saliera de curso. Tanto el cohete como el vehículo espacial tuvieron que ser destruidos pocó después de su lanzamiento. Se cree que un error de computadora también fue la causa del fracaso del Mariner 8 en 1971.

Cual es el orden sugerido de ejecucion de tests?

Testing no es solamente ejercitar el software para detectar defectos o fallas, Testing se aplica a cada una de las etapas conocidas del desarrollo de Software

Por lo general pensamos que ejecutar pruebas es todo el testing cuando en realidad eso solo representa el 40% del testing. Porque se da tanta importancia a una sola actividad cuando los errores se pueden encontrar antes y con menor costo. Yo creo que es una cuestion de cultura el no ver mas alla de lo que creemos importante.
Testing no es solamente ejercitar el software para detectar defectos o fallas, Testing se aplica a cada una de las etapas conocidas del desarrollo de Software. Cada etapa, documento involucrado, porcion de software, planeamiento es testeable y debe ser testeado antes de ejecutar los System Tests.
Ademas involucrar los testers en etapas tempranas del desarrollo trae muchos beneficios, como ahorro del tiempo de ejecucion de tests, familiarizacion con el futuro sistema.
El ciclo elemental de Testing cuenta con las siguientes etapas:

> Planeamiento y Control
> Analisis y Disenio.
> Ejecucion e implementacion
> Evaluacion y reportes
> Actividades de cierre

Cada una de estas actividades internas al area de testing estan relacionadas con las etapas del desarrollo del software para “testearlas” y encontrar fallas antes de tener el codigo listo.
Solo dento de la etapa de ejecucion se realizan los test de:
* Component Testing (Mas conocidos como UniTests)
* Integration Testing (Mediante distintas metodologias, Bigban, Funcional, etc…)
* System Testing (Functional y No Funciona)
* User Acceptance Testing

by Sergio