Sobre "bugs", fallos, errores y otra fauna

Siguiendo con el hilo de la terminología confusa, aquí tenemos otra muestra. Se trata de varios conceptos que se diferencian en pequeños matices y sobre los que no hay una definición exacta. En este aspecto cabe destacar que estos matices tienen que ver con el alcance de las consecuencias que cada término conlleva.

Como no hay una definición concreta de la mayoría de ellos, aquí dejo una recopilación de las definiciones que me han parecido más interesantes de cada uno de ellos. Creo que con esto, cada uno se podrá hacer una idea del significado y de por qué se usa un término y no otro en cada caso, etc.

Pido disculpas si la traducción del nombre de algunos conceptos no es del todo correcta o resulta un tanto extraña pero después de mucho buscar e investigar, creo que son las traducciones más adecuadas para lo que cada concepto representa.


ANOMALÍA

• [IEEE 1044] Cualquier comportamiento que se desvía de las expectativas basadas en las especificaciones de requerimientos, documentos de diseño, documentos de usuario, estándares, etc. o de la percepción y/o experiencia de alguien. Las anomalías se pueden encontrar (aunque no únicamente) durante revisiones, testeo, analisis, compilación o uso de productos de software o documentación aplicable.
• [COBUILD] Una regla o práctica que difiere de lo que es normal o usual y que es, por consiguiente, insatisfactoria.
• [ANSI] Cualquier cosa observada en la documentación o en el funcionamiento del software que se desvía de las expectativas basadas en productos de software previamente verificados o en documentos de referencia.
  

“BUG”

• [GCSSDT] Un error en un programa que hace que dicho programa funcione de un modo no deseado o imprevisto.
• [Wikipedia] Un error, defecto, equivocación, falla, fallo o “funcionalidad no documentada” en un programa de ordenador que evita que dicho programa funcione como es debido (por ejemplo, produciendo un resultado incorrecto).
• [Pham 2000] Un defecto de diseño que se manifestará cuando un objeto sea sometido al test apropiado.
  

CUELGUE

• [IEEE] La falla total y repentina de un sistema o componente.

DEFECTO

• Incumplimiento de los requerimientos o de la especificación funcional o del programa.
• [ISTQB] Un error en un componente o sistema que causa que dicho componente o sistema falle al ejecutar su funcionamiento requerido (por ejemplo, una sentencia o una definición de datos incorrecta). Un defecto, si se manifiesta en tiempo de ejecución, puede causar una falla del componente o sistema.
• [IEEE 610.12-1990] Una anomalía en un producto.
  

DESVIACIÓN

• Ver incidente.

ERROR

• [ISO] Una discrepancia entre un valor o una condición computados, observados o medidos y el valor o la condición verdaderos, especificados o teóricamente correctos.
• [ANSI]
1. La diferencia entre un valor o una condición computados, observados o medidos y el valor o la condición verdaderos, especificados o teóricamente correctos.
2. Un paso, proceso o definición de datos incorrecto. También: fallo.
3. Un resultado incorrecto. También: falla.
4. Una acción humana que produce un resultado incorrecto [After IEEE 610]. También: equivocación.

• [Krsul] Un error es una equivocación cometida por un desarrollador. Puede ser un error tipográfico, una confusión con las especificaciones, un malentendido sobre lo que hace una subrutina, etc. [IEEE 1990]. Un error puede conducir a uno o más fallos. Los fallos están localizados en el texto del programa.
• Un fallo en el sistema bajo testeo; normalmente, aunque no siempre, una equivocación al programar por parte del desarrollador.

EXCEPCIÓN

• [IEEE] Un evento que causa la suspensión de la ejecución normal de un programa.

FALLA

• [IEEE/ANSI] La incapacidad de un sistema o componente de llevar a cabo las funciones especificadas en los requerimientos.
• [After Fenton] Desviación real del componente o sistema de su función, servicio o resultado esperados.
• No funcionamiento o funcionamiento incorrecto de la función prevista de un producto. Una falla es, a menudo, la manifestación de uno o más fallos.

FALLO

• [ANSI] Un paso, proceso o definición de datos incorrecto en un programa de ordenador que hace que dicho programa funcione de un modo no deseado o imprevisto. Un paso, proceso o definición de datos incorrecto.
• [BCS SIGIST] La manifestación de un error en el software. Un fallo, si se produce en tiempo de ejecución, puede causar una falla.
• [Krsul] Un fallo es la diferencia entre un programa incorrecto y su versión correcta [IEEE 1990].
• Un defecto inherente en un producto que puede o no manifestarse, tal como un “bug” en el código.

INCIDENTE

• [After IEEE 1008] Cualquier evento ocurrido durante el testeo que requiere investigación.

EQUIVOCACIÓN

• Ver error.

PROBLEMA

• Ver defecto.

----------------------------------------------------------------------------

Continuing with the confused terminology, here we are another sample. They are some concepts that differ each others in little nuances and for which there is no accurate definition. In this sense, it worths mentioning that these nuances have to do with the scope of the consequences each concept implies.

Since there is no accurate definition for the great majority of them, here you are a compilation of definitions that I have considered as the most interesting for each one. I think that with this, everyone will have an idea of the meaning and why a particular term is used instead of other in each particular case, etc.


ANOMALY

• [IEEE 1044] Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation or use of software products or applicable documentation.
• [COBUILD] A rule or practice that is different from what is normal or usual and which is therefore unsatisfactory.
• [ANSI] Anything observed in the documentation or operation of software that deviates from expectations based on previously verified software products or reference documents.

BUG

• [GCSSDT] A fault in a program which causes the program to perform in an unintended or unanticipated manner.
• [Wikipedia] An error, flaw, mistake, failure, fault or “undocumented feature” in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result).
  
• [Pham 2000] A design flaw that will result in symptoms exhibited when an object is subjected to an appropriate test.

CRASH

• [IEEE] The sudden and complete failure of a computer system or component.

DEFECT

• Nonconformance to requirements or functional/program specification.
• [ISTQB] A flaw in a component or system that can cause the component or system to fail to perform its required function (e.g., an incorrect statement or data definition). A defect, if encountered during execution, may cause a failure of the component or system.
• [IEEE 610.12-1990] A product anomaly.

DEVIATION

• See incident.

ERROR

• [ISO] A discrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.
• [ANSI]
1. The difference between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.
2. An incorrect step, process or data definition. Also: fault.
3. An incorrect result. Also: failure.
4. A human action that produces an incorrect result [After IEEE 610]. Also: mistake.

• [Krsul] An error is a mistake made by a developer. It might be typographical error, a misleading of a specifications, a misunderstanding of what a subroutine does and so on [IEEE 1990]. An error might lead to one or more faults. Faults are located in the text of the program.
• A mistake in the system under test; usually but not always a coding mistake on the part of the developer.
  

EXCEPTION

• [IEEE] An event that causes suspension of normal program execution.

FAILURE

• [IEEE/ANSI] The inability of a system or component to perform its required functions within specified performance requirements.
• [After Fenton] Actual deviation of the component or system from its expected delivery, service or result.
• Non-performance or incorrect performance of an intended function of a product. A failure is often the manifestation of one or more faults.

FAULT

• [ANSI] An incorrect step, process or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. An incorrect step, process, or data definition in a computer program.
• [BCS SIGIST] A manifestation of an error in software. A fault, if encountered may cause a failure.
• [Krsul] A fault is the difference between incorrect program and the correct version [IEEE 1990].
• An inherent defect in a product that may or may not ever manifest, such as a bug in software code.

INCIDENT

• [After IEEE 1008] Any event occurring during testing that requires investigation.

MISTAKE

• See error.

PROBLEM

• See defect.

Referencias/References:

http://www.xqual.com/documentation/glossary.html
http://www.istqb.org/downloads/glossary-current.pdf
http://www.aptest.com/glossary.html
http://geekswithblogs.net/srkprasad/archive/2004/06/02/5795.aspx
http://sw-assurance.gsfc.nasa.gov/help/glossary.php
http://www.qatutor.com/glossary.html

Red S@Stenible

Consideramos imprescindible la retirada de la disposición final primera de la Ley de Economía Sostenible por los siguientes motivos:

1 -Viola los derechos constitucionales en los que se ha de basar un estado democrático en especial la presunción de inocencia, libertad de expresión, privacidad, inviolabilidad domiciliaria, tutela judicial efectiva, libertad de mercado, protección de consumidoras y consumidores, entre otros.

2 - Genera para la Internet un estado de excepción en el cual la ciudadanía será tratada mediante procedimientos administrativos sumarísimos reservados por la Audiencia Nacional a narcotraficantes y terroristas.

3 - Establece un procedimiento punitivo “a la carta” para casos en los que los tribunales ya han manifestado que no constituían delito, implicando incluso la necesidad de modificar al menos 4 leyes, una de ellas orgánica. Esto conlleva un cambio radical en el sistema jurídico y una fuente de inseguridad para el sector de las TIC (Tecnología de la Información y la Comunicación). Recordamos, en este sentido, que el intercambio de conocimiento y cultura en la red es un motor económico importante para salir de la crisis como se ha demostrado ampliamente.

4 - Los mecanismos preventivos urgentes de los que dispone la ley y la judicatura son para proteger a toda ciudadanía frente a riesgos tan graves como los que afectan a la salud pública. El gobierno pretende utilizar estos mismos mecanismos de protección global para beneficiar intereses particulares frente a la ciudadanía. Además la normativa introducirá el concepto de "lucro indirecto", es decir: a mí me pueden cerrrar el blog porque "promociono" a uno que "promociona" a otro que linka a un tercero que hace negocios presuntamente ilícitos

5 - Recordamos que la propiedad intelectual no es un derecho fundamental contrariamente a las declaraciones del Ministro de Justicia, Francisco Caamaño. Lo que es un derecho fundamental es el derecho a la producción literaria y artística.

6 - De acuerdo con las declaraciones de la Ministra de Cultura, esta disposición se utilizará exclusivamente para cerrar 200 webs que presuntamente están atentando contra los derechos de autor. Entendemos que si éste es el objetivo de la disposición, no es necesaria, ya que con la legislación actual existen procedimientos que permiten actuar contra webs, incluso con medidas cautelares, cuando presuntamente se esté incumpliendo la legalidad. Por lo que no queda sino recelar de las verdaderas intenciones que la motivan ya que lo único que añade a la legislación actual es el hecho de dejar la ciudadanía en una situación de grave indefensión jurídica en el entorno digital.

7 - Finalmente consideramos que la propuesta del gobierno no sólo es un despilfarro de recursos sino que será absolutamente ineficaz en sus presuntos propósitos y deja patente la absoluta incapacidad por parte del ejecutivo de entender los tiempos y motores de la Era Digital.

La disposición es una concesión más a la vieja industria del entretenimiento en detrimento de los derechos fundamentales de la ciudadanía en la era digital.

La ciudadanía no puede permitir de ninguna manera que sigan los intentos de vulnerar derechos fundamentales de las personas, sin la debida tutela judicial efectiva, para proteger derechos de menor rango como la propiedad intelectual. Dicha circunstancia ya fué aclarada con el dictado de inconstitucionalidad de la ley Corcuera (o ley de patada en la puerta). El Manifiesto en defensa de los derechos fundamentales en Internet, respaldado por más de 200 000 personas, ya avanzó la reacción y demandas de la ciudadanía antes la perspectiva inaceptable del gobierno.
Para impulsar un definitivo cambio de rumbo y coordinar una respuesta conjunta, el 9 de enero se ha constituido la "Red SOStenible" una plataforma representativa de todos los sectores sociedad civil afectados. El objetivo es iniciar una ofensiva para garantizar una regulación del entorno digital que permita expresar todo el potencial de la Red y de la creación cultural respetando las libertades fundamentales.

En este sentido, reconocemos como referencia para el desarrollo de la era digital, la Carta para la innovación, la creatividad y el acceso al conocimiento, un documento de síntesis elaborado por más de 100 expertos de 20 países que recoge los principios legales fundamentales que deben inspirar este nuevo horizonte.
En particular, consideramos que en estos momentos es especialmente urgentes la implementación por parte de gobiernos e instituciones competentes, de los siguientes aspectos recogidos en la Carta:

1 - Las/os artistas como todos los trabajadores tienen que poder vivir de su trabajo (referencia punto 2 "Demandas legales", párrafo B. "Estímulo de la creatividad y la innovación", de la Carta);

2 - La sociedad necesita para su desarrollo de una red abierta y libre (referencia punto 2 "Demandas legales", párrafo D "Acceso a las infraestructuras tecnológicas", de la Carta);

3 - El derecho a cita y el derecho a compartir tienen que ser potenciado y no limitado como fundamento de toda posibilidad de información y constitutivo de todo conocimiento (referencia punto 2 "Demandas legales", párrafo A "Derechos en un contexto digital", de la Carta);

4 - La ciudadanía debe poder disfrutar libremente de los derechos exclusivos de los bienes públicos que se pagan con su dinero, con el dinero publico (referencia punto 2 "Demandas legales", párrafo C "Conocimiento común y dominio público", de la Carta);

5 -Consideramos necesaria una reforma en profundidad del sistema de las entidades de gestión y la abolición del canon digital (referencia punto 2 "Demandas legales", párrafo B. "Estímulo de la creatividad y la innovación", de la Carta).

Por todo ello hoy se inicia la campaña INTERNET NO SERA OTRA TELE y se llevarán a cabo diversas acciones ciudadanas durante todo el periodo de la presidencia española de la UE.

Consideramos particularmente importantes en el calendario de la presidencia de turno española el II Congreso de Economía de la Cultura (29 y 30 de marzo en Barcelona), Reunión Informal de ministros de Cultura (30 y 31 de marzo en Barcelona) y la reunión de ministros de Telecomunicaciones (18 a 20 de abril en Granada).

La Red tiene previsto reunirse con representantes nacionales e internacionales de partidos políticos, representantes de la cultura y legaciones diplomáticas.

Firmado Red SOStenible

http://Red-SOStenible.net

http://Red-SOStenible.net/colabora/

La Red Sostenible somos todo. Si quieres adherirte a este texto, cópialo, blogguéalo, difúndelo.

El milagro de la automatización

Quién, que trabaje en SQA, no ha oído a su jefe, o a algún enterado, hablar maravillas de la automatización, como si fuera la panacea del SQA. Sin automatización estamos perdidos, sin automatización no podemos crecer (normalmente dicen escalar, que mola más).... Es casi tan repetido como esas otras dos que dicen "El SQA es muy fácil, lo hace cualquiera" o "El SQA lo puede hacer el programador, que es el que entiende mejor la aplicación y el código que ha escrito". No, no voy a comentar estas dos últimas frases, ya que hay extensos artículos y bastantes libros, ambos escritos por gente mucho más capaz que yo, que ya han demostrado, al igual que muchos casos empíricos, la falsedad de semejantes afirmaciones.

En realidad yo estoy bastante a favor de la automatización, es una herramienta (herramienta, no un fin último de suprema excelencia en el SQA), como muchas otras, muy útil a la hora de enfrentarnos a la tarea de probar una aplicación, página web, o lo que se nos ponga por delante. Con lo que no estoy de acuerdo es con ese pensamiento de que, automatizar soluciona todos tus problemas, y que una vez hecho, tienes un QA mucho más robusto y más completo, y tiempo para otras cosas.

La automatización es una muy buena ayuda para, por ejemplo, quitarte de encima tareas muy repetitivas, tests con montones de variables que se hacen eternos (sobre todo en los tests de regresión) y te permite, de forma rápida lanzar una cantidad enorme de pruebas con un, relativamente, bajo coste en tiempo de tus ingenieros de QA. Pero todo esto, no está exento de un cierto grado de inversión, de tiempo y recursos, que muchos no ven. Y no hablo de la creación en si de esos tests automáticos, no, eso, si tienes un buen catálogo de tests y los tienes de manera mas o menos ordenada, es fácil. Hablo de los otros costes, los costes de mantenimientos de esos tests, los costes de equipo necesario para tenerlos en un entorno decente para ser lanzados y hablo de los costes de revisar los resultados de esos tests una vez se han ejecutado, lo cual no suele ser tan fácil como parece.

Automatización si, toda la que se pueda, ya que nunca, nunca, es el 100%, tienes suerte si llegas al 70%. Pero cuidado con los costes escondidos. Cada cambio en el código, cada nueva funcionalidad, acaba afectando a esos tests, y toca revisarlos constantemente, probar si se siguen lanzando y revisar todos los errores para comprobar si son fallos o en realidad son cambios en la funcionalidad que han afectado a los tests. Conlleva un trabajo y un gran esfuerzo, que muchas veces no se tiene en cuenta por que "ya está automatizado".

Así que, ya sabéis, aseguraos de tener en cuenta todos los factores, por que la automatización es una gran herramienta, sobre todo bien hecha, pero conlleva una gran inversión, sobre todo si no se hace desde el principio, y un esfuerzo de mantenimiento y ejecución importante, aunque compensa enormemente el esfuerzo con unos beneficios evidentes.

La ciencia en España

Creo que hay muchas personas con más información, experiencia y mejor forma de expresarlo que yo, pero mi granito de arena aportaré.

La cosa es simple. La gran pregunta que deben hacerse todo el mundo en España, tanto votantes como grupos sociales (partidos políticos, empresas, sindicatos y demás), es bien simple.
Qué queremos hacer con nuestro país?
Parece algo fácil de responder y lo cierto es que las respuestas, aunque abundantes, en el caso de España se reducen a pocas y, para mi, a dos.
Queremos ser un país más, del montón, sin posibilidades de contar en la escena internacional, sin contar en la economía mundial ni en el desarrollo futuro? Eso nos relega a ser un país totalmente turístico, para vacaciones y servir de retiro para el resto de Europa? Con algunas empresas "decentes" y poco peso en el mundo.

O queremos ser un país que "corte el bacalao", que tenga empresas que sean la envidia del mundo, con productos punteros y a la que no le cuentan las cosas de rebote o no descubre tecnologías en revistas, sino que las investiga, las propaga a su sociedad y las vende al resto del mundo?

Para lo primero sólo hay que seguir como hasta ahora, no me entendáis mal, si España decide algo así, perfecto (tampoco creo que lo estemos haciendo muy bien si nos queremos dedicar al turismo, pero ese es otro tema). Pero es algo que muchos queremos saber, por meditar si migrar a otros sitios o en qué quiero trabajar en el futuro. Si es lo que queremos es fácil, seguimos igual, malgastando el dinero en tonterías a corto plazo, peleándonos entre nosotros por estupideces que no importan para nada y ensalzando al vago, al que chupa de la teta del estado, al que miente y sale bien parado y al vividor sin mas sueños que robar para vivir, vivir sin sueños, envidiando lo del vecino y quejándose de no tener lo mismo, eso si, sin querer cambiar para conseguir mejorar.

Por el contrario, si queremos un país que mezcle lo moderno que podemos conseguir (y hemos conseguido en los últimos 30 años) con el atractivo de una cultura única, un país que tenga ciudadanos críticos, inteligentes, bien educados en universidades punteras que sean envidia del resto del mundo (y no sólo por lo bonito del campus de turno, que también), ciudadanos que no permitan que sus derechos disminuyan, sino que aumenten, ciudadanos que crean empresas con ideas arriesgadas por que reciben ayuda para hacerlo por que es la fuente de regeneración del tejido empresarial, ciudadanos que trabajan en empresas y se siente orgullosos de trabajar en ellas por que la empresa les devuelve su esfuerzo con recompensas y eso crea una simbiosis entre empresa y empleado, ciudadanos que se sientan orgullosos de tener un país puntero, en vez de ver como es el resto del mundo el que muestra con orgullo su tecnología y sus avances mientras nosotros miramos deslumbrados.

A mi me gustaría este segundo caso, pero es una decisión de todos y en la que todos debemos trabajar para tomar. Basta de que decidan unos en contra de los otros, basta de políticos mediocres sin ideas mas halla de las próximas elecciones, basta de ciudadanos complacientes y complacidos con los poderes, sin auto-crítica, como si los partidos políticos fuera equipos de fútbol a los que defender a capa y espada aunque no tenga razón.
Maduremos, tenemos un enorme potencial y no lo estamos aprovechando. No sé qué se necesita para despertar a la sociedad y "obligarla" a debates serios de este tipo, pero necesitamos este debate, este cambio y ponernos a trabajar ya. Y para todo esto, la ciencia es la que nos debe llevar de la mano y ayudar a brillar con luz propia.

Testlink 1.8

Hace tiempo que no escribo, pero a ver si me pongo un poco al día.

Ya hace meses que está en la calle la versión definitiva de Testlink. En Junio sacaron la versión 1.8.3

Como comentario general decir que en nuestro equipo lo estamos usando y estamos muy contentos con los resultados. Tanto las nuevas funcionalidades como el funcionamiento en general es muy bueno. Una de las cosas que mas estamos agradeciendo es el API que han incluido para modificar el estado de los test ejecutados desde otras herramientas o scripts. En concreto nosotros tenemos un par de librerias que hemos hecho en PHP y Ruby (ya que tenemos scripts automáticos en ambos lenguajes) que utilizan el API de Testlink para ir reportando los resultados. Un avance tremendo que ahorra mucho tiempo y nos ayuda a mantener los datos al día.

Lo que menos me gusta, a parte de algúna que otra funcionalidad que se echa en falta, es que, de tanto en tanto, tarda mucho en cargar ciertas páginas, en concreto cuando se va a la página de acceso o se sale de la aplicación usando el link de Log out.

Nueva version de TestLink (1.8 Beta 3 )

Esta a punto de salir la versión 1.8 de TestLink. Un programa de gestión de test cases.

La verdad es que he probado varias y es la que más me convence. Con las que más puedo compararlas es conQATrack y Quality Center (de HP/Mercury), además de los tipicos métodos fáciles en plan ficheros doc, excel, etc.

Qué incorpora esta nueva versión?
Llevo usando la beta 3 desde hace unas semanas y he sacado en claro varias cosas:
- Ha mejorado mucho el uso de campos customizados.
- Es interesante el uso de "milestones" (objetivos?) (no sé como describirlo mejor). Con porcentajes de tipos de test a completar en determinadas fechas y algunas cosillas mas que son interesantes.
- La gestión de las distintas versiones de un test case se han mejorado mucho. También el actualizar el un test plan a las nuevas versiones. Muy útil.
- Estoy deseando probar el API para poder cambiar estados de test cases. Esto mezclado con tests automáticos puede ser de una gran utilidad y ahorra mucho tiempo.
- Los reports de resultados todavía tienen cosas que mejorar (los charts no muestran el último build, sino el que mas resultados tiene o alguna mezcla de ambos y no se pueden hacer reports de campos customizados) pero desde luego son geniales a la hora de ver como van las cosas en un build.
- El campo de identificador de test case es un gran avance. Lástima que no se puedan poner varios prefijos para un mismo proyecto, para tener los test cases de diferentes test suites con diferentes prefijos.
- Además tienen para crear nuevos tipos de datos para los campos customizados, lo cual, aunque no he investigado a fondo, puede resultar útil.

En fin que estoy deseando que saquen la RC 1 dentro de unas semanas a ver si solucionan algunos de los bugs y han metido algún nuevo cambio interesante.

Si a alguien le interesa, aquí tenéis el link a su página:
http://www.teamst.org/

-------------------------------------------------------------------------------------------------------------

SQA, SQC y Software Testing, ¿qué es qué?

Si queremos empezar por el principio, es necesario aclarar determinados conceptos básicos que tienden a usarse indistintamente, de forma equivocada, para referirse a lo mismo. Y digo "de forma equivocada" porque, evidentemente, no son lo mismo. Veamos algunas definiciones elementales.

De un modo general y basado en los estándares ANSI/IEEE:

• Testing: es el proceso de ejecutar un sistema con la intención de encontrar defectos incluyendo una planificación previa a la ejecución de los Casos de Test.

• Quality Control (QC): es un conjunto de actividades diseñadas para evaluar un producto.

• Quality Assurance (QA): es un conjunto de actividades diseñadas para asegurar que el proceso de desarrollo y/o mantenimiento es adecuado para asegurar que un sistema cumplirá los objetivos para los que fue diseñado.

Si lo resumimos en una frase podríamos decir que el Testing es equivalente al QC y se definiría como el proceso que mide la calidad de un producto mientras que el QA sería el proceso que mide la calidad de los procesos usados para crear dicho producto.

De un modo más particular orientado al software:

• Software Testing: es el conjunto de procedimientos usados para evaluar la calidad del software. Es una técnica de investigación empírica cuyo objetivo es proporcionar información acerca de la calidad de la aplicación bajo testeo con respecto al contexto en el que está previsto que funcione. El Software Testing conlleva la ejecución de la aplicación bajo condiciones controladas (tanto normales como anormales) y la evaluación de los resultados. Además, debe, intencionadamente, intentar provocar comportamientos erróneos para determinar si las cosas ocurren cuando no deberían o si las cosas no ocurren cuando deberían. El Software Testing está orientado a la detección.

• Software Quality Control (SQC): es un conjunto de procedimientos destinados a monitorizar, evaluar y mejorar el producto que resulta del Ciclo de Vida del Desarrollo de Software.

• Software Quality Assurance (SQA): es un conjunto de procedimientos formales destinados a monitorizar, evaluar y mejorar todos los procesos que conforman el Ciclo de Vida del Desarrollo de Software. Su principal objetivo es asegurar que en cualquier punto de este ciclo, cualquier estándar y procedimiento establecido se cumple y que los problemas se encuentran y se tratan adecuadamente, todo ello orientado a asegurar la producción de software de calidad que cumple con los requerimientos y estándares. El SQA está orientada a la prevención.

De todo esto podemos concluir que, mientras que el Software Testing y el SQC se encargan de controlar la calidad del software, el SQA se encarga de controlar la calidad de los procesos que dan como resultado dicho software.

Para terminar con las definiciones y a modo de anécdota, os dejo esta perla (de la traducción automática supongo) extraída de http://spanish.osstrans.net/software/testlink.html:

Testlink: "TestLink es un sistema que sigue basado tela de la gerencia y de la ejecución de la prueba construido para mejorar calidad de tu proceso de la verificación o de la prueba. La herramienta incluye la divulgación y los requisitos que siguen y coopera con los sistemas que siguen del insecto bien conocido.?"

----------------------------------------------------------------------------

If we want to start from the beginning, it is necessary to clarify some basic concepts that are usually taken, in a wrong way, as the same thing. And I said "in a wrong way" because, obviously, they are not the same thing. Let's see some basic definitions.

From a general point of view and based on the ANSI/IEEE standards:

• Testing: is the process of executing a system with the intent of finding defects including test planning prior to the execution of the Test Cases.

• Quality Control (QC): is a set of activities designed to evaluate a developed working product.

• Quality Assurance (QA): is a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet the objectives it was designed for.

Summarizing these concepts in a simple sentence we could say that Testing is equals to QC and it would be the process that measures the quality of a product while QA would be the process that measures the quality of the processes used to obtain this product.

From a more particular, oriented to software point of view:

• Software Testing: is the set of procedures used to evaluate the software quality. It is an empirical technical investigation conducted to supply information about the quality of the application under test with respect to the context in which it is intended to operate. Software Testing involves operation of a system or application under controlled conditions (both normal and abnormal) and evaluating the results. In addition, it should intentionally attempt to make things go wrong to determine if things happen when they should not or things do not happen when they should. Software Testing is oriented to detection.

• Software Quality Control (SQC): is a set of procedures oriented to monitoring, evaluating an improving the product that results from the Software Development Life Cycle (SDLC).

• Software Quality Assurance (SQA): is a set of formal procedures oriented to monitoring, evaluating an improving all the processes that take part in the Software Development Life Cycle (SDLC). Its main objective it to ensure that in every point of this cycle, any agreed-upon standards and procedures are followed and the problems are found and dealt with, all this with the objective of ensuring the development of quality software that accomplishes the requirements and the standards. SQA is oriented to prevention.

From all this we can conclude that while Software Testing and SQC are responsible for controlling the software quality, SQA is responsible for controlling the quality of the processes that produce this software.


Referencias/References:

http://www.realityinteractive.com/rgrzywinski/archives/000044.html
http://www.faqs.org/faqs/software-eng/testing-faq/section-9.html
http://www.softwareqatest.com/qatfaq1.html
http://en.wikipedia.org/wiki/Software_quality_control
http://en.wikipedia.org/wiki/Software_testing
http://en.wikipedia.org/wiki/Software_Quality_Assurance