En general, ¿el aseguramiento de la calidad (QA) / prueba es tan importante como el desarrollo? ¿Por qué? ¿Por qué las entrevistas de control de calidad / pruebas son más fáciles que las entrevistas de desarrollo? ¿No se refleja esto directamente en realizar un control de calidad o pruebas deficientes?

Tu pregunta es parcial. Es como preguntar por qué es más fácil actuar que la dirección, o si es necesaria la dirección (ya que ni siquiera vemos a los directores en la pantalla, ¿están trabajando?)

La pregunta principal que se hace es: ¿las pruebas son tan importantes como el desarrollo? Vamos a verlo de esta manera.

Si no ocurre desarrollo, no se requieren pruebas

Si el desarrollo ocurre y las pruebas no suceden, entonces el producto se desarrolla correctamente, pero no hay garantía de calidad. Puede ser un buen producto, puede ser un mal producto.

Entonces, desde la perspectiva de la producción, el desarrollo es más importante que las pruebas.

Desde la perspectiva de la calidad, las pruebas son más importantes.

Además, las pruebas son como las matemáticas. Todo el mundo sabe un poco. Pero para marcar la diferencia, debes estudiar y convertirte en un experto.

En muchas pequeñas empresas, desarrolladores y otras personas como BA, ventas, etc., se encargan de las pruebas. Esto se debe a que no pueden permitirse un equipo de prueba por separado o subcontratar sus esfuerzos de prueba. Esto en su mayoría deja muchos errores sin ser detectados, lo que afecta el uso posterior a la producción, lo que a su vez afecta el valor comercial y de marca de la empresa.

Si te preguntara cuál de los dos: la comida o la ropa es más importante, ¿qué dirías? Por supuesto comida! Si tienes hambre durante días, usar un buen vestido no tiene sentido. Pero si su hambre está saciada, ¿cuál es la próxima cosa importante que debe tener? ¡Lo supiste bien!

Después de estudiar esta pregunta, no puedo decir que el aseguramiento de la calidad sea menos importante que el desarrollo. Además, la ausencia del equipo de control de calidad en el proyecto en todas las etapas del desarrollo del software puede tener graves consecuencias.

Como escribí en mi artículo: “Importancia del aseguramiento de la calidad: 7 formas en que puede ayudar a su negocio”, incluso los codificadores talentosos hacen 3–4 errores por cada 1000 líneas de código. Este número es aún mayor para el personal menos experimentado.

Y aunque prueban su código y se aseguran de que se ejecute correctamente, no es suficiente.

Conozco muchos ejemplos tristes de grandes ideas para un producto que no se probaron bien y provocaron muertes o una gran pérdida financiera. Tome Ariane 5 y St. Mary’s Mercy Medical Center, por ejemplo.

Además, el control de calidad puede ayudar a su negocio de al menos siete formas diferentes:

1. Mejorar la retención de clientes;
2. Satisfacer las necesidades del cliente;
3. Ahorre costos;
4. Fortalecer la imagen positiva de la empresa, etc.

Puedes leer la pieza completa aquí. Espero que esta información haya ayudado 🙂

El desarrollo no puede pasar sin pruebas. El control de calidad tiene como objetivo prevenir defectos con un enfoque en el proceso que se utiliza para fabricar el producto. Es una gestión de calidad proactiva. El objetivo principal del control de calidad es vigilar la producción y el desarrollo, probarlos y mejorarlos. Esto se hace con la ayuda de pruebas que verifican qué tan buenos son los procesos y evitan que las compañías produzcan productos defectuosos.

Existen tres metodologías principales de desarrollo de software y el aseguramiento de la calidad es su parte integral.

El modelo en cascada se caracteriza por el desarrollo de software donde el proceso se ve como un flujo que desciende pasando todos los pasos sucesivos uno por uno. Son análisis de requisitos, diseño, desarrollo de productos, pruebas, instalación y mantenimiento. Debido a dicha estructura, se asemeja a una cascada.

El modelo se introdujo en 1970, y desde entonces han aparecido muchos métodos nuevos. Es constantemente criticado por no ser lo suficientemente flexible y centrarse en la gestión del proceso en lugar de sus resultados. Aquí es casi imposible realizar cambios, por lo que los plazos, el presupuesto y la calidad pueden verse muy comprometidos. A pesar de esto, el modelo de cascada sigue siendo bastante popular ya que hay industrias donde solo se puede aplicar. Por ejemplo, el proceso de construcción de software para el control de naves espaciales no puede ser ágil. Primero debe estar bien documentado, luego bien diseñado, construido y finalmente probado. Aquí, el costo de los errores es demasiado alto.

El modelo V es el proceso de desarrollo de software que a veces se considera relacionado con el modelo en cascada. Sin embargo, se parece solo parcialmente. Para ser más precisos, solo los pasos que preceden a la implementación del producto son similares. El resto de las etapas van hacia arriba creando una V. Las etapas incluyen concepto, análisis de requisitos, diseño detallado, implementación, integración y prueba, verificación, lanzamiento y mantenimiento. La forma en V se forma para explicar la conexión entre las fases iniciales con la prueba y verificación del producto.

Al igual que el método de cascada, el modelo V tampoco es bastante flexible. Es imposible realizar cambios dinámicos en varias etapas del ciclo de vida del producto. También presupone algunos riesgos que no pueden eliminarse solo porque el producto se prueba en etapas posteriores y cada corrección realizada influye en la línea de tiempo y en todo lo que está conectado con él.

Las pruebas ágiles se originan en el principio del mismo nombre del desarrollo de software. Sus seguidores consideran que el aseguramiento de la calidad es una parte integral del proceso de desarrollo. Significa que los desarrolladores y probadores trabajan en estrecha cooperación entre sí. Un equipo ágil debe ser muy flexible y reaccionar a todos los cambios necesarios de inmediato y no cuando se completa alguna etapa del proceso.

La interacción entre todos los miembros del equipo y el tipo de trabajo iterativo le da a este método una ventaja competitiva. Cada característica se desarrolla y prueba simultáneamente y está lista para la producción solo cuando es lo suficientemente buena. Tal enfoque ahorra costos significativos al cliente porque el producto se prueba paso a paso.

Puede encontrar más información sobre el control de calidad en el artículo: ¿Qué es la garantía de calidad: una necesidad o una pérdida de tiempo?

¿Qué? “¿El control de calidad / pruebas es tan importante como el desarrollo? ¿Por qué?”

Déjame preguntarte. ¿Es una picadura tan importante como morder y masticar?

Hay muchas buenas respuestas técnicas en este hilo. Adoro especialmente la respuesta de Vanessa Williams.

Permítanme centrarme en el simple sentido común.

Como es ridículo considerar morder, probar y masticar como actividades aisladas e independientes, tampoco es inteligente juzgar las pruebas aparte de la programación.

Todos deben probar, es decir, revisar el producto y su trabajo. Todos deben probar en su alcance. Los programadores revisan el código y escriben cheques automáticos (también conocidos como pruebas unitarias).

Ciertos tipos de pruebas son simples y directas. Muchos otros son profundos e intrincados; requieren mucho tiempo y habilidades para realizar. Los probadores son responsables de eso.

“La calidad es valor para una persona ” ~ Gerald Weinberg.

El aspecto muy especial de las pruebas es buscar amenazas al valor.

Es muy importante no entregar esto. (A menos que su cliente sea un pescador … ¿ve cuán volátil es el concepto de calidad? :))

Ahora a las subpreguntas.

¿Por qué las entrevistas de control de calidad / pruebas son más fáciles que las entrevistas de desarrollo? ¿No se refleja esto directamente en realizar un control de calidad o pruebas deficientes?

¡Tienes toda la razón!

Las malas prácticas de contratación a menudo dan como resultado un personal poco calificado que se refleja directamente en el desempeño laboral que se refleja directamente en la calidad del producto.

Mucho depende de la cultura de calidad en la empresa y la madurez de la gestión.

Existe la idea errónea de que la calidad puede separarse del desarrollo. Esto lleva a una cultura empresarial que no conduce a productos de calidad. Esto conduce a productos de la compañía que no generan ingresos de la compañía. Esto conduce a ingresos de la compañía que no pueden apoyar a los empleados de la compañía … y el hermoso ciclo de recontratación continúa.

Los productos de primer nivel tienen calidad incorporada desde el principio.

Una gran encarnación de esto está en Test Driven Development. El uso de ‘prueba’ en este eslogan ágil es preciso si es un poco desafortunado; sería igual de apropiado si se llamara “desarrollo impulsado por casos de uso”. Dejando a un lado los insultos, la esencia es que el software puede diseñarse, incluso a nivel modular y de unidad, para un propósito.

El producto y los módulos de producto pueden entonces desarrollarse y verificarse para ese propósito. Si se realiza correctamente, y si la empresa realiza un buen trabajo al recopilar artefactos y técnicas de verificación (por ejemplo, pruebas, pruebas basadas en procesos y más), el proceso de construcción del producto sirve para reforzar la calidad del producto.

… así que cuando pregunte “¿la prueba de calidad / pruebas es tan importante como el desarrollo?”, Le respondí: “El desarrollo de productos de calidad requiere que desarrolle Y pruebe con un objetivo. La calidad del producto resultará de la ejecución adecuada de ambos”.

En cuanto a por qué las personas de QA entrevistan más fácilmente que los desarrolladores … la respuesta a “por qué” siempre es “dinero” (o, en este caso, sospecho que la oferta y la demanda).

La respuesta de Lanette Creamer es buena desde el punto de vista del probador. Desde el punto de vista del desarrollador, nos encanta que nuestro equipo de control de calidad sepa más sobre las pruebas que nosotros. Al final del día, podemos estar seguros cuando lanzamos una nueva versión de un producto que es sólida. Como mínimo, no tiene regresiones y funciona al menos tan bien como la versión anterior. Nuestro proceso de prueba es extenso e involucra pruebas unitarias, pruebas de aceptación automatizadas, pruebas manuales, pruebas de rendimiento, etc.

Bromeamos al respecto, pero en realidad estamos muy contentos cuando QA encuentra algo mal que no notamos. Solucionarlo significa que estamos un paso más cerca de un gran producto. Por lo general, significa que hay una oportunidad para aprender algo.

Por lo tanto, la conclusión es que el desarrollo y las pruebas son igualmente importantes si su objetivo es producir software de calidad. Cualquier desarrollador que no entienda eso es alguien con quien no quiero tener que trabajar.

Sí, las pruebas de software son igualmente importantes para el desarrollo de software. Hay muchas desviaciones de los requisitos reales cuando el equipo de desarrollo trabaja. La prueba de software es necesaria porque todos cometemos errores. Algunos de esos errores no son importantes, pero algunos son caros o peligrosos.

Las pruebas de software son realmente necesarias para señalar los defectos y errores que se hicieron durante las fases de desarrollo.
Es esencial ya que se asegura de la confiabilidad del Cliente y su satisfacción en la aplicación.
Es muy importante garantizar la calidad del producto. El producto de calidad entregado a los clientes ayuda a ganar su confianza.

No puedo estar más de acuerdo con Lanette Creamer. Los equipos de TI ayudan a abordar las necesidades empresariales, cuando una parte de los equipos de TI no hace su trabajo correctamente, las necesidades empresariales no se satisfacen. Desarrollo, Pruebas, Infraestructura son solo algunas de las diferentes caras de estos equipos de TI. Aquí no hay un equipo más grande o más pequeño, es solo eso, el trabajo del equipo de Pruebas es validar la solicitud de Business Assurance que los lleva a una encrucijada con los equipos de Desarrollo. Construir una aplicación es tan importante como validar si está construida según los requisitos especificados y respaldada por la infraestructura adecuada.

Para responder al subtexto, las entrevistas de prueba se centran más en el enfoque de prueba, la estrategia, las herramientas, el proceso y los estándares en lugar de las preguntas tecnológicas. Así que no es una comparación manzana a manzana IMO.

Tema relacionado: Respuesta del usuario de Quora a ¿Por qué las pruebas de software se consideran menos “prestigiosas” que la ingeniería de software?

En una línea de fabricación, ¿es el Paso 2 más importante que el Paso 4? Ambos están orientados hacia un objetivo común, concentrándose solo en diferentes aspectos del proceso. En un restaurante (también en la industria de servicios), ¿es más importante cazar pollos que cocinarlo?

Claro, puede lanzar un software que no fue probado pero no puede probar sin tener ningún software para probar en primer lugar. Sin embargo, sería incorrecto usar el argumento de precedencia cronológica para enfatizar la importancia de la programación; no importa cuán tangible sea el programa, no sirve de nada crear un programa que tenga muchos defectos críticos o que ni siquiera satisfaga las necesidades principales de los usuarios finales en primer lugar.

Los programadores siempre pueden presentar una salida tangible, mientras que los probadores solo pueden presentar documentos de respaldo para el valor intangible del equipo de control de calidad. Sin embargo, al medir el verdadero valor comercial a través del Costo de Calidad (un concepto de contabilidad gerencial), el mayor costo en la empresa son los intangibles , por ejemplo, el costo de oportunidad perdido debido a una reputación empañada de la compañía. Sin los clientes habituales, los programadores no tendrán trabajo. Es responsabilidad del equipo de control de calidad asegurarse de que los clientes sigan contentos.

Así que por favor deja de insinuar que es “solo una prueba”. La respuesta del usuario de Quora a ¿Qué molesta a los probadores de software?

Como alguien que entrevista a los evaluadores, no creo que las entrevistas de control de calidad sean inherentemente más fáciles. De hecho, espero más habilidades de comunicación y perspectiva comercial en una entrevista de control de calidad que en una entrevista de programación. Si aplico el mismo criterio al realizar entrevistas para un trabajo de programación, estoy seguro de que muchas personas fracasarían.

Hay programadores que suponen que las pruebas de software son fáciles, pero son las mismas personas que odiarían probar su propia salida. Tampoco se han dado cuenta de que hay otros factores a considerar al realizar las pruebas. La respuesta del usuario de Quora a ¿Qué dificulta las pruebas de software?

Antecedentes: Soy un graduado de Ciencias de la Computación e Ingeniería Informática que trabaja en el campo de Garantía de Calidad de software.

Seguramente es tan importante, pero generalmente requiere más perseverancia y paciencia que habilidad. El control de calidad requiere una gran cantidad de repeticiones de prueba, siguiendo todas las rutas posibles del usuario, a veces una gran cantidad de iteraciones.

En mi experiencia, lo más importante en el desarrollo de aplicaciones es la prueba.
Debe comprender que un proyecto puede ser costoso sin límites si necesita hacer un trabajo que ya se realizó (retrabajo).
Los dos tipos de retrabajo es el cambio de alcance (cuando el usuario cambia los requisitos) y cuando el producto falla por falta de control de calidad.
Debe tener mucha paciencia para usar y reutilizar la aplicación una y otra vez tratando de encontrar errores para que el control de calidad sea alto. También necesitará habilidades porque puede automatizar la prueba con muchas herramientas o utilizar un sistema que rastree los errores y la importancia de cada uno de ellos.
Si no conoce tan bien la industria de TI, imagine si compra un automóvil. Imagínese si compra un nuevo Honda Civic, la última edición, y dos semanas después el Honda “descubrió” (en muchas ocasiones fue el usuario el que descubrió) una falla en el sistema del automóvil y el automóvil debe ser retirado del mercado.
Por lo tanto, se enojará porque compre un automóvil costoso y no conozca los flujos del automóvil. En este momento podría estar muerto usando un automóvil con un “sistema de falla”.

Ahora no confías en Honda y serás cauteloso cuando vuelvas a tener el auto nuevo.

En la industria del software es casi lo mismo, a la gente le gusta el software más seguro y estable. No quiero perder dinero porque el software tiene peros que no es mi culpa (me refiero al usuario).
El software más estable y eficiente es el más feliz que todos estarán. ¡Su gerente y el dueño de la compañía porque gastan menos dinero, el usuario con un producto de alta calidad y usted porque su trabajo es increíble!

Las pruebas de calidad son una parte muy importante de cualquier negocio, debido al mundo competitivo de hoy. Aquí hay algunos beneficios de las pruebas de control de calidad

1. Las pruebas ayudan a lanzar productos sin defectos

2. La garantía de calidad adecuada garantiza una entrega más rápida del software de calidad

3. Soluciones de prueba de respuesta rápida al utilizar las mejores prácticas de prueba y ofrece una mayor estabilidad y un mayor rendimiento.

El control de calidad / pruebas es tan importante como el desarrollo de cualquier software. El control de calidad realiza el proceso de validación y verificación del proceso. Esto ayuda a mantener la calidad del proyecto / software antes de que llegue al usuario final. Durante las pruebas, tiene que pasar por cierto proceso, como las pruebas funcionales, las pruebas de rendimiento, las pruebas de automatización, que cualquier empresa de servicios qa tiene que validar. Una vez que se pasan todas las pruebas, solo entonces se valida para las versiones. Sin pruebas, ningún proyecto / software se libera y, en caso de que se encuentre algún defecto, es muy costoso solucionarlo.

Por lo tanto, el desarrollo es tan importante como QA / Testing para cualquier proyecto. Espero, esto responde tu respuesta.

La calidad es tan importante como la funcionalidad cuando se trata de software. Es posible que desee leer más sobre esto en mi blog aquí:

¿Qué es el aseguramiento de la calidad y por qué lo necesito? por Carl Alston en Gear Inc

Creo que la gerencia podría poner a los evaluadores en roles de salarios bajos a tiempo parcial un poco más y contratar a más desarrolladores intermedios / senior más, por lo tanto, la percepción de una entrevista más fácil.