Los defectos no son algo con lo que generalmente cuentas y tomas una decisión. Un defecto puede dejar inutilizable una aplicación, mientras que otro defecto nunca puede afectar a un solo usuario.
Los desarrolladores lanzan aplicaciones (móviles u otras) cuando sienten que el beneficio de la liberación supera el costo de la espera.
En algunos casos, esto podría significar la liberación intencional de una aplicación muy reducida y con errores para obtener rápidamente comentarios valiosos del mercado y de los usuarios.
- ¿Cuál es la mejor compañía para la compañía nativa de desarrollo de aplicaciones móviles en Hyderabad?
- ¿Cómo pueden las nuevas empresas de aplicaciones móviles usar Apptopia? ¿Cómo se usan las métricas y qué tipo de acciones se toman después? ¿Vale la pena gastar tanto dinero en Apptopia?
- ¿Por qué no puede deshacer una actualización de la aplicación móvil si prefiere una versión anterior?
- Cómo elegir una empresa de diseño y desarrollo de sitios web
- ¿Cuáles son las principales empresas de desarrollo de aplicaciones móviles en Bangalore?
En otros casos, esto podría significar pasar por meses de rigurosas pruebas y correcciones de errores.
Piense en cualquier aplicación comercial: sistemas operativos, software de negocios, juegos, etc. ¿Se da cuenta con qué frecuencia se actualiza la aplicación para corregir errores?
No existe una aplicación perfecta.
¿Por qué?
- Incluso después de las pruebas más rigurosas, todavía está lanzando un diseño particular que puede ser percibido como defectuoso por alguien que espera un diseño diferente.
- Solo sabes sobre los errores que pruebas. Raramente se documentan y / o prueban todos los escenarios dentro de una aplicación. Por lo tanto, puede lanzar una aplicación que pase todos los casos de prueba pero que todavía esté llena de errores.
¡El cómic clásico a continuación ilustra la dificultad de entregar una aplicación perfecta, y ni siquiera incluye una fase de prueba!
De: Cómo y por qué los prototipos son obligatorios para un buen diseño
Cómo reducir errores en aplicaciones
Como ejemplo, en mi empresa, nuestros estándares son:
- Especifique una aplicación o una nueva versión de una aplicación por adelantado de una manera lo suficientemente detallada como para que todas las partes entiendan los comportamientos esperados,
- Reduzca la posibilidad de errores al invertir en componentes, patrones y estándares reutilizables,
- Desarrolle casos de prueba manuales y automatizados para tantos escenarios y casos de uso como sea posible,
- Realice la misma prueba de unidad regimentada 3 veces de la siguiente manera:
- Desarrollador: en su propio dispositivo
- Desarrollador: en un dispositivo de desarrollo común
- Garantía de calidad: en un dispositivo de desarrollo común
- Realice pruebas de integración para garantizar que un cambio en un elemento no haya roto otros elementos,
- Actualice las especificaciones y los casos de prueba según sea necesario para garantizar que se tengan en cuenta las interacciones inesperadas
- Arreglar error
- Realice los pasos 1–7 nuevamente según sea necesario.
- Suelta a la puesta en escena y realiza una prueba de cordura.
- Suelta para vivir (publica la aplicación) y realiza una prueba de cordura
Como puede imaginar, el proceso anterior puede llevar más tiempo que desarrollar la aplicación en primer lugar. Esto es aún más cierto cuando se realizan modificaciones en aplicaciones existentes grandes y complejas.
Por lo general, no lanzamos una aplicación hasta que se hayan corregido todos los errores conocidos. La única excepción es cuando tanto las partes interesadas en el desarrollo como las empresas acuerdan que el beneficio de la publicación supera el costo de la espera.
Sin embargo, siempre habrá problemas que surjan en una aplicación lanzada, sin importar cuán exhaustivos sean sus procesos de garantía de calidad.
Las preguntas permanecen:
- ¿Con qué rigor diseña, planifica y prueba su aplicación?
- ¿Qué tan rápido necesitas sacar tu lanzamiento?
