Puede que no esté lo suficientemente familiarizado con esta práctica, pero por lo general no pienso en las versiones alfa y beta como pruebas "posteriores" al lanzamiento. Para mí, las pruebas posteriores al lanzamiento se aplican a cosas como parches y otras actualizaciones. Si el software se ha lanzado al cliente para uso general, entonces ya no es realmente una versión alfa o beta, sino una versión inicial poco probada y potencialmente inestable. "Lanzar" una versión alfa o beta, por ejemplo, a un ejecutivo para que la pruebe, todavía se considera una versión previa al lanzamiento. ¿Me equivoco? Ham Pastrami ( discusión ) 21:00, 3 abril 2008 (UTC)
La prueba de software es el proceso para encontrar la corrección y los defectos de una aplicación de software. —Comentario anterior sin firmar añadido por 122.167.109.27 (discusión) 04:52, 7 de junio de 2008 (UTC)
Parece que la gente se olvida de que la prueba beta no es, de hecho, una función del grupo de pruebas. La prueba beta es una función de marketing para probar las características del producto en relación con lo que los usuarios a los que se dirige quieren o desean que haga el producto. No tiene como objetivo encontrar errores de desarrollo o de programación reales. —Comentario anterior sin firmar añadido por 205.225.192.66 ( discusión ) 16:48, 6 enero 2009 (UTC)
Algunas partes del proceso de prueba no tienen nada que ver con el ejercicio, por lo que cambié el título.
Dicho esto, necesito hacer algo de ejercicio, así que me voy. ;-) -- Pashute ( discusión ) 11:10 25 jun 2008 (UTC)
Prueba - Proceso de poner a prueba un sistema o un componente de un sistema para verificar que satisface los requisitos especificados y detectar errores. [en DO-178 CONSIDERACIONES DE SOFTWARE EN LA CERTIFICACIÓN DE SISTEMAS Y EQUIPOS AÉREOS] Thread-union (discusión) 17:25 4 jul 2008 (UTC)
Uno de los puntos bajo el título "Controversia" dice "...y en su mayoría aún se adhieren a CMM". ¿Qué es CMM? No se menciona este acrónimo antes y no hay antecedentes obvios en el punto. Mcswell ( discusión ) 00:49 13 ago 2008 (UTC)
Agregué un enlace al artículo de CMMI y cambié "CMM" por "CMMI" NoBot42 (discusión) 20:00, 21 de agosto de 2008 (MEZ)
Las referencias a CMMI parecen estar fuera de lugar. CMMI define las pautas de mejora de procesos independientemente del modelo de desarrollo utilizado (sea ágil, en cascada o cualquier otro). Esta "controversia" está creando una falsa dicotomía entre el desarrollo ágil y la madurez del proceso. No hay nada inherente a CMMI que impida su implementación en un entorno ágil. El conflicto entre "ágil" y "tradicional"/en cascada es que los métodos ágiles enfatizan las pruebas continuas, mientras que el método tradicional consistía en comenzar las pruebas solo al final del proceso de desarrollo. 76.164.8.130 ( discusión ) 22:24 21 nov 2008 (UTC)
---
Los comentarios anteriores sobre CMMI son correctos. El objetivo de CMMI es garantizar que el proceso se gestione y no prescribe ninguna mecánica sobre cómo realizar las funciones. En el mejor de los casos, proporciona ejemplos, pero esos ejemplos sirven más para ilustrar lo que significan para un área de proceso en particular que para prescribir cómo hacerlo. Al implementar un buen proceso ágil, por supuesto que abordará la mayoría de las disciplinas que se detallan en CMMI. Es cierto que el gobierno de los EE. UU. a menudo exige procesos que cumplan con los niveles 2 o 3 de CMMI, pero generalmente dejan la implementación de ese proceso a la empresa con la que tienen el contrato. Muchas empresas están aprendiendo el valor de aplicar procesos ágiles a CMMI. El gobierno de los EE. UU. puede imponer su implementación de procesos a una empresa, pero esa no es la norma.
Uno de los principales mecanismos que utilizan todos los procesos ágiles para mitigar el riesgo de los costes asociados a los cambios en el desarrollo de la aplicación es el de las iteraciones estrictas. Básicamente, se divide el trabajo en iteraciones de una o dos semanas en las que se hace la especificación hasta la integración, y las pruebas se realizan después de una iteración. Los costes de los requisitos, el diseño o la implementación incorrectos se reducen esencialmente a niveles muy manejables. Eso es lo que los convierte en ágiles. 137.100.53.254 (discusión) 20:17 16 abr 2009 (UTC)
--- Creo que aquí es necesario centrarse más en la automatización de pruebas. Cuando los defensores del desarrollo ágil recomiendan que se realicen todas las pruebas al 100 %, a menudo quieren decir "Quiero tener una cobertura de código del 100 % con las pruebas unitarias que estamos ejecutando". Incluso si se tiene una cobertura de código del 100 %, todavía hay mucho margen de error (errores de usabilidad, errores de integración, etc.). Si existe alguna forma de automatizar las pruebas de usabilidad, no la conozco.
¿Por qué es importante esto? Hay muchos PHB (jefes con cabeza puntiaguda) desinformados que escuchan a los vendedores de herramientas de automatización de software y creen que las herramientas de reproducción de registros permitirán a su equipo de control de calidad automatizar por completo sus pruebas de caja negra. Alguna mención de este "aceite de serpiente" en un medio en evolución y muy respetado como Wikipedia podría poner un freno a las expectativas poco razonables de este tipo. También debería hacerse una distinción clara entre la automatización de la interfaz gráfica de usuario (que está sujeta a distintos grados de fragilidad y requiere tanto o más tiempo para su mantenimiento que para escribir las pruebas iniciales: el argumento en contra de la automatización) y la automatización de pruebas unitarias (que normalmente requiere menos mantenimiento que la automatización de la interfaz gráfica de usuario).
(Antes de seguir con esto, creo que alguien debería proporcionar citas que muestren algunos defensores destacados de Agile que , de hecho, proponen una cobertura del 100%. Estoy absolutamente seguro de que ninguno de los que he conocido en la vida real lo hace , y algunos de ellos se irritan mucho con esta afirmación, por lo que no estoy convencido de que toda esta idea no sea un concepto erróneo/malentendido popular. 82.71.32.108 ( discusión ) 01:12, 10 de febrero de 2009 (UTC))
--
La cobertura del 100% se suele citar para pruebas unitarias , y no para todas las pruebas de un sistema. En el mejor de los casos, la cobertura del 100% es un objetivo, pero puede no ser factible debido a las limitaciones de la herramienta de cobertura u otras circunstancias atenuantes. Muchos equipos ágiles no emplean el desarrollo guiado por pruebas (que es solo una aplicación de los procesos ágiles), por lo que no siempre miden la cobertura de las pruebas. De los que lo hacen, una cobertura del código del 100% no significa necesariamente que se hayan probado el 100% de los casos. [1] 137.100.53.254 (discusión) 20:14, 16 de abril de 2009 (UTC)
--
Pruebas manuales vs. automatizadas Algunos autores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación.[47] Otros, como los defensores del desarrollo ágil, recomiendan automatizar el 100% de todas las pruebas. Más en particular, el desarrollo basado en pruebas establece que los desarrolladores deberían escribir pruebas unitarias del tipo x-unit antes de codificar la funcionalidad. Las pruebas pueden considerarse entonces como una forma de capturar e implementar los requisitos.
--
"¿Los testers deberían aprender a trabajar en condiciones de incertidumbre y cambio constante o deberían apuntar a la 'madurez' del proceso?" Esta misma cita del enfoque "Agile vs. Traditional" es una interpretación errónea. Básicamente, la única diferencia es cuando los testers se involucran en el ciclo de vida del software. Con el enfoque tradicional, los testers no se involucran hasta que el software está 100% completo (se han satisfecho todos los requisitos). Con los enfoques ágiles e iterativos, los testers se involucran tan pronto como se realiza una iteración. Las metodologías ágiles tienen iteraciones semanales o quincenales, lo que significa que las pruebas comienzan en la segunda o tercera semana de desarrollo. Los testers aumentan la cobertura de sus pruebas para que coincidan con los requisitos (o historias de usuario como los agilistas tienden a llamarlos) que se desarrollaron en ese momento. El beneficio es que cuando un proyecto ágil ha alcanzado la etapa de 100% de funcionalidad completa, la mayoría de los errores ya se han detectado y solucionado.
Los procesos ágiles son maduros y tienen poco que ver con trabajar en condiciones de incertidumbre y cambio constante. Tienen que ver con ciclos de iteración ajustados para que cuando el cliente necesite que el equipo vuelva a centrar sus esfuerzos, tenga la capacidad de hacerlo. No olvidemos también que hay otros procesos maduros que adoptan muchos de los mismos principios, como el Proceso Unificado Racional (RUP) y otras metodologías iterativas en las que el ciclo de requisitos→diseño→construcción→prueba→mantenimiento se repite varias veces antes de que el proyecto esté 100% completo. 72.83.188.248 (discusión) 02:26 20 abr 2009 (UTC)
"Las pruebas basadas en especificaciones son necesarias pero insuficientes para protegerse contra ciertos riesgos. [16]". Esta frase es completamente irrelevante, porque
Supongo que esta frase sólo sirve para introducir un enlace al autor. Por eso la elimino. —Comentario anterior sin firmar añadido por 80.219.3.124 ( discusión ) 18:20, 21 de agosto de 2008 (UTC)
Las métricas para el esfuerzo de encontrar y corregir errores son interesantes. Las he visto muchas veces. Se me ocurrió que la consecuencia es que es xx veces más fácil introducir errores en las fases de requisitos y arquitectura . ¿Hay alguna literatura al respecto? Es decir, ¿qué es causa y qué es efecto? Muchas veces, parecen ser utilizadas por quienes están acostumbrados a un método en cascada para justificar la especificación excesiva de las cosas. 69.77.161.3 (discusión) 20:50, 19 de noviembre de 2008 (UTC)
Probablemente, la marca registrada sea un uso inapropiado; la referencia aquí hace que sea un anuncio. Tedickey ( discusión ) 01:16 30 nov 2008 (UTC)
De otro tester de software, deja de inventar cosas como lo has hecho en el artículo sobre pruebas de software . Estás inventando términos y conceptos. Si no dejas de hacerlo, consideraré tus ediciones sin fuentes como vandalismo y te denunciaré. Por ejemplo, ningún libro de mi biblioteca menciona "pruebas optimistas". Parece que estás definiendo las pruebas positivas y negativas. Nada más. Les estás dando términos elaborados, uno de los cuales entra en conflicto con otro término. Tus elaboraciones sobre pruebas destructivas , que tienen un artículo en Wikipedia, son incorrectas. Por favor, deja de elaborar necesariamente los términos. -- Walter Görlitz ( discusión ) 06:34, 21 de julio de 2009 (UTC)
"ad hoc testing should be limited belies your misunderstanding of its use". En el artículo se decía que las pruebas en general, y más aún las pruebas ad hoc y la creatividad, pueden descubrir muchos errores, y nadie los descubre. ¿No estás de acuerdo con eso "this easily tends to be endless, costly and no result giving." ? El proyecto siempre ha tenido una financiación limitada, se debe aplicar el principio de Pareto, por lo que también las pruebas "creativas" ad hoc deben estar limitadas en el tiempo y el alcance. Podrías probar una determinada parte de un software para siempre , por lo que necesita un límite: Y esto se establecerá de forma realmente artificial, sí. ... Me presionaron muchas veces para que hiciera una "estimación de tiempo profesional-experto", incluso sin ninguna información disponible todavía. ¿Es esto con lo que no estás de acuerdo?"don't always use positive test cases"pruebas : se pueden construir como preguntas, como "haz esto, ¿aparecerá esto?", con la expectativa de que (a) aparezca / b) no aparezca) sea correcto, por lo que la prueba puede pasar o fallar en el evento "apareció". Sí, ambos lo sabemos.Buscando una definición clara del término completitud del código, me topo con este pasaje. Claramente, la primera oración es incorrecta: el párrafo se refiere a la completitud del código de prueba, no al código que se está probando, aunque este último es una de las cosas que se están probando. Rp ( discusión ) 11:16 18 ago 2009 (UTC)
He hecho una pequeña modificación a la definición inicial. La definición era: "'Prueba de software' es una investigación empírica realizada para proporcionar a las partes interesadas información sobre la calidad del producto o servicio que se está probando, con respecto al contexto en el que se pretende que funcione". He quitado "con respecto al contexto en el que se pretende que funcione" porque creo que es confuso y limita innecesariamente el alcance. La gente suele utilizar los productos de maneras muy diferentes a la intención del fabricante. A menudo tiene todo el sentido probar el comportamiento de un producto en usos previsibles o en contextos previsibles, no sólo en los previstos (pensemos en productos críticos para la vida, por ejemplo). CemKaner (discusión) 15:39 29 dic 2009 (UTC)
Hay una definición muy clara de "Pruebas de software" en el Glosario estándar IEEE de terminología de ingeniería de software, IEEE Std 610.12-1990 (¡de pago!), y cito:
- "El proceso de operar un sistema o componente bajo condiciones específicas, observando o registrando los resultados y haciendo una evaluación de algún aspecto del sistema o componente"
- "(IEEE Std 829-1983) El proceso de analizar un elemento de software para detectar la diferencia entre las condiciones existentes y las requeridas (es decir, errores) y para evaluar las características de los elementos de SW".
De manera más simple, en "Siete principios de las pruebas de software" (Bertrand Meyer (ETH Zürich y Eiffel Software) en: “IEEE Computer”, agosto de 2008, págs. 99-101 (¡de pago!), se da la definición simple:
"Probar un programa es intentar que falle."
El ISTQB (International Software Testing Qualifications Board) no ofrece una definición adecuada de prueba (en particular, no se puede encontrar ninguna definición en el "Glosario estándar de términos utilizados en pruebas de software versión 2.0 por el ISTQB"), pero amplía el significado de manera informal para incluir lo que ellos llaman "pruebas estáticas" en complemento a las "pruebas dinámicas", que son actividades como revisiones, inspecciones de código y análisis estático y que generalmente se incluirían en el diseño y la gestión de calidad (creo que más poder para ellos). La siguiente definición informal se da en el "Programa de estudios de nivel básico del ISTQB":
Las actividades de prueba existen antes y después de la ejecución de la prueba. Estas actividades incluyen la planificación y el control, la elección de las condiciones de prueba, el diseño y la ejecución de los casos de prueba, la comprobación de los resultados, la evaluación de los criterios de salida, la elaboración de informes sobre el proceso de prueba y el sistema en prueba, y la finalización o finalización de las actividades de cierre una vez finalizada una fase de prueba. Las pruebas también incluyen la revisión de documentos (incluido el código fuente) y la realización de análisis estáticos.
En particular, en "Point/Counterpoint - Test Principles Revisited" (Bertrand Meyer (ETH Zürich) vs. Gerald D. Everett (American Software Testing Qualifications Board), “IEEE Software”, agosto de 2009, págs. 62-65 (¡de pago!), leemos lo siguiente del Sr. Meyer:
"El señor Everett y el ISTQB amplían la definición de pruebas para cubrir esencialmente todo el aseguramiento de la calidad. En ciencia, uno es libre de usar cualquier término, con una definición precisa, para denotar cualquier cosa, pero no tiene sentido contradecir la práctica establecida. La definición del ISTQB va más allá de las técnicas dinámicas comúnmente conocidas como pruebas para abarcar las estáticas. Cientos de publicaciones discuten el análisis estático, incluidas las pruebas, frente a las pruebas. Tales comparaciones son de gran relevancia (incluso para mí como el creador, junto con Yuri Gurevich, de las conferencias Tests and Proofs, http://tap.ethz.ch), pero las diferencias siguen siendo claras. Pregúntele a los profesionales o investigadores sobre las pruebas; la mayoría describirá las técnicas dinámicas. Si el ISTQB quiere ampliar su alcance al aseguramiento de la calidad, debería cambiar su nombre, no tratar de redefinir una terminología que tiene décadas de antigüedad".
78.141.139.10 (discusión) 17:27 19 mar 2013 (UTC)
Estoy de acuerdo con eso. Meyer claramente quería una "definición básica" breve y concisa que ciertamente no pretendía cubrir todos los aspectos de las pruebas. Aquí está el contexto, del artículo citado anteriormente
La única conexión incontrovertible es negativa, una falsificación en el sentido popperiano: un test fallido nos da evidencia de falta de calidad. Además, si el test anterior ha sido aprobado, indica una regresión y señala posibles problemas de calidad en el programa y en el proceso de desarrollo. La cita más famosa sobre el testing lo expresa de forma memorable: “El testing de programas”, escribió Edsger Dijkstra, “puede utilizarse para mostrar la presencia de errores, ¡pero nunca para mostrar su ausencia!”.
Menos conocido (y probablemente no pretendido por Dijkstra) es lo que esto significa para los testers: la mejor autopromoción posible. Sin duda, cualquier técnica que descubra fallos es de gran interés para todos los “stakeholders”, desde los directivos hasta los desarrolladores y los clientes. En lugar de una acusación, deberíamos entender esta máxima como una definición de testing. Aunque es menos ambiciosa que proporcionar “información sobre la calidad”, es más realista y directamente útil.
Principio 1: Definición Probar un programa es intentar hacerlo fallar.
Esto mantiene el proceso de prueba enfocado: su único objetivo es descubrir fallas al provocar fallas. Cualquier inferencia sobre la calidad es responsabilidad del control de calidad, pero está más allá del alcance de las pruebas. La definición también nos recuerda que las pruebas, a diferencia de la depuración, no se ocupan de corregir fallas, sino solo de encontrarlas.
78.141.139.10 (discusión) 17:15 22 mar 2013 (UTC)
En el apartado “Métodos de prueba” leemos lo siguiente:
Pruebas estáticas vs. pruebas dinámicas
Existen muchos enfoques para realizar pruebas de software. Las revisiones, los recorridos o las inspecciones se denominan pruebas estáticas, mientras que la ejecución real del código programado con un conjunto determinado de casos de prueba se denomina pruebas dinámicas. Las pruebas estáticas se pueden omitir y, lamentablemente, en la práctica, a menudo se hace. Las pruebas dinámicas se llevan a cabo cuando se utiliza el propio programa. Las pruebas dinámicas pueden comenzar antes de que el programa esté 100 % completo para probar secciones particulares del código y se aplican a funciones o módulos discretos. Las técnicas típicas para esto son el uso de stubs/drivers o la ejecución desde un entorno de depuración.
Las pruebas estáticas implican verificación, mientras que las pruebas dinámicas implican validación. Juntas, ayudan a mejorar la calidad del software.
El uso no estándar de "Pruebas dinámicas" y "Pruebas estáticas" proviene directamente del programa de estudios del ISTQB. La frase "Las pruebas estáticas se pueden omitir y, lamentablemente, en la práctica, a menudo se hace" no tiene ningún sentido, porque las "pruebas estáticas" pertenecen al diseño, la gestión del ciclo de vida y el control de calidad. No son pruebas. ¿Se pueden dejar de lado? ¿Lo son? ¿Es desafortunado? La respuesta es "depende". Por supuesto, hacerlo, si el tiempo y el dinero lo permiten, ayuda a mejorar la calidad del software, de eso se trata.
Y luego:
"Las pruebas estáticas implican verificación, mientras que las pruebas dinámicas implican validación. Juntas, ayudan a mejorar la calidad del software".
¡NO! En la página de Wikipedia sobre V&V leemos:
Validación. La garantía de que un producto, servicio o sistema satisface las necesidades del cliente y otras partes interesadas identificadas. A menudo implica la aceptación y la idoneidad por parte de los clientes externos.
Verificación. Evaluación de si un producto, servicio o sistema cumple o no con una reglamentación, requisito, especificación o condición impuesta. Suele ser un proceso interno.
Por lo tanto, las denominadas "pruebas estáticas" se aplican tanto a la validación como a la verificación. Las denominadas "pruebas dinámicas" se aplican sin duda a la verificación ("¿cumple los requisitos enumerados?"), pero en un grado mucho menor a la validación.
Conclusión: es necesario reescribir el código. Se debe aclarar la diferencia entre "estático/dinámico" y "prueba simple", ya que es muy confuso.
78.141.139.10 (discusión) 17:32 22 mar 2013 (UTC)
Hola, he visto que has eliminado mi subsección sobre pruebas de software. No sabía que no se podían añadir a Wikipedia artículos que no se habían publicado anteriormente. ¿Qué se considera "publicado anteriormente"?
Lo he publicado en: http://experiencesonsoftwaretesting.blogspot.com/2010/01/braguet-testing-discovery-of-lucas.html por lo que ya no es material inédito. -- Diego.pamio ( discusión ) 15:43 5 ene 2010 (UTC)
¿Tiene sentido? Por favor háganmelo saber.
La discusión sobre la certificación me cita dos proposiciones.
Respecto del primero, he argumentado a menudo que la ingeniería de software (incluidas las pruebas) no está preparada para la LICENCIA porque carecemos de un cuerpo de conocimientos aceptado. (Véase, por ejemplo, John Knight, Nancy Leveson, Lori Clarke, Michael DeWalt, Lynn Elliott, Cem Kaner, Bev Littlewood y Helen Nissenbaum. "Grupo de trabajo de la ACM sobre licencias de ingenieros de software que trabajan en software crítico para la seguridad: informe preliminar, julio de 2000. Véase también http://www.acm.org/serving/se_policy/safety_critical.pdf.) Sin embargo, la certificación no es una licencia. Podemos certificar a alguien como competente en el uso de una herramienta, la aplicación de una técnica o el dominio de un conjunto de conocimientos sin afirmar también que esa es la mejor herramienta, la técnica más aplicable o el conjunto de conocimientos "correcto" (o el único válido) (o el universalmente aceptado). Creo que las certificaciones actuales afirman demasiado, que tergiversan el estado del conocimiento y el acuerdo en el campo y, al hacerlo, varias de ellas promueven una mentalidad estrecha e ignorante que perjudica al campo. Pero se trata de un problema de especificidades, un problema de estas certificaciones particulares.
En cuanto a lo segundo, no he dicho que la certificación NO PUEDA medir estas cosas. Por ejemplo, mire la certificación de nivel Expert de Cisco . La veo como un claro ejemplo de certificación de habilidad. De manera similar, no veo ninguna razón para argumentar que NO PODEMOS medir la productividad o el conocimiento práctico de un programador o un evaluador. Sin embargo, creo que las certificaciones actuales NO intentan medir estas cosas, o que cualquiera podría argumentar razonablemente que cualquiera de estas certificaciones hace un trabajo creíble al realizar tales mediciones. CemKaner (discusión) 22:30 9 abr 2010 (UTC)
El retorno de la inversión (ROI) es un término que suele malinterpretarse. Este término puede volverse aún más complejo cuando se mide el retorno de la inversión en pruebas de software.
¿Cómo evaluar el ROI de las pruebas de software y cómo mejorarlo?
http://blogs.msdn.com/b/robcaron/archive/2006/01/31/520999.aspx
http://www.mverify.com/resources/Whats-My-Testing-ROI.pdf NewbieIT ( discusión ) 03:53 10 jun 2010 (UTC)
El encabezado "CMMI o cascada" era completamente incorrecto. Ni el Modelo de Madurez de Capacidades para Software (SW-CMM), ni el CMM para Ingeniería de Sistemas (EIA-731) ni el Modelo de Madurez de Capacidades Integrado (CMMI) han exigido nunca el ciclo de vida en cascada. De hecho, muchos de los autores originales del CMM han dado conferencias sobre el tema de cómo la cascada se originó a partir de un discurso mal citado y malinterpretado de Winston Royce en 1973, y por lo tanto, podría decirse que nunca fue un ciclo de vida legítimo en su interpretación más estricta. Los ciclos de vida en espiral, incremental, iterativo, OOPS, sushi, fuente, etc. son todos ciclos de vida que pueden ser la base para la ejecución de proyectos y pruebas, y todos pueden usarse para abordar las prácticas requeridas en el CMMI. Vic Basily ha escrito un excelente artículo en el que analiza cómo los enfoques de prueba de todo al final no son "tradicionales" y cómo los enfoques incrementales/iterativos para el desarrollo y las pruebas de software han existido desde que existe la industria. El enfoque de "probar primero" promovido por los métodos ágiles es en realidad un resurgimiento de disciplinas de larga data. —Comentario anterior sin firmar agregado por 63.241.202.8 ( discusión ) 19:31, 9 agosto 2010 (UTC)
El título de esta sección era tan chocante que tuve que detenerme y ver si alguien había planteado el tema. Me alegra ver que alguien lo haya hecho. El primer autor de arriba tiene toda la razón. El segundo... CMMI y cascada en realidad no sugieren cosas que sean en lo más mínimo similares. Este título parece haber sido escrito por alguien que no tiene la más mínima idea sobre CMMI. 65.201.123.212 ( discusión ) 17:16, 6 de mayo de 2013 (UTC)
Estoy de acuerdo con 65.201.123.212 y Walter Görlitz , CMMI es un modelo completamente diferente y lo que sería mejor referenciar aquí es TMMI y cómo se relaciona con el SDLC general. Esta sección debería debatir sobre Waterfall o Agile Sandelk ( discusión ) 11:00, 17 de diciembre de 2013 (UTC)
No soy un experto en la materia, por lo que me cuesta entender este concepto. ¿Por qué las pruebas automatizadas son mucho más caras? Una vez que tienes tu arquitectura de automatización en marcha, no veo costes adicionales... si estás realizando actividades de prueba como algo único, puedo ver que es caro, pero en un entorno en el que se realizan pruebas constantes, imagino que vale la pena la inversión. Cronax (discusión) 12:21 28 sep 2010 (UTC)
En realidad, discrepo un poco con Walter Görlitz en este punto. La automatización puede resultar más barata, pero tiene un retorno de la inversión muy alto y requiere un gran gasto inicial para pagar las herramientas correspondientes, los ingenieros que escriban los scripts y los desafíos adicionales que se enfrentarán, pero si se hace bien, después de 2 o 3 años la inversión se amortiza con creces, especialmente si se considera el tiempo que se ahorra con los esfuerzos de automatización. Este artículo debe analizar la automatización de manera más objetiva y destacar tanto los pros como los contras de manera más efectiva. Sandelk ( discusión ) 11:09, 17 de diciembre de 2013 (UTC)
¿Debería haber un nuevo punto de controversia: un equipo de pruebas independiente frente a un equipo de análisis empresarial que lleve a cabo las pruebas ? Estoy buscando información sobre esto y, dependiendo de los comentarios sobre este tema, es posible que se añada un nuevo punto de controversia. —Comentario anterior sin firmar añadido por Culudamar (discusión • contribuciones ) 12:21, 20 de octubre de 2010 (UTC)
En Yahoo!, una importante empresa de software con unos 15.000 empleados, los términos "Control de calidad" e "Ingeniería de calidad" se utilizan principalmente para hacer referencia a lo que en esta página se denomina Pruebas de software. Todas las pruebas, excepto las Pruebas unitarias, recaen en un equipo de Control de calidad, y los miembros de esos equipos tienen el título de Ingeniero de calidad como parte de sus puestos de trabajo. Esto me lleva a preguntarme: ¿la distinción que se hace aquí refleja la práctica de la industria? Puede ser que Yahoo! sea una excepción, o puede ser que el uso de la terminología haya cambiado. No sé lo suficiente sobre el tema como para decirlo, pero quería plantear la pregunta.
CopaceticOpus ( discusión ) 04:25 1 feb 2011 (UTC)
La definición no tiene ningún sentido: "La prueba de software es una investigación realizada para proporcionar a las partes interesadas información sobre la calidad del producto o servicio bajo prueba".
Bluh. No se puede ser más impreciso. ¿Por qué no decir "La prueba de software es una actividad con la que mucha gente gana dinero fácilmente sin siquiera entender los principios básicos de la razón, reuniéndose y gritando "¡Sí, nosotros también tenemos una profesión!"?
La "industria de pruebas de software" y el ISTQB son una religión que absorbe cualquier pensamiento decente. —Comentario anterior sin firmar añadido por 115.189.199.174 (discusión) 23:10, 22 de abril de 2011 (UTC)
Gracias, Walter.
Afirmo que no, porque no es una definición. Una definición debe distinguir el objeto definido del resto del universo, de lo contrario no es una definición. Demostraré este defecto reemplazando términos de la "definición" sin cambiar la semántica, y señalando en () para cada paso por qué es correcto:
"La prueba de software es una investigación realizada para proporcionar a las partes interesadas información sobre la calidad del producto o servicio bajo prueba".
<--> (las "partes interesadas" pueden ser cualquiera)
"La prueba de software es una investigación realizada para proporcionar información sobre la calidad del producto o servicio bajo prueba".
<--> ("calidad" no está definida y describe características arbitrarias)
"La prueba de software es una investigación realizada para proporcionar información sobre el producto o servicio bajo prueba".
<--> ("calidad" no está definida)
"La prueba de software es una investigación realizada para proporcionar información sobre el producto o servicio bajo prueba".
<--> ("producto o servicio" puede ser cualquier cosa)
"La prueba de software es una investigación realizada para proporcionar información sobre el objeto bajo prueba".
<--> ("prueba de software" es la actividad realizada)
"La prueba de software es una investigación realizada para proporcionar información sobre su objeto".
<--> ("investigación" es cualquier actividad que intenta revelar información sobre algo)
"La prueba de software es una investigación sobre su objeto".
<--> ("objeto" es cualquier cosa arbitraria)
"La prueba de software es una investigación sobre algo".
<--> ("algo" es una cosa indiferente)
"La prueba de software es una investigación".
<--> ("investigación" es cualquier actividad que intenta revelar información sobre algo, pero no hay nada especificado)
"La prueba de software es una investigación de todo".
<--> ("una investigación sobre todo" se centra únicamente en lo esotérico y lo exotérico)
"Las pruebas de software son una religión".
<--> ("religión" es irrelevante para la calidad del software, lo único que es relevante son las "pruebas de software")
"Las pruebas de software son irrelevantes".
<--> ("irrelevante" significa que no tiene relación con otras cosas)
"¡La prueba de software es!"
<--> (todo es)
"¡!"
Entonces: no hay ninguna definición. El artículo existente debería reemplazarse por un "!".
Un pesimista es alguien que dice la verdad demasiado pronto. —Comentario anterior sin firmar añadido por 115.189.239.224 (discusión) 09:15 3 may 2011 (UTC)
Gracias, WikiWilliamP. Me encantaría que lo intentaras. —Comentario anterior sin firmar añadido por 115.189.38.100 (discusión) 21:03, 3 de mayo de 2011 (UTC)
El artículo dice: "Las pruebas nunca pueden identificar por completo todos los defectos del software". Esto sería realmente malo si fuera cierto. Consideremos programas simples que se pueden verificar por completo para todas las entradas. En estos casos, el proceso de prueba puede asegurar que el algoritmo funciona como se espera a menos que el sistema operativo o el hardware fallen, o que los datos se corrompan por otras partes del software. Todas estas condiciones quedan fuera del alcance de la prueba de un solo algoritmo o conjunto de algoritmos. Sin embargo, por lo general el software es demasiado complejo para permitir una verificación completa o una prueba de corrección. Aun así, se pueden encontrar muchos errores mediante pruebas. Se podría decir que un error que no se puede encontrar es uno que no existe, si se dispone de tiempo suficiente para realizar pruebas (que puede ser mucho tiempo...). Si bien nunca se puede estar seguro de que se hayan encontrado todos los errores en un algoritmo mediante pruebas, a menos que se verifiquen todas las combinaciones de entrada/salida, es posible que se hayan encontrado todos los errores en el software. Por lo tanto, se requiere una redacción mucho más cautelosa aquí. Yo propondría decir: "Las pruebas aleatorias no pueden garantizar que se hayan encontrado todos los defectos del software". — Comentario anterior sin firmar añadido por ScaledLizard ( discusión • contribs ) 17:34 20 jun 2011 (UTC)
De eso se trata la "explosión combinatoria". 78.141.139.10 (discusión) 17:17 22 mar 2013 (UTC)
Su disputa parece deberse a una simple ambigüedad. "Las pruebas nunca pueden identificar por completo todos los defectos del software" puede interpretarse como
o
o algo intermedio, por ejemplo
Creo que la mayoría de la gente consideraría que la primera afirmación es falsa y la segunda, verdadera. La tercera afirmación parece la más cercana a lo que se pretende y creo que es difícil de refutar. Rp ( discusión ) 17:41 28 feb 2014 (UTC)
En presencia de hipótesis de prueba específicas, existen conjuntos de pruebas finitos de modo que, si la implementación bajo prueba (IUT) las supera todas, entonces es necesariamente correcta con respecto a la especificación considerada. Por ejemplo, es bien sabido que, si asumimos que el comportamiento de la IUT puede ser denotado por una máquina de estado finito determinista con no más de n estados, entonces el conjunto de pruebas (finito) que consiste en todas las secuencias de 2n+1 entradas consecutivas está completo (es decir, es sólido y exhaustivo). Es decir, si la IUT las supera todas, entonces sabemos con certeza que es correcta (consulte, por ejemplo, "Principios y métodos de prueba de máquinas de estado finito" de Lee y Yannakakis). Además, se ha demostrado la existencia de conjuntos de pruebas completos finitos para muchos otros conjuntos (muy diferentes) de hipótesis asumidas; consulte la jerarquía de dificultad de prueba en este artículo para obtener más detalles. Por lo tanto, la frase "Las pruebas nunca pueden identificar por completo todos los defectos del software" es falsa y debería reemplazarse por algo como "En ausencia de hipótesis de prueba adecuadas, las pruebas nunca pueden identificar por completo todos los defectos del software". Para explicar un poco esta adición y evitar controversias, tal vez se debería incluir un enlace a la sección de jerarquía de dificultad de las pruebas en este artículo justo después de la frase, de modo que podría ser algo como: "En ausencia de hipótesis de prueba adecuadas, las pruebas nunca pueden identificar por completo todos los defectos del software (aunque pueden existir conjuntos de pruebas completos bajo algunas hipótesis de prueba, consulte la jerarquía de dificultad de las pruebas a continuación)". Si nadie se opone a este cambio en unos pocos días, lo haré. --EXPTIME-complete ( discusión ) 20:00, 25 de agosto de 2014 (UTC)
Como nadie ha discutido mi punto en el párrafo anterior, he cambiado el texto por: “Aunque las pruebas pueden determinar con precisión la corrección del software bajo el supuesto de algunas hipótesis específicas (ver la jerarquía de dificultad de las pruebas a continuación), por lo general las pruebas no pueden identificar por completo todos los defectos dentro del software”. Creo que esta es una oración de consenso. Por un lado, muestra que las pruebas no pueden garantizar la corrección del software si no se pueden asumir algunas hipótesis específicas (un caso típico de hecho). Por otro lado, muestra que algunas hipótesis permiten la completitud en las pruebas. Tenga en cuenta que el poder de las hipótesis en las pruebas es relevante y vale la pena mencionarlo aquí porque, en cualquier campo, solo se puede obtener nuevo conocimiento si se asumen algunas hipótesis: los matemáticos necesitan asumir axiomas, los físicos necesitan asumir que las observaciones son correctas y que las “reglas universales” no cambiarán de repente en unos pocos minutos, etc. Las pruebas de software no son una excepción. Además, incluso cuando las pruebas no pueden garantizar la corrección del sistema (el caso típico), también se asumen implícita o explícitamente muchas hipótesis. --EXPTIME-complete ( discusión ) 8:56 28 ago 2014 (UTC)
No se menciona cómo se deben registrar las pruebas en cada categoría. Serían útiles algunas pautas generalmente aceptadas, como evaluador, fecha y hora, título, detalles, acción, resolución, etc. Depende de la categoría; por ejemplo, las pruebas de rendimiento y las pruebas de regresión son bastante diferentes.
También sería útil describir cómo resumir los resultados de manera continua para los desarrolladores y gerentes; dónde se encuentra el cronograma de pruebas, la proporción de problemas resueltos, los criterios de aceptación (no necesariamente un éxito del 100%). Todo esto es esencial para los gerentes. SombreGreenbul ( discusión ) 13:07, 20 de julio de 2011 (UTC)
A menudo, el software es portable entre plataformas, por ejemplo, entre Windows ME, Vista y 7. La prueba del software en las plataformas pertinentes debería ser una subsección dentro de las pruebas no funcionales. SombreGreenbul ( discusión ) 14:13 20 jul 2011 (UTC)
Moviendo esto desde mi página de discusión: Hola, no puedo entender tus ideas sobre las pruebas de caja gris. ¿Por qué estás revirtiendo mis ediciones? También estoy proporcionando referencias que pertenecen a mis ediciones relevantes. Solo compruébalo e infórmame dónde estoy equivocado. Pero, por favor, no deshagas mis ediciones. — Comentario anterior sin firmar agregado por Netra Nahar ( discusión • contribuciones ) 2011-09-12T17:52:40
"A veces, las versiones beta se ponen a disposición del público para aumentar el campo de comentarios a un número máximo de futuros usuarios. [cita requerida]" ¿Podría ampliarse esto? Esta es ahora una práctica bastante común para los sitios web y, por lo general, cuanto más grande sea el sitio, más larga será la duración de la prueba beta. ¡Google Mail estuvo en versión beta durante 5 años! Para las citas, ¿qué tal http://www.slate.com/articles/news_and_politics/recycled/2009/07/why_did_it_take_google_so_long_to_take_gmail_out_of_beta.html o incluso un artículo mucho más antiguo: http://www.zdnet.com/news/a-long-winding-road-out-of-beta/141230 — Comentario anterior sin firmar agregado por 86.19.211.206 (discusión) 15:19, 7 de octubre de 2011 (UTC)
¿Qué opinas sobre el uso del término "pruebas humanas" o "pruebas realizadas por humanos" en lugar de pruebas manuales? ¿Tiene sentido? Esto en contraste con las pruebas realizadas por máquinas, las pruebas realizadas por robots o las pruebas automatizadas.
Saludos. — Comentario anterior sin firmar añadido por Anon5791 ( discusión • contribs ) 22:21 14 oct 2011 (UTC)
Después de que Dave Gelperin y William C. Hetzel clasificaron en 1988 las fases y objetivos de las pruebas de software en las siguientes etapas, se incluye una lista que se extiende más allá de 1988. Es necesaria una mayor explicación. Jeblad ( discusión ) 20:28 27 dic 2011 (UTC)
Parece que las pruebas basadas en riesgos se han escrito sin tener en cuenta que probablemente sea mejor incluir una breve frase en este artículo, si fuentes independientes y fiables demuestran que se merece tal peso. En otras palabras, el artículo parece ser un neologismo , WP:POVFORK , y un poco de propaganda . ¿Puede alguien encontrar fuentes que justifiquen una breve mención en este artículo, o tal vez fuentes suficientes para mantener las pruebas basadas en riesgos como un artículo en sí mismo? -- Ronz ( discusión ) 03:15, 31 de enero de 2012 (UTC)
Este artículo no parece tener nada de eso. Habría problemas de sincronización, peligros, carreras y uso de semáforos o mutexes que, además de estar diseñados más o menos correctamente, necesitan ser probados. Habría problemas de productor rápido y consumidor lento y cómo esto es manejado por el sistema o por la aplicación. ¿Envío de punteros a datos compartidos, se hace y funciona? Habría problemas de prioridad de procesos o mensajes y manejo de inversión de prioridad. Y estos probablemente serían solo algunos de los factores que necesitarían ser probados. ¿Debería haber un capítulo separado sobre esto en el artículo? — Comentario anterior sin firmar agregado por Aclassifier ( discusión • contribuciones ) 12:07, 26 de marzo de 2012 (UTC)
¿Vale la pena mencionar esto? Puede que haya requisitos delineados en las normas (como IEC 61508 ), pero no se menciona la ética. ¿Cómo se trata o se prueba una situación que sería muy poco frecuente? ¿Cuáles serían las consecuencias? ¿Cuánto le contamos al usuario final qué se ha probado y qué no (en esta versión)? ¿Cómo respondemos a una pregunta? No sé mucho sobre esto, pero me parece relevante. ¿Debería haber un capítulo separado sobre esto? Øyvind Teig ( discusión ) 12:16 26 mar 2012 (UTC)
Hay dos problemas con la discusión de pruebas no funcionales:
-- AlanUS ( discusión ) 18:06 31 mar 2012 (UTC)
Toda la sección sobre "funcional" versus "no funcional" es errónea. La distinción a la que se alude es entre verificación ("¿Codificamos bien el producto?") y validación ("¿Codificamos correctamente el producto?").
El término funcional se refiere al código que es llamado por el código bajo prueba (CUT). El término integración se refiere al código que llama al CUT. Esa es probablemente la distinción más importante en todas las pruebas de software y ni siquiera forma parte del vocabulario de la mayoría de los programadores.
La razón por la que es tan importante es que la mayoría de las personas combinan pruebas funcionales y de integración . En realidad, eso es validación , aunque la mayoría de las personas llaman a todo ese conjunto pruebas de integración de forma perezosa. Es lo más difícil de depurar. Deberían realizar pruebas de integración sin pruebas funcionales falsificando el código que se llama mediante la CUT o utilizando una versión trivial de la CUT.
Mucha gente dice pruebas unitarias cuando se refiere a pruebas funcionales . Las pruebas unitarias adecuadas simulan el código llamado por la CUT de modo que solo se ejecuta la CUT.
-- Cdunn2001 (discusión) 17:58 7 jul 2013 (UTC)
Los casos de prueba positivos y negativos se redireccionan aquí, pero ninguno se explica en el artículo. -- Beland ( discusión ) 18:16, 5 de octubre de 2012 (UTC)==
Desde 2008 existe un artículo detallado sobre el software de pruebas de estrés, dedicado 100% al tema. Prueba de estrés (software) . La referencia aquí a ese artículo específico se ha revertido 2 veces al artículo muy general sobre pruebas de estrés . Ese es un artículo de amplio alcance que cubre hardware, software, finanzas (pruebas de estrés bancarias) y pronto puede cubrir pruebas de estrés médicas/humanas (cardíacas, de voz, de parto y alumbramiento, pruebas de estrés emocional, etc.). Parece no tener sentido que este artículo que está dedicado 100% al software no apunte directamente a Prueba de estrés (software) , ya que se sabe con certeza que el lector que lee aquí en detalle se centra en el software. Rick ( discusión ) 03:34, 25 de febrero de 2013 (UTC)
Lo anterior se refiere a revert1 y revert2. Donde en la página, Pruebas de software , el enlace:
Se ha revertido dos veces al modo más general:
Es necesario precisar qué se entiende por (it) en:
¿También es necesario precisar exactamente a qué se refieren estos () ?
Este artículo y otros artículos relacionados pueden estar sujetos a edición por parte de editores inexpertos como parte de un esfuerzo por mejorar la calidad de la información sobre el tema de las pruebas de software: http://weekendtesting.com/archives/3095
Por favor sea amable.
Cmcmahon ( discusión ) 22:45 5 sep 2013 (UTC) (Soy miembro del personal de WMF pero opero aquí no en mi capacidad oficial)
Creo que la monitorización (por ejemplo con nagios) es parte de las pruebas de software. El artículo actual de Wikipedia no trata este tema. Hay una sección sobre pruebas alfa y luego sobre pruebas beta. Hace mucho tiempo que los programas se escribían, luego se grababan en un CD/DVD y luego se vendían. Hoy en día, la mayoría del software está basado en servidores y los programadores pueden ocuparse del software durante su ejecución en vivo. Como "DevOps": observar los procesos es parte de las pruebas de software. No soy un hablante nativo, por eso no quieres escribir en el artículo real de la wiki. Pero tal vez alguien esté de acuerdo conmigo y pueda agregar algo al artículo real. — Comentario anterior sin firmar agregado por 89.246.192.60 (discusión) 19:47, 8 de noviembre de 2013 (UTC)
Creo que la pregunta "¿La monitorización es parte de las pruebas de software?" no tiene una respuesta definitiva, pero espero que todos estén de acuerdo: está **relacionada** con las pruebas de software. Por eso creo que se deberían incluir algunas frases sobre la monitorización (comprobaciones de Nagios) en la página. Hasta ahora soy demasiado nuevo en Wikipedia y no sé cómo empezar, pero si alguien empieza, me encantaría dar su opinión. Guettli ( discusión ) 07:25 6 nov 2015 (UTC)
En mi contexto, el monitoreo es parte de las pruebas. La referencia canónica (pero quizás no la mejor) es esta charla de hace una década de Ed Keyes, donde dice "Un monitoreo suficientemente avanzado es indistinguible de las pruebas" (enlace de video) Angryweasel ( discusión ) 23:18, 17 de noviembre de 2017 (UTC)
Soy un autor de software con más de 40 años de experiencia en pruebas. Este artículo es demasiado extenso para lo que es esencialmente un proceso "simple". La mayoría de las personas entienden para qué se usa un cuchillo y reconocerían herramientas de corte de diferentes tipos desde la edad de piedra hasta la actualidad. Un "probador" de la edad de piedra realizaría la tarea de "probar" su producto de la misma manera que un carnicero moderno. ¿La herramienta de corte hace lo que se supone que debe hacer? Si no, ¿por qué no? ¿Cómo se puede solucionar? El artículo diferencia la depuración de las pruebas a pesar del hecho de que la prueba es la forma más obvia de identificar errores. Creo que debería haber una sección de historia que identifique claramente en qué etapa progresó cada avance en las técnicas de validación manual o automática de programas. El presente artículo nos haría creer que hubo numerosas subdivisiones "arcaicas" de las pruebas de software desde el principio. Esto no es cierto. Ha habido cambios de paradigma en el arte de las pruebas y la depuración que se reflejan en las herramientas comerciales que han evolucionado para ayudar al progreso hasta el día de hoy. Hasta cierto punto, la gran cantidad de paradigmas de programación, lenguajes y plataformas de hardware ha obstaculizado el desarrollo de herramientas de prueba universales, pero el concepto de prueba asistida existe al menos desde los años 70 y se le ha restado importancia. Es un artículo verdaderamente terrible. — Comentario anterior sin firmar agregado por 81.154.101.27 (discusión) 09:44, 4 de enero de 2014 (UTC)
Los buenos programadores son vagos. Esa es al menos mi opinión. Sí, hay una gran cantidad de teoría... pero ¿cuál es el objetivo de este artículo? ¿Hacer un trabajo académico teórico profundo o dar una buena visión general? Para mí, la visión general es más importante que los detalles. También me gustaría un artículo mucho más breve. Si algunas partes necesitan explicaciones más detalladas, entonces se debe crear una nueva página. Por ejemplo, "pruebas de seguridad". Supongo que solo el 0,0001% de todos los desarrolladores trabajan en un entorno que necesita pruebas de seguridad. Sí, es importante para algunas personas, pero solo para muy pocas. PD: Hablo de "pruebas de seguridad". "Preocupaciones de seguridad" es otra cosa. Esto es algo que todos los desarrolladores deben hacer a diario. Guettli ( discusión ) 07:33, 6 de noviembre de 2015 (UTC)
El artículo afirma que "existen varios programas de certificación para respaldar las aspiraciones profesionales de los evaluadores de software y los especialistas en control de calidad. Ninguna certificación que se ofrece actualmente requiere que el solicitante demuestre su capacidad para evaluar software. Ninguna certificación se basa en un conjunto de conocimientos ampliamente aceptado", pero ¿cuál es la base real para afirmar eso? Sin duda, hay otros que no creen que esto sea cierto; véase, por ejemplo, ISTQB: "El esquema se basa en un conjunto de conocimientos (programas de estudio y glosario) y en reglas de examen que se aplican de manera uniforme en todo el mundo, y los exámenes y el material de apoyo están disponibles en muchos idiomas". Se agregó la cita necesaria-plantilla. Slsh ( discusión ) 15:34, 30 de enero de 2014 (UTC)
La prueba negativa es una forma de desambiguación. El significado del software se encuentra aquí, pero esta página no contiene la palabra "negativo". -- Dan Wylie-Sears 2 ( discusión ) 01:48, 11 de abril de 2014 (UTC)
El artículo necesita urgentemente una definición del término o un enlace a otro artículo en el que se defina. — Comentario anterior sin firmar añadido por 68.183.37.170 ( discusión ) 20:02, 21 de mayo de 2014 (UTC)
No es necesario tener acceso a registros o bases de datos para comprender un algoritmo o una estructura de datos interna y viceversa. Por lo tanto, no hay nada que realmente distinga las pruebas de caja gris de las de caja blanca o negra. — Comentario anterior sin firmar añadido por 68.183.37.170 ( discusión ) 20:02, 21 de mayo de 2014 (UTC)
¿Se trata de un nivel o de un tipo de prueba? Si la respuesta es "ambos", entonces las nociones de "nivel" y "tipo" se superponen y esas dos secciones deberían combinarse. — Comentario anterior sin firmar añadido por 68.183.37.170 ( discusión ) 20:02 21 may 2014 (UTC)
He eliminado la mayoría de las entradas en la sección de proveedores de certificación. Wikipedia es WP:NOTDIRECTORY y la sección se estaba llenando de spam con todas las entradas que carecían de artículos o fuentes secundarias. Si estas certificaciones de prueba son realmente proporcionadas por organizaciones notables, su inclusión debería estar respaldada por un artículo o una fuente WP:SECONDARY . Si no se pueden encontrar dichas fuentes, se vuelve imposible distinguir entre un servicio legítimo y una fábrica de certificación. De todas formas, Wikipedia no es una plataforma para publicidad, que es lo que esto significa. Creo que las pocas entradas restantes también deberían eliminarse, a menos que haya alguna objeción. Grayfell ( discusión ) 20:28, 6 de septiembre de 2014 (UTC)
El estudio del NIST no es una fuente creíble para la estimación económica de los costos de los defectos de software para la economía. Presenta resultados extraños, como "en promedio, un error de software menor tiene un costo de cuatro millones de dólares" o "los errores menores pueden costar más que los mayores" (ambos de la Tabla 6-11). Tiene tamaños de muestra irrazonablemente bajos -menos de 15 desarrolladores de software- y, aunque la parte del estudio dedicada a los usuarios tenía 179 más 98 encuestados, eso representa una tasa de respuesta deplorable que habría dado como resultado que el estudio se descartara en la mayoría de las publicaciones académicas. Lo más importante es que no se basa en ninguna medición interna real, sino en una encuesta de 25 minutos en la que se pidió a las personas que adivinaran cuánto le estaban costando los errores a su empresa.
Más detalles aquí: https://plus.google.com/u/1/+LaurentBossavit/posts/8QLBPXA9miZ — Comentario anterior sin firmar agregado por LaurentBossavit (discusión • contribuciones ) 14:32, 13 de septiembre de 2014 (UTC)
Me he dado cuenta de que los primeros 3 o 4 párrafos de la primera sección de esta página se repiten. Si lo lees, verás a qué me refiero. Realmente se podría limpiar. Lo haría con gusto, pero no quiero lanzarme y ocuparme de ello sin mencionarlo aquí primero, y como no tengo idea de cuánto tiempo puede llevar este proceso, probablemente alguien más querrá hacerlo, al menos si a alguien le importa cuán inteligente debe parecer el artículo, considerando el tema. — Comentario anterior sin firmar agregado por 184.78.188.225 (discusión) 03:50, 14 de septiembre de 2014 (UTC)
He observado que dos secciones utilizan exactamente las mismas oraciones cuando analizan dos tipos diferentes de pruebas:
¿Alguien que entienda mejor este tema podría aclararlo? — Ma y ast ( discusión ) 22:12 23 nov 2014 (UTC)
Creo que faltan pruebas consecutivas y deberían mencionarse en este artículo. -- Sae1962 ( discusión ) 14:59 16 jun 2015 (UTC)
Hola compañeros wikipedistas,
Acabo de agregar enlaces de archivo a un enlace externo en Software testing . Tómese un momento para revisar mi edición. Si es necesario, agregue después del enlace para evitar que lo modifique. Alternativamente, puede agregar para mantenerme fuera de la página por completo. Hice los siguientes cambios:{{cbignore}}{{nobots|deny=InternetArchiveBot}}
Cuando haya terminado de revisar mis cambios, configure el parámetro marcado a continuación como verdadero para informar a los demás.
Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulten la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}
Saludos. — cyberbot II Habla con mi dueño :En línea 16:54, 27 de agosto de 2015 (UTC)
Los cambios realizados por @ NoahSussman : fueron demasiados. La adición de fuentes fue buena, pero no todas cumplen con WP:RS . Elisabeth Hendrickson sí lo es, pero Kate Falanga no, y pasar de 73 referencias a 36 no es una mejora. Eliminar términos comunes como pruebas de caja negra y caja blanca es incomprensible. Es demasiado para revisarlo en una sola sesión. Walter Görlitz ( discusión ) 14:01, 15 de marzo de 2017 (UTC)
Walter Görlitz Sería bueno que consideraras el trabajo de Noah Sussman como algo en curso y lo criticaras o lo actualizaras punto por punto si fuera necesario, en lugar de revertir estos cambios en su totalidad. Esta página ha sido un desastre durante años, y ahora que finalmente alguien competente la está actualizando, la comunidad de pruebas de software agradecería todo el apoyo que Wikipedia pueda brindar. Si hace una diferencia, fui el líder de control de calidad en WMF durante unos tres años, y puedo asegurar que nadie en esta conversación es un títere. Cmcmahon ( discusión ) 18:16 15 mar 2017 (UTC)
Como recordatorio, no ha justificado su reversión de las ediciones de Noah, simplemente ha declarado que las revisiones no fueron, en su opinión, "útiles". ¿Qué revisiones específicas no fueron útiles? ¿Por qué? Si la mitad del contenido se ha movido a otras páginas, ¿se ha eliminado? ¿O simplemente se ha editado? Si se ha movido la mitad del contenido, ¿no cabría esperar que también se eliminara la mitad de las referencias?
El lenguaje que utilizas aquí "Lo estoy considerando", "Es demasiado para revisarlo en una sola sesión" recuerda mucho a WP:OWNBEHAVIOR . Por favor, recuerda WP:OWNERSHIP. — Comentario anterior sin firmar añadido por Cyetain ( discusión • contribuciones ) 19:34, 15 de marzo de 2017 (UTC)
Admito que hice modificaciones masivas para ver qué pasaba. Me solidarizo con cualquiera que quiera que su trabajo se fragmente en lo más pequeño que sea práctico :) Reharé las modificaciones en pequeños fragmentos. SIN EMBARGO, la "eliminación total" es INEXACTA Y EQUIVOCADA, ya que MOVÍ el contenido en cuestión a una nueva página, que está vinculada desde la ubicación anterior del contenido. Tengo la intención de aplicar este cambio nuevamente. NO SE TRATA DE LA ELIMINACIÓN DE LA PRUEBA DE CAJA BLANCA Y NEGRA, simplemente estoy cumpliendo con la caja "demasiado grande" que *encontré en su lugar* en la página. Estoy tratando de seguir las instrucciones existentes para mejorar Wikipedia y hacer la página más pequeña extrayendo el contenido de la lista en una página de "lista de cosas". Por lo tanto, espero no recibir rechazo por ese cambio cuando lo vuelva a implementar en un futuro cercano. Gracias y espero continuar la discusión / sus pensamientos / sus comentarios adicionales NoahSussman ( discusión ) 10:38, 16 de marzo de 2017 (UTC)
"73 referencias frente a 36 referencias no es una mejora", pero sí lo es si la mitad de las referencias son a material de marketing, material desactualizado, mal escrito o material que es las tres cosas a la vez. Como es el caso aquí. Demasiados enlaces poco fiables o de marketing en esta página son un serio problema de credibilidad. Sin embargo, ahora cuestionaré una referencia a la vez en lugar de intentar eliminar más en bloque. No más eliminaciones en bloque. Pero las referencias en esta página son un fracaso y las TERMINARÉ. NoahSussman ( discusión ) 10:45 16 mar 2017 (UTC)
"No estoy seguro de cómo una técnica puede volverse obsoleta" - bueno, creo que este es el quid de la cuestión con esta página. Toda la página se basa en una idea de Pruebas de Software que surgió hace décadas, mientras que las técnicas de desarrollo de software han evolucionado. Muchos de nosotros, los probadores de software, hemos ampliado/adaptado nuestros métodos durante la última década, y estoy de acuerdo con Noah en que son necesarios cambios importantes en todo el asunto. Entiendo la reticencia a descartar grandes partes de la página (y referencias) y espero que obtengamos una página mejor de esta discusión. Rutty ( discusión ) 15:00, 16 de marzo de 2017 (UTC)
I'd like to see some discussion of generative testing, supplemented by a link to the QuickCheck page. RichMorin (talk) 03:29, 28 September 2017 (UTC)
Does this section provide value or reference on software testing roles? I'm questioning whether it can be removed or merged into another section.
Furthermore, the list of "roles" in this section are just a snapshot of some software testing titles, and there are so many of these that I don't think listing a few of them would help any reader. — Preceding unsigned comment added by Angryweasel (talk • contribs) 23:22, 17 November 2017 (UTC)
I don't see a strong precedent for the date format in citations. I see things like "2012-01-13" and "July 1, 2009". Is there a preference? I think "July 1, 2009" is more readable. Faught (talk) 19:23, 21 November 2017 (UTC)
So I went with the US style that was prevalent in the body of the article. But perhaps you'd want to use ISO format only in the citations? Not sure whether you'd want to make it different just in the citations. Faught (talk) 00:47, 28 November 2017 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on Software testing. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.—InternetArchiveBot (Report bug) 08:17, 2 December 2017 (UTC)
How should we choose between American English or British English? Does the spelling on any related pages matter?
On Software testing I see American spellings like artifacts, behavior, and unrecognized, and British spellings like artefacts, grey-box, unauthorised, and organisational. Faught (talk) 20:57, 6 December 2017 (UTC)
{{Use American English|date=October 2024}}. Of course, this will change each month and year that it's on the talk page or in the archive because of the embedded formula. Walter Görlitz (talk) 01:58, 7 December 2017 (UTC)Can anyone identify what this reference is? "Regarding the periods and the different goals in software testing,[1]..." Perhaps the article they co-authored, "The Growth of Software Testing"? If we can't identify what this is referring to, we should delete the reference. Faught (talk) 18:24, 18 December 2017 (UTC)
References
There's a rather odd citation in the History section: Company, People's Computer (1987). "Dr. Dobb's journal of software tools for the professional programmer". Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116.
Can anyone intuit a title and author for this article? Faught (talk) 19:19, 20 December 2017 (UTC)
References
I published an edit to the Certifications section with several minor improvements, and adding certifications from the International Software Certifications Board (better known as QAI).
I deleted two of them: 1) Certified Quality Improvement Associate (CQIA), which is not specific to software, and 2) ISEB, which is not a certification, but hints at the fact that ISEB markets the ISTQB certifications already listed here. If there is any controversy about those deletions, let's add them back without losing the other changes.
The ISTQB offers a richer set of certifications than is indicated here, but the way they organize them makes it difficult to list all the variations as separate certifications. Maybe someone could find a good solution for this page.
One more thing - I want to delete the "Software testing certification types" information entirely. This is already covered at Certification#In_software_testing and doesn't need to be hashed out on the software testing page. Any objections?
Also, I want to consider moving most of the first paragraph to the Controversies section. I don't think it has a neutral point of view. Faught (talk) 22:20, 30 January 2018 (UTC)
I added a [citation needed] tag to the following line in the Testing Levels section:
"There are generally four recognized levels of tests: unit testing, integration testing, component interface testing, and system testing."
I do see a few web mentions (mostly from sites selling their wares) defining "the 4 levels" as unit, integration, system, and acceptance. I feel like that may be the better edit, but I'm not certain where the initial reference of those 4 levels comes from. I'll keep digging, but throwing it here in the meantime. For example, there's an explanation on the test-institute dot org website (coincidentally blocked by wikipedia) - but I don't want to reference a site that is focused on selling certifications. I've thumbed through my library of test books, but haven't found the original source yet.
I also found a reference to Component, integration, system, and acceptance testing in _Foundations of Software Testing ISTQB Certification_ by Rex Black and Dot Graham.
I am wondering (out loud) if anything about Testing Levels rises to the level of being worth mentioning in Wikipedia. Angryweasel (talk) 19:49, 3 April 2018 (UTC)
The blurb about outsourcing links to an article touting a particular firms services and offers little actual evidence about the claims, suggesting it be removed Sinfoid (talk) 02:52, 7 May 2018 (UTC)
we can find the tests to get overview and asked my students to this overview 103.228.159.104 (talk) 15:47, 6 December 2021 (UTC)
This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.
The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:08, 1 February 2023 (UTC)
User MrOllie has recently removed my contributions about the Testability Hierarchy arguing citation spam. I would like to ask a volunteer to review the relevance to this article of the Testability Hierarchy section existing before it was reverted by MrOllie at 22:27, 20 February 2024 (UTC). EXPTIME-complete (talk) 23:33, 20 February 2024 (UTC)
In particular, this is the text I would like to introduce again:
Based on the number of test cases required to construct a complete test suite in each context (i.e. a test suite such that, if it is applied to the implementation under test, then we collect enough information to precisely determine whether the system is correct or incorrect according to some specification), a hierarchy of testing difficulty has been proposed.[1][2] It includes the following testability classes:
It has been proved that each class is strictly included in the next. For instance, testing when we assume that the behavior of the implementation under test can be denoted by a deterministic finite-state machine for some known finite sets of inputs and outputs and with some known number of states belongs to Class I (and all subsequent classes). However, if the number of states is not known, then it only belongs to all classes from Class II on. If the implementation under test must be a deterministic finite-state machine failing the specification for a single trace (and its continuations), and its number of states is unknown, then it only belongs to classes from Class III on. Testing temporal machines where transitions are triggered if inputs are produced within some real-bounded interval only belongs to classes from Class IV on, whereas testing many non-deterministic systems only belongs to Class V (but not all, and some even belong to Class I). The inclusion into Class I does not require the simplicity of the assumed computation model, as some testing cases involving implementations written in any programming language, and testing implementations defined as machines depending on continuous magnitudes, have been proved to be in Class I. Other elaborated cases, such as the testing framework by Matthew Hennessy under must semantics, and temporal machines with rational timeouts, belong to Class II.
EXPTIME-complete (talk) 09:01, 21 February 2024 (UTC)
References
Estoy pensando en eliminar la sección Fallas y errores, ya que, aunque no está mal, está fuera de tema. También pienso eliminar el párrafo que dice "producto de software para el hogar", ya que también está muy fuera de tema.
@ Furkanakkurt8015 : quería etiquetarte porque vi que modificaste la sección de fallas recientemente. Espero que no te importe si la elimino. Stevebroshar ( discusión ) 20:27, 28 de abril de 2024 (UTC)