https://wiki.openoffice.org/w/api.php?action=feedcontributions&feedformat=atom&user=Hohenheim 2026-08-13T20:06:13Z User contributions MediaWiki 1.35.14 https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198621 2011-12-15T23:03:30Z

<p>Hohenheim: /* STATUS */</p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. Solo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien, puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> ==CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED==<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198609 2011-12-15T00:30:08Z

<p>Hohenheim: /* VERIFIED= */</p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien, puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> ==CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED==<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198608 2011-12-15T00:29:55Z

<p>Hohenheim: </p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien, puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> ==CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED===<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198607 2011-12-15T00:27:47Z

<p>Hohenheim: /* CONFIRMED= */</p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien, puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> ==CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED===<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198606 2011-12-15T00:27:29Z

<p>Hohenheim: /* UNCONFIRMED */</p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien, puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> =CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED===<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Campos_de_un_bug&diff=198605 2011-12-15T00:26:42Z

<p>Hohenheim: Created page with &quot;==STATUS== El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones de estados son permitidas. ==RESOLUTION== El campo de resolución indica que pasó con …&quot;</p> <hr /> <div>==STATUS==<br /> El campo status indica el estado actual de un &#039;bug&#039;. SOlo ciertas trancisiones<br /> de estados son permitidas.<br /> <br /> ==RESOLUTION==<br /> El campo de resolución indica que pasó con ese &#039;bug&#039;.<br /> <br /> ===Open Bugs (Bugs Abiertos)===<br /> ==UNCONFIRMED==<br /> Este bug se ha añadido recientemente a la base de datos. Nadie ha confirmado (CONFIRMED)<br /> que este error es válido. Los usuarios que tienen el &quot;canconfirm&quot; conjunto de <br /> permisos puede confirmar este error, cambiar su estado por confirmar. O bien,<br /> puede ser resuelto directamente y marcó resuelto (RESOLVED).<br /> <br /> =CONFIRMED==<br /> Este error es válido y ha sido presentado recientemente. Errores en este estado se pasan a estado en progreso (IN_PROGRESS) cuando alguien está trabajando en ellos, o se resuelven y son marcados como resueltos (RESOLVED).<br /> <br /> ==IN PROGRESS==<br /> Este error no se ha resuelto, pero se le asigna a la persona adecuada que está trabajando en el error. A partir de aquí, los errores se pueden dar a otra persona y se convierten en confirmados (CONFIRMED), o se resuelven y se convierten en resueltos (RESOLVED).<br /> <br /> No resolution yet. No hay solución todavía. Todos los errores que se encuentran en estado abierto (OPEN) no tienen solución aún.<br /> <br /> === Closed Bugs (Bugs cerrados)===<br /> <br /> <br /> ==RESOLVED==<br /> La resolución se ha realizado, y está pendiente de verificación por control de calidad. A partir de aquí los errores son reabiertos y dan un estatus abierto, o son verificados por control de calidad y marcados como verificados (VERIFIED).<br /> <br /> ==VERIFIED===<br /> QA ha estudiado el fallo y la resolución y está de acuerdo en que la resolución apropiada ha sido tomada. Este es el estado final de los bugs.<br /> <br /> ==FIXED==<br /> Una solución para este error se registró en el árbol y se ha probado.<br /> <br /> ==INVALID==<br /> El problema descrito no es un error.<br /> <br /> ==WONTFIX==<br /> El problema descrito es un bug que nunca será solucionado.<br /> <br /> ==DUPLICATE==<br /> El problema es un duplicado de un bug existente. Cuando un bug es marcado como duplicado (DUPLICATE), verás que el bug es un duplicado a un lado de la resolución.<br /> <br /> ==WORKSFORME==<br /> Todos los intentos de reproducir este error fueron inútiles, y la lectura del código produce ninguna pista de por qué el comportamiento descrito se produciría. Si aparece más información más tarde, el error puede ser reabierto.<br /> <br /> <br /> ===Other Fields===<br /> <br /> ==Alias==<br /> Un nombre corto, único asignado a un error en el fin de ayudar con mirar hacia arriba y refiriéndose a ella en otros lugares en Bugzilla.<br /> <br /> ==Assignee==<br /> La persona encargada de resolver el error.<br /> <br /> ==Blocks==<br /> Este error se debe resolver antes de que los errores listados en este campo se puedan resolver.<br /> <br /> ==Bug ID==<br /> El ID numérico de un bug, único en toda la instalación de Bugzilla.<br /> <br /> ==CC==<br /> Los usuarios que no pueden tener un papel directo en este error, pero que están interesados ​​en su progreso.<br /> <br /> ==Changed==<br /> Cuando este error se actualizó por última vez.<br /> <br /> ==Classification==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Comment==<br /> Los errores se clasifican en categorías, productos y componentes. clasificaciones es la clasificación de nivel superior.<br /> <br /> ==Component==<br /> Los componentes son categorías de segundo nivel, cada una pertenece a un determinado producto. Seleccione un producto para reducir esta lista.<br /> <br /> ==Content==<br /> Este es un campo disponible en las búsquedas que realiza la búsqueda como &quot;texto completo&quot; de Google en el resumen y los campos de comentario.<br /> <br /> ==Creation date==<br /> Cuando el error se presentó.<br /> <br /> ==Depends on==<br /> Los fallos en la lista aquí deben ser resueltos antes de que este error se puede resolver.<br /> <br /> ==Hardware==<br /> La plataforma de hardware en la que fue observado el bug. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Keywords==<br /> Puede añadir palabras clave a partir de una lista definida de los bugs, con el fin de la etiqueta y agruparlos.<br /> <br /> ==OS==<br /> El sistema operativo en el que se ha observado el error. Nota: Al buscar, seleccionar la opción &quot;Todos&quot; sólo encuentra errores, cuyo valor para este campo es, literalmente, la palabra &quot;todos&quot;.<br /> <br /> ==Priority==<br /> Ingenieros priorizan sus errores utilizando este campo.<br /> <br /> ==Product==<br /> Los errores se clasifican en productos y componentes.<br /> <br /> ==QA Contact==<br /> La persona responsable de confirmar este error si no está confirmada, y para verificar la corrección de una vez el problema sea resuelto.<br /> <br /> ==Reporter==<br /> La persona que presentó este error.<br /> <br /> ==See Also==<br /> Esto permite hacer referencia a los errores en otras instalaciones. Usted puede escribir una dirección URL a un error en el campo agregar &quot;URL de Bug&#039; tener en cuenta que ese error se relaciona con éste. Se pueden introducir varias direcciones URL a la vez separándolos con comas.<br /> Normalmente se debe utilizar este campo para referirse a los errores en otras instalaciones. Para conocer los errores en esta instalación, es mejor utilizar el &#039;Depends&#039; de los campos y bloques.<br /> <br /> ==Severity==<br /> ¿Qué tan grave es el error?, o si se trata de una mejora.<br /> <br /> ==Summary==<br /> El resumen de errores es una frase corta que describe de forma sucinta de lo que el bug se trata.<br /> <br /> ==URL==<br /> Los errores pueden tener una URL asociada con ellos - por ejemplo, un puntero a un sitio web donde se ve el problema.<br /> <br /> ==Version==<br /> El campo de versión define la versión del software en la que se encontró el bug.<br /> <br /> ==Votes==<br /> Algunos errores pueden ser votados, y puede limitar su búsqueda a los bugs con más de un número determinado de votos.<br /> <br /> ==Whiteboard==<br /> Cada bug tiene una forma libre de una sola línea de cuadro de texto de entrada para la adición de etiquetas y la información de estado.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad&diff=198594 2011-12-14T22:34:54Z

<p>Hohenheim: /* Control de Calidad */</p> <hr /> <div>== Control de Calidad ==<br /> <br /> En este apartado podr&amp;aacute;s encontrar informaci&amp;oacute;n de mucha ayuda para el &amp;aacute;rea de aseguramiento de la calidad, as&amp;iacute; como el proceso de testing.<br /> <br /> A continuaci&amp;oacute;n se listan los temas que te pueden ser de gran ayuda,<br /> <br /> === Control de la Calidad del Software ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Control de Calidad del Software|Control de Calidad del Software]]<br /> <br /> === Soporte de Control de Calidad ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Soporte de Control de Calidad|Soporte de Control de Calidad]]<br /> <br /> === Software Testing (Pruebas de Software) ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Software Testing|Software Testing]]<br /> <br /> ===Reporte de Bugs===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reporte de Bugs|Reporte de Bugs]]<br /> <br /> ===Anatom&amp;iacute;a de un Bug===<br /> [[OOoES/Calidad/Gestion de la Calidad: Anatomia de un Bug|Anatomia de un Bug]]<br /> <br /> ===Manejo de Issues===<br /> [[OOoES/Calidad/Gestion de la Calidad: Manejo de Issues|Manejo de Issues]]<br /> <br /> ===Reglas b&amp;aacute;sicas para usar un Issue Tracker===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reglas para usar un Issue Tracker|Reglas para usar un Issue Tracker]]<br /> <br /> ===Campos en los que se puede clasificar un bug en un Issue Tracker===<br /> [[OOoES/Calidad/Gestion de la Calidad: Campos de un bug]]<br /> <br /> === Soporte de Control en OOo ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Writer/Calc/Graphics/Database/Framework/Automatizacion|Writer/Calc/Graphics/Database/Framework/Automatizacion]]<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198499 2011-11-24T22:39:47Z

<p>Hohenheim: </p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===FRAMEWORK===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.&lt;/p&gt;<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.<br /> &lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198498 2011-11-24T22:14:32Z

<p>Hohenheim: /* AUTOMATIZACI&amp;Oacute;N */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===FRAMEWORK===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.&lt;/p&gt;<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.<br /> &lt;/p&gt;</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198497 2011-11-24T22:14:05Z

<p>Hohenheim: /* AUTOMATIZACI&amp;Oacute;N */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===FRAMEWORK===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.&lt;/p&gt;<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198496 2011-11-24T22:13:24Z

<p>Hohenheim: /* FRAMEWORK */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===FRAMEWORK===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.&lt;/p&gt;<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198495 2011-11-24T22:13:03Z

<p>Hohenheim: /* GRAPHICS */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198494 2011-11-24T22:12:44Z

<p>Hohenheim: /* GRAPHICS */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198493 2011-11-24T22:12:03Z

<p>Hohenheim: /* BASE */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===GRAPHICS===<br /> El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal<br /> de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw <br /> (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas <br /> automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con <br /> la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las <br /> pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para <br /> asegurar su integración en las mejores condiciones posibles.<br /> <br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198492 2011-11-24T22:11:39Z

<p>Hohenheim: /* WRITER */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.&lt;/p&gt;<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===GRAPHICS===<br /> El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal<br /> de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw <br /> (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas <br /> automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con <br /> la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las <br /> pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para <br /> asegurar su integración en las mejores condiciones posibles.<br /> <br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198491 2011-11-24T22:11:10Z

<p>Hohenheim: /* CALC */</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.<br /> <br /> ===CALC===<br /> &lt;p style=&quot;text-align:justify;&quot;&gt;El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo, gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> &lt;/p&gt;<br /> <br /> ===BASE===<br /> El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===GRAPHICS===<br /> El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal<br /> de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw <br /> (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas <br /> automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con <br /> la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las <br /> pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para <br /> asegurar su integración en las mejores condiciones posibles.<br /> <br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Writer/Calc/Graphics/Database/Framework/Automatizacion&diff=198490 2011-11-24T22:09:45Z

<p>Hohenheim: Created page with &quot;En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el obj…&quot;</p> <hr /> <div>En el presente apartado, se proporcionarán las declaraciones de la Misi&amp;oacute;n de cada una de los componentes de OpenOffice.org con la intenci&amp;oacute;n de dar a conocer el objetivo de QA en cada uno de &amp;eacute;stos, tambi&amp;eacute;n se comparten los nombres de los respectivos responsables de cada proyecto.<br /> <br /> <br /> ===WRITER===<br /> El objetivo del Equipo de OOo Writer de control de calidad es asegurar y mejorar la calidad del <br /> OpenOffice.org Writer (procesador de textos), así como las áreas cercanas, como Math <br /> (editor de fórmulas), bibliografía, fuentes, lingüística (corrector ortográfico) y la impresión. <br /> Para lograr esto, utilizamos pruebas automatizadas, pruebas con TCS (especificaciones de casos <br /> de prueba) y las pruebas funcionales en Solaris, Linux y Windows. Para asegurar la calidad de <br /> las características de nuevo Writer, participamos en iTeams para tener un TCS apropiado listo <br /> antes de que una función se integre.<br /> <br /> ===CALC===<br /> El equipo de QA OOo Calc es el principal responsable de asegurar y mejorar la calidad de la <br /> OOo / SUN área de hoja de cálculo StarOffice. A esta área pertenece principalmente: las <br /> características Calc básico, Calc y OASIS formato de archivo XML, los filtros de hoja de cálculo,<br /> gráficos y sistema de ayuda. La prueba se da, principalmente mediante el uso de la oficina, <br /> las pruebas funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y <br /> con pruebas automáticas sobre todo en Windows, Linux y Solaris. También nuevas características <br /> son guiados en su camino hacia el producto para asegurar su integración en las mejores <br /> condiciones posibles.<br /> <br /> <br /> ===BASE===<br /> El equipo de OOo Base de datos de control de calidad es el principal responsable de asegurar y <br /> mejorar la calidad de la OOo / SUN área de base de datos de StarOffice. Para esta zona, <br /> principalmente pertenece: fuentes de datos y bases de datos, libreta de direcciones, dbase, <br /> ODBC, JDBC, ADO y también la forma y el manejo de control y la capacidad de accesibilidad dentro <br /> de estas áreas. La prueba se da, principalmente mediante el uso de la oficina, las pruebas <br /> funcionales esporádicos, las pruebas con TCS (especificación de casos de prueba) y con pruebas <br /> automáticas sobre todo en Windows, Linux y Solaris. También nuevas características son guiados <br /> en su camino hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===GRAPHICS===<br /> El equipo Graphics de control de calidad de OOo tiene la responsabilidad principal<br /> de asegurar y mejorar la calidad de la zona de OOo / SUN StarOffice gráficos, incluyendo Draw <br /> (Dibujo) e Impress (presentación). El proceso de prueba se compone principalmente de pruebas <br /> automatizadas y manuales en Windows, Linux y Solaris. Las pruebas automatizadas se realiza con <br /> la Testtool, pruebas manuales, trabajando con las especificaciones de caso de prueba y las <br /> pruebas funcionales. Las nuevas características son guiados en su camino hacia el producto para <br /> asegurar su integración en las mejores condiciones posibles.<br /> <br /> <br /> ===FRAMEWORK===<br /> El equipo de control de calidad del Framework OOo es el principal responsable de asegurar y mejorar <br /> la calidad del Framework de OOo / Sun StarOffice. Esta área se compone de:, configuración e <br /> instalación del sistema de integración, la oficina de inicio, la oficina de un navegador <br /> plug-in, el archivo de las operaciones como cargar y guardar archivos (sistema de archivos, <br /> FTP, HTTP (WebDAV)), las ventanas y el manejo de las tareas y la configuración y el <br /> comportamiento de las barras de herramientas.<br /> La prueba se realiza principalmente mediante el uso de la oficina, las pruebas funcionales <br /> esporádicas, las pruebas con TCS (especificación de casos de prueba) y con pruebas automáticas <br /> sobre todo en Windows, Linux y Solaris. También nuevas características son guiados en su camino <br /> hacia el producto para asegurar su integración en las mejores condiciones posibles.<br /> <br /> ===AUTOMATIZACI&amp;Oacute;N===<br /> El equipo de QA Automatización de OOo tiene la responsabilidad principal de asegurar la <br /> estabilidad y la calidad de todo el OOo / Sun StarOffice. El sistema automatizado de pruebas de<br /> interfaz gráfica de usuario ofrece un marco de prueba con scripts de prueba y una aplicación <br /> (VCL TestTool) para probar la aplicación casi automática de toda la oficina. Los scripts TestTool <br /> VCL están escritos en BASIC con algunas funciones adicionales, especialmente para la oficina. <br /> El TestTool VCL comunica a través de TCP / IP con la aplicación de Office. Para iniciar la <br /> prueba de interfaz gráfica de usuario, se recomienda descargar los scripts (Medio Ambiente <br /> TestTool) y la aplicación TestTool VCL para la plataforma en la que desea ejecutar las pruebas.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad&diff=198489 2011-11-24T22:02:29Z

<p>Hohenheim: </p> <hr /> <div>== Control de Calidad ==<br /> <br /> En este apartado podr&amp;aacute;s encontrar informaci&amp;oacute;n de mucha ayuda para el &amp;aacute;rea de aseguramiento de la calidad, as&amp;iacute; como el proceso de testing.<br /> <br /> A continuaci&amp;oacute;n se listan los temas que te pueden ser de gran ayuda,<br /> <br /> === Control de la Calidad del Software ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Control de Calidad del Software|Control de Calidad del Software]]<br /> <br /> === Soporte de Control de Calidad ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Soporte de Control de Calidad|Soporte de Control de Calidad]]<br /> <br /> === Software Testing (Pruebas de Software) ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Software Testing|Software Testing]]<br /> <br /> ===Reporte de Bugs===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reporte de Bugs|Reporte de Bugs]]<br /> <br /> ===Anatom&amp;iacute;a de un Bug===<br /> [[OOoES/Calidad/Gestion de la Calidad: Anatomia de un Bug|Anatomia de un Bug]]<br /> <br /> ===Manejo de Issues===<br /> [[OOoES/Calidad/Gestion de la Calidad: Manejo de Issues|Manejo de Issues]]<br /> <br /> ===Reglas b&amp;aacute;sicas para usar un Issue Tracker===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reglas para usar un Issue Tracker|Reglas para usar un Issue Tracker]]<br /> <br /> === Soporte de Control en OOo ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Writer/Calc/Graphics/Database/Framework/Automatizacion|Writer/Calc/Graphics/Database/Framework/Automatizacion]]<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Anatomia_de_un_Bug&diff=198436 2011-11-16T20:54:44Z

<p>Hohenheim: </p> <hr /> <div>==Anatom&amp;iacute;a de un Bug==<br /> Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.&lt;br&gt;<br /> &lt;br&gt;Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes.<br /> Creación / Modificaci&amp;oacute;n de Bugs: La creaci&amp;oacute;n, modificaci&amp;oacute;n y visualizaci&amp;oacute;n de errores.&lt;br&gt;<br /> Documentación: La documentaci&amp;oacute;n Bugzilla, incluyendo la gu&amp;iacute;a de Bugzilla.&lt;br&gt;<br /> Email: Todo lo relacionado con el correo electr&amp;oacute;nico enviado por Bugzilla.&lt;br&gt;<br /> Instalaci&amp;oacute;n: El proceso de instalaci&amp;oacute;n de Bugzilla.&lt;br&gt;<br /> Consulta / Buglist: Todo lo relacionado con la b&amp;uacuet;squeda de errores y ver la buglists.<br /> Informes / Gr&amp;aacute;ficos: C&amp;oacute;mo los informes de Bugzilla.<br /> Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc.<br /> Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.&lt;br&gt;<br /> &lt;br&gt;<br /> 2.- Estado y la Resoluci&amp;oacute;n: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a trav&amp;eacute;s de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resoluci&amp;oacute;n de la instalaci&amp;oacute;n debe estar documentada en la ayuda contextual para esos elementos.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> 3.- Asignado a: La persona responsable de corregir el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.&lt;br&gt;<br /> &lt;br&gt;<br /> 5.- URL: Un URL asociada con el error, en su caso.&lt;br&gt;<br /> &lt;br&gt;<br /> 6.- Resumen: Un resumen de una sentencia del problema.&lt;br&gt;<br /> &lt;br&gt;<br /> 7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.&lt;br&gt;<br /> &lt;br&gt;<br /> 8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.&lt;br&gt;<br /> &lt;br&gt;<br /> 9.- Plataforma y sistema operativo: Indican el entorno inform&amp;aacute;tico, donde se encontr&amp;oacute; el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 10.- Versi&amp;oacute;n: El campo de &quot;versi&amp;oacute;n&quot; se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.&lt; br&gt;<br /> &lt;br&gt;<br /> 11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.&lt;br&gt;<br /> &lt;br&gt;<br /> 12.- Gravedad: Esto indica que tan grave es el problema - de bloqueo (&quot;aplicaci&amp;oacute;n inservible&quot;) a lo trivial (&quot;cuestión estética menor&quot;). También puede utilizar este campo para indicar si un error es una solicitud de mejora.&lt;br&gt;<br /> &lt;br&gt;<br /> 13.- Objetivo: (Milestone objetivo aka) Una versi&amp;oacute;n futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.&lt;br&gt;<br /> &lt;br&gt;<br /> 14.- Reportero: La persona que present&amp;oacute; el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 15.- Lista de CC: Una lista de las personas que reciben correo electr&amp;oacute;nico cuando cambia el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta funci&amp;oacute;n, tienes que ser bendecido pertenencia a un grupo especificado por el par&amp;aacute;metro &quot;timetrackinggroup&quot;.&lt;br&gt;<br /> &lt;br&gt;<br /> 17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que est&amp;aacute;n marcados <br /> como archivos grandes, que se almacenan directamente en el disco.&lt;br&gt;<br /> &lt;br&gt;<br /> 18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs <br /> que se fija (bloques), sus n&amp;uacute;meros se registran aqu&amp;iacute;.&lt;br&gt;<br /> &lt;br&gt;<br /> 19.- Votos: Si este error se ha asignado ningn voto.&lt;br&gt;<br /> &lt;/p&gt;<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Reporte_de_Bugs&diff=198435 2011-11-16T18:21:07Z

<p>Hohenheim: </p> <hr /> <div>==Reporte de Bugs==<br /> <br /> Como bien se sabe, para poder reportar o dar seguimiento a diferentes issues/bugs se debe utilizar un issue tracker, el que esta utilizando OpenOffice.org actualmente es Bugzilla, al cual puedes acceder dando clic [https://bugs.freedesktop.org aquí] , y posteriormente te mostramos una gu&amp;iacute;a &amp;uacute;til de como usar este issue tracker.<br /> <br /> <br /> El procedimiento para reportar un bug es el siguiente:<br /> <br /> 1. Clic en link &quot;New&quot; disponible en el pie de p&amp;aacute;gina de las paginas, o en el link &quot;Enter a new bug report&quot; mostrado en la pagina de inicio de la Instalaci&amp;oacute;n de Bugzilla.<br /> <br /> 2. Primero debes seleccionar el producto en el cual encontraste el bug.<br /> <br /> 3.Ahora aparecer&amp;aacute; un formulario donde puede especificar el componente (parte del producto que se ve afectado por el error que has descubierto, y si no tienes ni idea, s&amp;oacute;lo tienes que seleccionar &quot;General&quot; si existe un componente), la versi&amp;oacute;n del programa que el uso, el sistema operativo y la plataforma de su programa se est&amp;acute; ejecutando y la gravedad del error ( si el error encontrado bloquea el programa), es probablemente un error mayor o critico, si hay un error en alguna otra parte es es algo menor, si se trata de algo que te gustaria ver implementado, entonces es una mejora.<br /> <br /> 4. Ahora tiene que dar un resumen corto pero descriptivo del error que has encontrado. &quot;Mi programa se bloquea todo el tiempo&quot; es un resumen muy pobre y no ayuda a los desarrolladores de todos. Intente algo m&amp;aacute;s significativo,o tu bug era probablemente ignorado ebido a tu falta de precision. El siguiente paso es dar una lista muy detallada de los pasos para reproducir el problema que has encontrado. Trate de limitar estos pasos para un conjunto m&amp;iacute;nimo necesario para reproducir el problema, esto har&amp;aacute; mas f&amp;aacute;cil la vida del desarrollador, y la probabilidad de que se considere su error en un plazo razonable, sera mucho mayor.<br /> <br /> Nota: Trata de asegurarte que todo en el resumen esta tambien en el primer comentario. Los resumenes son a menudo actualizados y esto asegurara que su informaci&amp;oacute;n original sea de f&amp;aacute;cil acceso.<br /> <br /> 5. A medida que el archivo de errores, tambi&amp;eacute;n puede adjuntar un documento (caso_prueba, parche o captura de pantalla del problema).<br /> <br /> 6. Dependiendo de la instalaci&amp;oacute;n de Bugzilla que est&amp;aacute, utilizando y el producto en el que est&amp;aacute; presentando el error, también puede solicitar a los desarrolladores a considerar si el fallo de diferentes maneras (por ejemplo, solicitar la revisi&amp;oacute;n por el parche que acabas de adjuntar, solicitando su error al bloquear el pr&amp;oacute;xima lanzamiento del producto, y muchas solicitudes de otros productos espec&amp;iacute;ficos).<br /> <br /> 7. Ahora es un buen momento para leer su informe de error de nuevo. Eliminar todas las faltas de ortograf&amp;iacute;a, de lo contrario el error no puede ser encontrado por los desarrolladores ejecutar consultas de algunas palabras espec&amp;iacute;ficas, por lo que su error no tendr&amp;iacute;a la menor atenci&amp;oacute;n. Adem&amp;aacute;s, aseg&amp;uacute;rese de no olvidar ninguna informaci&amp;oacute;n importante a los desarrolladores deben saber con el fin de reproducir el problema, y aseg&amp;uacute;rese de que su descripci&amp;oacute;n del problema es lo suficientemente expl&amp;iacute;cito y claro. Cuando usted piensa en su informe de error est&amp;aacute; listo para ir, el &amp;uacute;ltimo paso es hacer clic en el &quot;Comit&amp;eacute;&quot; para añadir su informe en la base de datos.<br /> <br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Manejo_de_Issues&diff=198434 2011-11-16T18:15:37Z

<p>Hohenheim: </p> <hr /> <div>==Manejo de Issues==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Se hablará de como los &#039;issues&#039; son tratados dentro del departamento de control de calidad (QA) de OOo.<br /> <br /> Bueno dando clic aqui puedes encontrar una guía, la cual neesitaremos probablemente cuando tengamos algun problema con OOo. Tal vez la aplicacion falló, algun comportamiento inesperado o algo mas que nos  haga sentir que algo esta mal. Lo mas probable es que hayamos encontrado un issue/bug (problema, defecto) que debe ser resuelto. Cuando eres nuevo reportando issues esa página te ayudará a entender la forma en que un &#039;issue&#039; es tratado desde que es encontrado hasta que finalmente se soluciona.&lt;/p&gt;<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;<br /> #Se recomienda que empieces iniciando sesión en un &#039;IssueTracker&#039;. Si deseas aprender sobres los beneficios de ser un Issue Tracker lee esto.<br /> #Por favor  busca en la base de datos del &#039;IssueTracker&#039; para asegurarte que tu &#039;issue&#039; aún no existe. Haz una búsqueda rápida de duplicados o haz una más avanzada con los criterios que creas necesarios aqui. Si tu &#039;issue&#039; ya existe, quizá te gustaría registrarlo (en el bookmark) o establecerte en el CC para darle seguimiento.<br /> #¿No encontraste tu &#039;issue&#039; en la base de datos? Bueno, adelante reporta uno nuevo usando un formulario como éste. Si tu no estas familiarizado reportando buenos reportes de bugs, te recomendamos leer esto. Siguiendo estas simples reglas realmente te hará la vida mas sencilla, si quisieras saber un poco mas, quizá podrías leer también estodetalladamente. (link no disponible por el momento :S)<br /> #El &#039;issue&#039; necesita ser confirmado, cuando eres nuevo en OOo, no estas autorizado para confirmar tus &#039;ssues&#039; tu mismo, así que alguien con los permisos requeridos tomará cartas en el asunto. El voluntario OOo tratará de reproducir tu mismo problema y -en caso de falla- te contactará y pedirá mas información. Si la reproducción tiene éxito, al &#039;issue&#039; se le asigna un &#039;target&#039; (un objetivo/blanco), y será entregado al equipo de desarrollo para solucionarlo. Si el &#039;issue&#039; no puede ser reproducido es cerrado.<br /> #Tu &#039;issue&#039; es añadido a un CWS (ChildWorkSpace). El CWS es creado, y es en el cual tu &#039;issue&#039; es solucionado por un desarrollador. Cuando la solución esta lista el CWS es enviado a Control de Calidad (QA).<br /> #El &#039;issue&#039; necesita ser verificado en el CWS tu issue ahora será verificado, lo cual significa que alguien (que también podría ser tu), echa un vistazo, ejecutando una compilación de desarrollo del CWS. Si la solución no es buena (falló completamente o es insuficiente) regresa a desarrollo.<br /> #La solución es buena, y se integra dentro del MWS. El &#039;issue&#039; ahora tiene el status de fixed/verified (solucionado/verificado) y se integra dentro de la línea de desarrollo principal y puedes descargarla.<br /> #Verificación final de la solución, de nuevo alguien verifica que la solución no se corrompió o perdió por accidente. Si todo salió bien, el status es cambiado a closed/fixed (cerrado/solucionado). Cualquier problema, la tarea regresa a desarrollo y el ciclo comienza de nuevo.<br /> &lt;/p&gt;<br /> <br /> <br /> &lt;p style=&quot;text-align:center;&quot;&gt;[[File:issue_handling.png]]<br /> &lt;/p&gt;<br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Manejo_de_Issues&diff=198433 2011-11-16T18:15:21Z

<p>Hohenheim: </p> <hr /> <div>==Manejo de Issues==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Se hablará de como los &#039;issues&#039; son tratados dentro del departamento de control de calidad (QA) de OOo.<br /> <br /> Bueno dando clic aqui puedes encontrar una guía, la cual neesitaremos probablemente cuando tengamos algun problema con OOo. Tal vez la aplicacion falló, algun comportamiento inesperado o algo mas que nos  haga sentir que algo esta mal. Lo mas probable es que hayamos encontrado un issue/bug (problema, defecto) que debe ser resuelto. Cuando eres nuevo reportando issues esa página te ayudará a entender la forma en que un &#039;issue&#039; es tratado desde que es encontrado hasta que finalmente se soluciona.&lt;/p&gt;<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;<br /> #Se recomienda que empieces iniciando sesión en un &#039;IssueTracker&#039;. Si deseas aprender sobres los beneficios de ser un Issue Tracker lee esto.<br /> #Por favor  busca en la base de datos del &#039;IssueTracker&#039; para asegurarte que tu &#039;issue&#039; aún no existe. Haz una búsqueda rápida de duplicados o haz una más avanzada con los criterios que creas necesarios aqui. Si tu &#039;issue&#039; ya existe, quizá te gustaría registrarlo (en el bookmark) o establecerte en el CC para darle seguimiento.<br /> #¿No encontraste tu &#039;issue&#039; en la base de datos? Bueno, adelante reporta uno nuevo usando un formulario como éste. Si tu no estas familiarizado reportando buenos reportes de bugs, te recomendamos leer esto. Siguiendo estas simples reglas realmente te hará la vida mas sencilla, si quisieras saber un poco mas, quizá podrías leer también estodetalladamente. (link no disponible por el momento :S)<br /> #El &#039;issue&#039; necesita ser confirmado, cuando eres nuevo en OOo, no estas autorizado para confirmar tus &#039;ssues&#039; tu mismo, así que alguien con los permisos requeridos tomará cartas en el asunto. El voluntario OOo tratará de reproducir tu mismo problema y -en caso de falla- te contactará y pedirá mas información. Si la reproducción tiene éxito, al &#039;issue&#039; se le asigna un &#039;target&#039; (un objetivo/blanco), y será entregado al equipo de desarrollo para solucionarlo. Si el &#039;issue&#039; no puede ser reproducido es cerrado.<br /> #Tu &#039;issue&#039; es añadido a un CWS (ChildWorkSpace). El CWS es creado, y es en el cual tu &#039;issue&#039; es solucionado por un desarrollador. Cuando la solución esta lista el CWS es enviado a Control de Calidad (QA).<br /> #El &#039;issue&#039; necesita ser verificado en el CWS tu issue ahora será verificado, lo cual significa que alguien (que también podría ser tu), echa un vistazo, ejecutando una compilación de desarrollo del CWS. Si la solución no es buena (falló completamente o es insuficiente) regresa a desarrollo.<br /> #La solución es buena, y se integra dentro del MWS. El &#039;issue&#039; ahora tiene el status de fixed/verified (solucionado/verificado) y se integra dentro de la línea de desarrollo principal y puedes descargarla.<br /> #Verificación final de la solución, de nuevo alguien verifica que la solución no se corrompió o perdió por accidente. Si todo salió bien, el status es cambiado a closed/fixed (cerrado/solucionado). Cualquier problema, la tarea regresa a desarrollo y el ciclo comienza de nuevo.<br /> &lt;/p&gt;<br /> <br /> <br /> &lt;p style=&quot;text-align:left;&quot;&gt;[[File:issue_handling.png]]<br /> &lt;/p&gt;<br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Manejo_de_Issues&diff=198432 2011-11-16T18:13:42Z

<p>Hohenheim: </p> <hr /> <div>==Manejo de Issues==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Se hablará de como los &#039;issues&#039; son tratados dentro del departamento de control de calidad (QA) de OOo.<br /> <br /> Bueno dando clic aqui puedes encontrar una guía, la cual neesitaremos probablemente cuando tengamos algun problema con OOo. Tal vez la aplicacion falló, algun comportamiento inesperado o algo mas que nos  haga sentir que algo esta mal. Lo mas probable es que hayamos encontrado un issue/bug (problema, defecto) que debe ser resuelto. Cuando eres nuevo reportando issues esa página te ayudará a entender la forma en que un &#039;issue&#039; es tratado desde que es encontrado hasta que finalmente se soluciona.&lt;/p&gt;<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;<br /> #Se recomienda que empieces iniciando sesión en un &#039;IssueTracker&#039;. Si deseas aprender sobres los beneficios de ser un Issue Tracker lee esto.<br /> #Por favor  busca en la base de datos del &#039;IssueTracker&#039; para asegurarte que tu &#039;issue&#039; aún no existe. Haz una búsqueda rápida de duplicados o haz una más avanzada con los criterios que creas necesarios aqui. Si tu &#039;issue&#039; ya existe, quizá te gustaría registrarlo (en el bookmark) o establecerte en el CC para darle seguimiento.<br /> #¿No encontraste tu &#039;issue&#039; en la base de datos? Bueno, adelante reporta uno nuevo usando un formulario como éste. Si tu no estas familiarizado reportando buenos reportes de bugs, te recomendamos leer esto. Siguiendo estas simples reglas realmente te hará la vida mas sencilla, si quisieras saber un poco mas, quizá podrías leer también estodetalladamente. (link no disponible por el momento :S)<br /> #El &#039;issue&#039; necesita ser confirmado, cuando eres nuevo en OOo, no estas autorizado para confirmar tus &#039;ssues&#039; tu mismo, así que alguien con los permisos requeridos tomará cartas en el asunto. El voluntario OOo tratará de reproducir tu mismo problema y -en caso de falla- te contactará y pedirá mas información. Si la reproducción tiene éxito, al &#039;issue&#039; se le asigna un &#039;target&#039; (un objetivo/blanco), y será entregado al equipo de desarrollo para solucionarlo. Si el &#039;issue&#039; no puede ser reproducido es cerrado.<br /> #Tu &#039;issue&#039; es añadido a un CWS (ChildWorkSpace). El CWS es creado, y es en el cual tu &#039;issue&#039; es solucionado por un desarrollador. Cuando la solución esta lista el CWS es enviado a Control de Calidad (QA).<br /> #El &#039;issue&#039; necesita ser verificado en el CWS tu issue ahora será verificado, lo cual significa que alguien (que también podría ser tu), echa un vistazo, ejecutando una compilación de desarrollo del CWS. Si la solución no es buena (falló completamente o es insuficiente) regresa a desarrollo.<br /> #La solución es buena, y se integra dentro del MWS. El &#039;issue&#039; ahora tiene el status de fixed/verified (solucionado/verificado) y se integra dentro de la línea de desarrollo principal y puedes descargarla.<br /> #Verificación final de la solución, de nuevo alguien verifica que la solución no se corrompió o perdió por accidente. Si todo salió bien, el status es cambiado a closed/fixed (cerrado/solucionado). Cualquier problema, la tarea regresa a desarrollo y el ciclo comienza de nuevo.<br /> &lt;/p&gt;<br /> <br /> <br /> [[File:issue_handling.png]]<br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Anatomia_de_un_Bug&diff=198431 2011-11-16T18:12:49Z

<p>Hohenheim: </p> <hr /> <div>==Anatom&amp;iacute;a de un Bug==<br /> Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.&lt;br&gt;<br /> &lt;br&gt;Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes.<br /> Creación / Modificación de Bugs: La creación, modificación y visualización de errores.&lt;br&gt;<br /> Documentación: La documentación Bugzilla, incluyendo la guía de Bugzilla.&lt;br&gt;<br /> Email: Todo lo relacionado con el correo electrónico enviado por Bugzilla.&lt;br&gt;<br /> Instalación: El proceso de instalación de Bugzilla.&lt;br&gt;<br /> Consulta / Buglist: Todo lo relacionado con la búsqueda de errores y ver la buglists.<br /> Informes / Gráficos: Cómo los informes de Bugzilla.<br /> Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc.<br /> Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.&lt;br&gt;<br /> &lt;br&gt;<br /> 2.- Estado y la Resolución: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a través de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resolución de la instalación debe estar documentada en la ayuda contextual para esos elementos.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> 3.- Asignado a: La persona responsable de corregir el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.&lt;br&gt;<br /> &lt;br&gt;<br /> 5.- URL: Un URL asociada con el error, en su caso.&lt;br&gt;<br /> &lt;br&gt;<br /> 6.- Resumen: Un resumen de una sentencia del problema.&lt;br&gt;<br /> &lt;br&gt;<br /> 7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.&lt;br&gt;<br /> &lt;br&gt;<br /> 8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.&lt;br&gt;<br /> &lt;br&gt;<br /> 9.- Plataforma y sistema operativo: Indican el entorno informático, donde se encontró el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 10.- Versión: El campo de &quot;version&quot; se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.&lt; br&gt;<br /> &lt;br&gt;<br /> 11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.&lt;br&gt;<br /> &lt;br&gt;<br /> 12.- Gravedad: Esto indica qu￩ tan grave es el problema - de bloqueo (&quot;aplicación inservible&quot;) a lo trivial (&quot;cuestión estética menor&quot;). También puede utilizar este campo para indicar si un error es una solicitud de mejora.&lt;br&gt;<br /> &lt;br&gt;<br /> 13.- Objetivo: (Milestone objetivo aka) Una versión futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.&lt;br&gt;<br /> &lt;br&gt;<br /> 14.- Reportero: La persona que presentó el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 15.- Lista de CC: Una lista de las personas que reciben correo electrónico cuando cambia el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta función, tienes que ser bendecido pertenencia a un grupo especificado por el parámetro &quot;timetrackinggroup&quot;.&lt;br&gt;<br /> &lt;br&gt;<br /> 17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que están marcados <br /> como archivos grandes, que se almacenan directamente en el disco.&lt;br&gt;<br /> &lt;br&gt;<br /> 18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs <br /> que se fija (bloques), sus números se registran aquí.&lt;br&gt;<br /> &lt;br&gt;<br /> 19.- Votos: Si este error se ha asignado ningn voto.&lt;br&gt;<br /> &lt;/p&gt;<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Anatomia_de_un_Bug&diff=198430 2011-11-16T18:11:38Z

<p>Hohenheim: </p> <hr /> <div>==Anatom&amp;iacute;a de un Bug==<br /> Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.&lt;br&gt;<br /> &lt;br&gt;Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes.<br /> Creación / Modificación de Bugs: La creación, modificación y visualización de errores.&lt;br&gt;<br /> Documentación: La documentación Bugzilla, incluyendo la guía de Bugzilla.&lt;br&gt;<br /> Email: Todo lo relacionado con el correo electrónico enviado por Bugzilla.&lt;br&gt;<br /> Instalación: El proceso de instalación de Bugzilla.&lt;br&gt;<br /> Consulta / Buglist: Todo lo relacionado con la búsqueda de errores y ver la buglists.<br /> Informes / Gráficos: Cómo los informes de Bugzilla.<br /> Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc.<br /> Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.&lt;br&gt;<br /> &lt;br&gt;<br /> 2.- Estado y la Resolución: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a través de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resolución de la instalación debe estar documentada en la ayuda contextual para esos elementos.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> 3.- Asignado a: La persona responsable de corregir el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.&lt;br&gt;<br /> &lt;br&gt;<br /> 5.- URL: Un URL asociada con el error, en su caso.&lt;br&gt;<br /> &lt;br&gt;<br /> 6.- Resumen: Un resumen de una sentencia del problema.&lt;br&gt;<br /> &lt;br&gt;<br /> 7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.&lt;br&gt;<br /> &lt;br&gt;<br /> 8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.&lt;br&gt;<br /> &lt;br&gt;<br /> 9.- Plataforma y sistema operativo: Indican el entorno informático, donde se encontró el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 10.- Versión: El campo de &quot;version&quot; se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.&lt; br&gt;<br /> &lt;br&gt;<br /> 11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.&lt;br&gt;<br /> &lt;br&gt;<br /> 12.- Gravedad: Esto indica qu￩ tan grave es el problema - de bloqueo (&quot;aplicación inservible&quot;) a lo trivial (&quot;cuestión estética menor&quot;). También puede utilizar este campo para indicar si un error es una solicitud de mejora.&lt;br&gt;<br /> &lt;br&gt;<br /> 13.- Objetivo: (Milestone objetivo aka) Una versión futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.&lt;br&gt;<br /> &lt;br&gt;<br /> 14.- Reportero: La persona que presentó el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 15.- Lista de CC: Una lista de las personas que reciben correo electrónico cuando cambia el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta función, tienes que ser bendecido pertenencia a un grupo especificado por el parámetro &quot;timetrackinggroup&quot;.&lt;br&gt;<br /> &lt;br&gt;<br /> 17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que están marcados <br /> como archivos grandes, que se almacenan directamente en el disco.&lt;br&gt;<br /> &lt;br&gt;<br /> 18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs <br /> que se fija (bloques), sus números se registran aquí.&lt;br&gt;<br /> &lt;br&gt;<br /> 19.- Votos: Si este error se ha asignado ningn voto.&lt;br&gt;<br /> &lt;/p&gt;<br /> [[File:issue_handling.png]]<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=File:Issue_handling.png&diff=198429 2011-11-16T18:09:53Z

<p>Hohenheim: </p> <hr /> <div></div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Anatomia_de_un_Bug&diff=198428 2011-11-16T18:09:02Z

<p>Hohenheim: </p> <hr /> <div>==Anatom&amp;iacute;a de un Bug==<br /> Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.&lt;br&gt;<br /> &lt;br&gt;Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes.<br /> Creación / Modificación de Bugs: La creación, modificación y visualización de errores.&lt;br&gt;<br /> Documentación: La documentación Bugzilla, incluyendo la guía de Bugzilla.&lt;br&gt;<br /> Email: Todo lo relacionado con el correo electrónico enviado por Bugzilla.&lt;br&gt;<br /> Instalación: El proceso de instalación de Bugzilla.&lt;br&gt;<br /> Consulta / Buglist: Todo lo relacionado con la búsqueda de errores y ver la buglists.<br /> Informes / Gráficos: Cómo los informes de Bugzilla.<br /> Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc.<br /> Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.&lt;br&gt;<br /> &lt;br&gt;<br /> 2.- Estado y la Resolución: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a través de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resolución de la instalación debe estar documentada en la ayuda contextual para esos elementos.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> 3.- Asignado a: La persona responsable de corregir el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.&lt;br&gt;<br /> &lt;br&gt;<br /> 5.- URL: Un URL asociada con el error, en su caso.&lt;br&gt;<br /> &lt;br&gt;<br /> 6.- Resumen: Un resumen de una sentencia del problema.&lt;br&gt;<br /> &lt;br&gt;<br /> 7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.&lt;br&gt;<br /> &lt;br&gt;<br /> 8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.&lt;br&gt;<br /> &lt;br&gt;<br /> 9.- Plataforma y sistema operativo: Indican el entorno informático, donde se encontró el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 10.- Versión: El campo de &quot;version&quot; se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.&lt; br&gt;<br /> &lt;br&gt;<br /> 11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.&lt;br&gt;<br /> &lt;br&gt;<br /> 12.- Gravedad: Esto indica qu￩ tan grave es el problema - de bloqueo (&quot;aplicación inservible&quot;) a lo trivial (&quot;cuestión estética menor&quot;). También puede utilizar este campo para indicar si un error es una solicitud de mejora.&lt;br&gt;<br /> &lt;br&gt;<br /> 13.- Objetivo: (Milestone objetivo aka) Una versión futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.&lt;br&gt;<br /> &lt;br&gt;<br /> 14.- Reportero: La persona que presentó el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 15.- Lista de CC: Una lista de las personas que reciben correo electrónico cuando cambia el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta función, tienes que ser bendecido pertenencia a un grupo especificado por el parámetro &quot;timetrackinggroup&quot;.&lt;br&gt;<br /> &lt;br&gt;<br /> 17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que están marcados <br /> como archivos grandes, que se almacenan directamente en el disco.&lt;br&gt;<br /> &lt;br&gt;<br /> 18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs <br /> que se fija (bloques), sus números se registran aquí.&lt;br&gt;<br /> &lt;br&gt;<br /> 19.- Votos: Si este error se ha asignado ningn voto.&lt;br&gt;<br /> &lt;/p&gt;<br /> [[File:http://qa.openoffice.org/ooQAReloaded/Docs/issue_handling.png]]<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Reporte_de_Bugs&diff=198427 2011-11-16T18:04:06Z

<p>Hohenheim: </p> <hr /> <div>==Reporte de Bugs==<br /> <br /> Como bien se sabe, para poder reportar o dar seguimiento a diferentes issues/bugs se debe utilizar un issue tracker, el que esta utilizando OpenOffice.org actualmente es Bugzilla, al cual puedes acceder dando clic [https://bugs.freedesktop.org aquí] , y posteriormente te mostramos una gu&amp;iacute;a &amp;uacute;til de como usar este issue tracker.<br /> <br /> <br /> El procedimiento para reportar un bug es el siguiente:<br /> <br /> 1. Clic en link &quot;New&quot; disponible en el pie de pagina de las paginas, o en el link &quot;Enter a new bug report&quot; mostrado en la pagina de inicio de la Instalaci&amp;oacute;n de Bugzilla.<br /> <br /> 2. Primero debes seleccionar el producto en el cual encontraste el bug.<br /> <br /> 3.Ahora aparecer&amp;aacute; un formulario donde puede especificar el componente (parte del producto que se ve afectado por el error que has descubierto, y si no tienes ni idea, s&amp;oacute;lo tienes que seleccionar &quot;General&quot; si existe un componente), la versi&amp;oacute;n del programa que el uso, el sistema operativo y la plataforma de su programa se est&amp;acute; ejecutando y la gravedad del error ( si el error encontrado bloquea el programa), es probablemente un error mayor o critico, si hay un error en alguna otra parte es es algo menor, si se trata de algo que te gustaria ver implementado, entonces es una mejora.<br /> <br /> 4. Ahora tiene que dar un resumen corto pero descriptivo del error que has encontrado. &quot;Mi programa se bloquea todo el tiempo&quot; es un resumen muy pobre y no ayuda a los desarrolladores de todos. Intente algo m&amp;aacute;s significativo,o tu bug era probablemente ignorado ebido a tu falta de precision. El siguiente paso es dar una lista muy detallada de los pasos para reproducir el problema que has encontrado. Trate de limitar estos pasos para un conjunto m&amp;iacute;nimo necesario para reproducir el problema, esto har&amp;aacute; mas f&amp;aacute;cil la vida del desarrollador, y la probabilidad de que se considere su error en un plazo razonable, sera mucho mayor.<br /> <br /> Nota: Trata de asegurarte que todo en el resumen esta tambien en el primer comentario. Los resumenes son a menudo actualizados y esto asegurara que su informaci&amp;oacute;n original sea de f&amp;aacute;cil acceso.<br /> <br /> 5. A medida que el archivo de errores, tambi&amp;eacute;n puede adjuntar un documento (caso_prueba, parche o captura de pantalla del problema).<br /> <br /> 6. Dependiendo de la instalaci&amp;oacute;n de Bugzilla que est&amp;aacute, utilizando y el producto en el que est&amp;aacute; presentando el error, también puede solicitar a los desarrolladores a considerar si el fallo de diferentes maneras (por ejemplo, solicitar la revisi&amp;oacute;n por el parche que acabas de adjuntar, solicitando su error al bloquear el pr&amp;oacute;xima lanzamiento del producto, y muchas solicitudes de otros productos espec&amp;iacute;ficos).<br /> <br /> 7. Ahora es un buen momento para leer su informe de error de nuevo. Eliminar todas las faltas de ortograf&amp;iacute;a, de lo contrario el error no puede ser encontrado por los desarrolladores ejecutar consultas de algunas palabras espec&amp;iacute;ficas, por lo que su error no tendr&amp;iacute;a la menor atenci&amp;oacute;n. Adem&amp;aacute;s, aseg&amp;uacute;rese de no olvidar ninguna informaci&amp;oacute;n importante a los desarrolladores deben saber con el fin de reproducir el problema, y aseg&amp;uacute;rese de que su descripci&amp;oacute;n del problema es lo suficientemente expl&amp;iacute;cito y claro. Cuando usted piensa en su informe de error est&amp;aacute; listo para ir, el &amp;uacute;ltimo paso es hacer clic en el &quot;Comit&amp;eacute;&quot; para añadir su informe en la base de datos.<br /> <br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Software_Testing&diff=198426 2011-11-16T17:46:01Z

<p>Hohenheim: </p> <hr /> <div>==Software Testing==<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Pruebas del Software (Software Testing) <br /> <br /> Es una investigaci&amp;oacute;n llevada a cabo para proporcionar a los interesados ​​informaci&amp;oacute;n sobre la calidad del producto o servicio bajo prueba. También provee una objetiva e independiente vista hacia el software que permite apreciar y entender los riesgos de la implementaci&amp;oacute;n del software.&lt;br&gt; <br /> &lt;br&gt;<br /> Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingenier&amp;iacute;a del software. As&amp;iacute; se ejecuta un programa y mediante t&amp;eacute;cnicas experimentales se trata de descubrir que errores tiene.&lt;br&gt;<br /> <br /> &lt;br&gt;<br /> Las t&amp;eacute;cnicas de prueba incluyen el proceso de un programa o aplicaci&amp;oacute;n con la intenci&amp;oacute;n de encontrar errores de software (software bugs).<br /> &lt;br&gt;<br /> Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigaci&amp;oacute;n m&amp;aacute;s que seguir un procedimiento al pie de la letra. Una definici&amp;oacute;n de &quot;testing&quot; es: proceso de evaluaci&amp;oacute;n de un producto desde un punto de vista cr&amp;iacute;tico, donde el &quot;tester&quot; (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacci&amp;oacute;n. Por supuesto, nunca se debe testear el software en un entorno de producci&amp;oacute;n. Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producci&amp;oacute;n. Para crear un entorno de pruebas en una m&amp;aacute;quina independiente de la m&amp;aacute;quina de producci&amp;oacute;n es necesario crear las mismas condiciones que en la m&amp;aacute;quina de producci&amp;oacute;n. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen autom&amp;aacute;ticamente las bases de datos para simular un entorno de producción.&lt;br&gt;<br /> &lt;br&gt;<br /> En general, los inform&amp;aacute;ticos distinguen entre errores de programaci&amp;oacute;n (o &quot;bugs&quot;) y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programaci&amp;oacute;n puede describirse como un fallo en la sem&amp;aacute;ntica de un programa de ordenador. &amp;Eacute;ste podr&amp;iacute;a presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de c&amp;aacute;lculo.&lt;br&gt;<br /> &lt;br&gt;<br /> Una pr&amp;aacute;ctica com&amp;uacute;n es que el proceso de pruebas de un programa sea realizado por un grupo independiente de &quot;testers&quot; al finalizar su desarrollo y antes de sacarlo al mercado. Una pr&amp;aacute;ctica que viene siendo muy popular es distribuir de forma gratuita una versi&amp;oacute;n no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versi&amp;oacute;n del producto en pruebas y que es anterior a la versi&amp;oacute;n final (o &quot;master&quot;) se denomina beta, y a dicha fase de pruebas, beta testing.&lt;br&gt;<br /> &lt;br&gt;<br /> Finalmente y antes de salir al mercado, es cada vez m&amp;aacute;s habitual que se realice una fase de RTM testing (Release To Market), d&amp;oacute;nde se comprueba cada funcionalidad del programa completo en entornos de producci&amp;oacute;n. Otra pr&amp;aacute;ctica es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y contin&amp;uacute;e hasta que finaliza.&lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Soporte_de_Control_de_Calidad&diff=198425 2011-11-16T16:56:19Z

<p>Hohenheim: </p> <hr /> <div>==Soporte de Control de Calidad==<br /> <br /> Contribuir en OOo es muy f&amp;aacute;cil, mas de lo que piensas, primero debes registrarte como usuario en OOo.&lt;br&gt;<br /> &lt;br&gt;<br /> El soporte de Control de Calidad en OOo esta graduada en 3 pasos de participaci&amp;oacute;n.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> *El primer paso es &quot;Reportar Bugs&quot;, significa para los novatos adquirir conocimiento general sobre &#039;issues&#039; en com&amp;uacute;n. Los participantes en la primera etapa son capaces de encontrar y escribir &#039;issues&#039;  solos. El link contiene toda la informaci&amp;oacute;n que necesitas para saber como empezar a contribuir.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> *El segundo paso es &quot;Pruebas manuales&quot;, el cual esta dirigido a los participantes con mas habilidades. Son capaces de hacer pruebas manuales por su cuenta. Pueden ejecutar y escribir Test-Case-Specifications (TCS), y presentar &#039;issues&#039; encontrados al tratar con TCS. La p&amp;aacute;gina contiene toda la informaci&amp;oacute;n necesaria para contribuir en el segundo paso de participaci&amp;oacute;n.&lt;br&gt;<br /> &lt;br&gt;<br /> *En el tercer paso de participaci&amp;oacute;n &quot;&#039;&amp;Uacute;nete a QA&quot; puedes aplicarte para unirte al aquipo QA de OOo en una de las OOo &#039;Teamleads&#039;. Ahora has recolectado suficiente conocimientos sobre manejo de &#039;issues&#039;  (issue handling) para confirmarlos y cerrarlos por ti mismo. El llegar a esta etapa de participaci&amp;oacute;n trae muchas ventajas: tienes contacto directo con los desarrolladores de StarOffice / OpenOffice.org y con ingenieros QA. Será listado directamente como un miembro del equipo QA de OOo. Serás capaz de enviar  &#039;issues&#039; por ti mismo directo al ingeniero responsable , obtienes una responsabilidad  directa, m&amp;aacute;s derechos (como &#039;caconfirm&#039;) y mas peso en las decisiones.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Control_de_Calidad_del_Software&diff=198424 2011-11-16T16:35:32Z

<p>Hohenheim: </p> <hr /> <div>==Control de Calidad del Software==<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Las pruebas del software (software testing) son parte del proceso de control de calidad del software (SQA), donde especialistas en procesos de software y auditores están preocupados por el proceso de desarrollo de software en lugar de los artefactos, tales como documentaci&amp;oacuten, c&amp;oacute;digo y sistemas. Ellos examinan y cambian el proceso de ingenier&amp;iacute;a del software en s&amp;iacute; para reducir la cantidad de errores en el software entregado: denominada tasa de defectos.&lt;br&gt;<br /> &lt;br&gt;<br /> Lo que constituye una “Aceptable tasa de defectos” depende de la naturaleza del software; un simulador de vuelo de un juego de video podr&amp;iacute;a tener una tolerancia mucho más alta que un software para un avi&amp;oacuten real.&lt;br&gt;<br /> &lt;br&gt;<br /> Aunque existe una estrecha relaci&amp;oacuten con SQA, los departamentos de pruebas a menudo existen de forma independiente, y podr&amp;iacute;a no haber funciones SQA en algunas compañ&amp;iacute;as.&lt;br&gt;<br /> &lt;br&gt;<br /> Las pruebas de software son una tarea destinada a detectar los defectos en el software contrastando los resultados esperados de un programa informático con los resultados reales de un conjunto dado de entradas. Por el contrario, QA (control de calidad) es la implementaci&amp;oacuten de las pol&amp;iacute;ticas y procedimientos destinados a prevenir los defectos que se produzcan en primer lugar.&lt;br&gt;<br /> &lt;br&gt;<br /> OpenOffice.org cuenta con un Departamento de SQA, el cual mantiene relaci&amp;oacuten con las pruebas del software. Su comunidad de QA es un importante grupo creciente. El proyecto es liderado por Nakata Maho y los co-l&amp;iacute;deres son Caio Tiago Oliveira y Joost Andrae. Un equipo de más de 20 ingenieros QA a tiempo completo de Oracle. Los gerentes de los equipos son Thorsten Ziehm y Joerg Jahnke.<br /> &lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Ponga_toda_la_informaci%C3%B3n_relevante_dentro_del_isssue&diff=198423 2011-11-14T19:47:09Z

<p>Hohenheim: </p> <hr /> <div>==Ponga toda la información relevante dentro del &#039;issue&#039;==<br /> <br /> <br /> No solo uses links para referenciar las descripciones del bug. Los links tienen a volverse obsoletos, asi que si en medio año, alguien ve tu &#039;issue&#039;,  éste ha perdido su significado.<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Usar_adjuntos_cuando_sea_posible&diff=198422 2011-11-14T19:46:48Z

<p>Hohenheim: </p> <hr /> <div>==Usa adjuntos cuando sea posible==<br /> <br /> <br /> No adjuntes grandes archivos en la descripción. Si se le solicita proporcionar un ejemplo del problema, copie el ejemplo del problema en un archivo y adj&amp;uacute;ntelo.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Proporcionar_documentos_de_ejemplo_si_es_posible&diff=198421 2011-11-14T19:46:30Z

<p>Hohenheim: </p> <hr /> <div>==Proporcionar documentos de ejemplo, si es posible==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Si hay un problema con un documento en particular, entonces adjuntalo. Esto a menudo le permite y facilita realmente a las personas a reproducir tu problema solo abriendo el documento adjunto. Si la descripción de como se reproduce un defecto excede cierto limite, pregúntate si puedes  reportar el resultado de la descripción con un documento de ejemplo y adjuntalo al &#039;issue&#039;.&lt;br&gt;<br /> &lt;br&gt;<br /> Si un problema aparece en la página 3 de tu tesis de titulación de 1000 páginas, entonces primero intenta ver si el problema tambien ocurre si quitas toda las páginas excepto la tercera, si es así, entonces adjunta una versión simplificada del documento y no todas las 1000 páginas.&lt;/p&gt;<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Proporcionar_descripciones_paso_por_paso&diff=198420 2011-11-14T19:46:11Z

<p>Hohenheim: </p> <hr /> <div>==Proporcionar descripciones paso por paso==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Usted como el &#039;Submiter&#039; de un problema, sabe exactamente lo que estaba haciendo cuando se vio afectado por el problema.<br /> Sin embargo, la mayoria probablemente no. Por ejemplo puede tener un flujo de trabajo completamente diferente de hacer las mismas cosas que esta haciendo. Incluso una expresión tan inocente como &quot;dar formato al texto en negrita&quot; tiene el  potencial de un mal entendido. Por lo tanto un problema de descripción tal como &quot;Cuando trato de dar formato al texto en negrita OpenOffice.org deja de funcionar.&quot; No solo es de poca ayuda, sino que obliga a la gente a preguntar que quisiste decir.<br /> Este puede ser un ejemplo trivial, y podrias argumentar que otras persoans simplemente pueden intentar, y<br /> después eventualmente podrán encontrar el problema y así saber lo que querias decir.&lt;/p&gt;<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Proporcionar_un_resumen_con_significado&diff=198419 2011-11-14T19:45:50Z

<p>Hohenheim: </p> <hr /> <div>==Proporcionar un resumen significativo==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Muchas personas tienen que lidiar con un alto número  &#039;issues&#039; sobre una base regular. Usualmente esto pasa con la generación de reportes de &#039;issues&#039; donde el resumen de todo los &#039;issues&#039;, además de algunos datos  adicionales son mostrados. Por lo tanto, el resumen de un &#039;issue&#039; es de mucha importancia: si se elije correctamente, te permite:&lt;br&gt;<br /> &lt;br&gt;<br /> Reconocer fácilmente un problema de una lista de docenas de otros.&lt;br&gt;<br /> &lt;br&gt;<br /> Encontrar un &#039;issue&#039;. Dado a que los &#039;issues&#039; duplicados estan drenando un monton de trabajo de los miembros de la comunidad, siempre les pedimos a las personas revisar si su problema, el cual van a  reportar como &#039;issue&#039;, ya ha sido conocido y reportado. Por supuesto, esto funciona mejor si los resumenes de los &#039;issues&#039; existentes son lo mas descriptivos posible.&lt;br&gt;<br /> &lt;br&gt;<br /> Juzgar la importancia de un problema. &quot;El problema de hoja de calculo&quot;, es menos probable que se maneje apropiadamente que &quot;Hoja de cálculo: La pérdida de dados cuando ... &quot; o &quot;Etiqueta X en diálogo Y tiene un mal desplazamiento (2 px).&lt;br&gt;<br /> &lt;br&gt;<br /> Por lo tanto, evite resúmenes como &quot;Gran error en OpenOffice.org&quot; o &quot; Problema de impress&quot; no son realmente de mucha ayuda y obligan a la gente a perder el tiempo, para dar con el &#039;issue&#039; (en lugar de ver un informe) para ver de que se trata.&lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Un_problema_-_Un_%27issue%27&diff=198418 2011-11-14T19:45:10Z

<p>Hohenheim: </p> <hr /> <div>==Un problema - Un &#039;issue&#039;==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Al informar de un problema, por favor envíe un &#039;issue&#039; por cada problema. Hay varias razonespara esto, entre ellas:&lt;br&gt;<br /> &lt;br&gt;<br /> Entre más poblado sea un &#039;issue&#039;, lo más probable es que algunos problemas pueden perderse con el tiempo.<br /> Diferentes problemas tienen más probabilidades de ser manejados por personas diferentes (tanto en la ingeniería,donde se fija el problema, y en el control de calidad, donde se verifica).&lt;br&gt;<br /> Entre mas problemas más que poner en el asunto, más difícil es el tema de manejar para todas las partes involucradas.<br /> En particular, si vas a escribir frases como: &quot;Además de esto, me di cuenta de que ....&quot; o &quot;Hay varios problemas con ....&quot;, por favor, en serio se pregunta si debe presentar múltiples problemas en lugar de uno solo.<br /> Si usted no sigue esta regla, debe estar preparado para las personas que le pedirá dividir tu problema.&lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Reglas_para_usar_un_Issue_Tracker&diff=198417 2011-11-14T19:44:54Z

<p>Hohenheim: </p> <hr /> <div>==Reglas b&amp;aacute;sicas para usar un Issue Tracker==<br /> <br /> Antes de hacer uso de un issue tracker debes tener en mente que el issue que reportes no solo lo lee una persona, sino que este es revisado por diferentes personas como:<br /> <br /> *Miembros de la comunidad quienes estan clasificando defectos.<br /> *Desarrolladores quienes estan finalmente solucionando defectos.<br /> *A veces desarrolladores que necesitan hacer trabajo preliminar.<br /> *Ingenieros QA quienes necesitan verificar la solución.<br /> *Todos aquellos que tienen el mismo problema e intentan comprender si tu defecto también describe su problema o si tu &#039;issue&#039; es uno por el que les gustaría votar.<br /> *Posiblemente un miembro del equipo de experiencia del usuario que están evaluando una solicitud de función.<br /> *Posiblemente un miembro del equipo de liberación evaluando si el defecto es suficientemente importante para ser incluido en la actualización de mantenimiento.<br /> *Como se puede ver, hay muchas personas involucradas, que pueden leer lo que escribes. Por eso, la mayoría de las reglas se enfocan  en hacer más fácil la lectura. Aunque a veces toma un poco mas de tiempo entenderlo, a menudo ayuda a ahorrarle un montón de tiempo a otros mas adelante.&lt;br&gt;<br /> &lt;br&gt;<br /> Así que por favor, no solo cuando se presentes nuevos problemas, sino también cuando se agregan comentarios a los problemas existente, trata de ayudar a otros respetando estas sencillas reglas.&lt;br&gt;<br /> <br /> Ya que no seguirlas hacen el manejos del problemas mas difícil ( a veces mucho mas difícil), muchas personas tienden a no hacerle frente a sus problemas, hasta que estén en una forma mas razonable para hacerlo.<br /> <br /> A continuación las reglas:&lt;br&gt;<br /> &lt;br&gt;<br /> *[[OOoES/Calidad/Gestion de la Calidad: Un problema - Un &#039;issue&#039;|Un problema - Un &#039;issue&#039;]]<br /> *[[OOoES/Calidad/Gestion de la Calidad: Proporcionar un resumen con significado|Proporcionar un resumen con significado]]<br /> *[[OOoES/Calidad/Gestion de la Calidad: Proporcionar descripciones paso por paso|Proporcionar descripciones paso por paso]]<br /> *[[OOoES/Calidad/Gestion de la Calidad: Proporcionar documentos de ejemplo si es posible|Proporcionar documentos de ejemplo si es posible]]<br /> *[[OOoES/Calidad/Gestion de la Calidad: Usar adjuntos cuando sea posible|Usar adjuntos cuando sea posible]]<br /> *[[OOoES/Calidad/Gestion de la Calidad: Ponga toda la información relevante dentro del isssue|Ponga toda la información relevante dentro del isssue]]<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Manejo_de_Issues&diff=198416 2011-11-14T19:43:20Z

<p>Hohenheim: </p> <hr /> <div>==Manejo de Issues==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Se hablará de como los &#039;issues&#039; son tratados dentro del departamento de control de calidad (QA) de OOo.<br /> <br /> Bueno dando clic aqui puedes encontrar una guía, la cual neesitaremos probablemente cuando tengamos algun problema con OOo. Tal vez la aplicacion falló, algun comportamiento inesperado o algo mas que nos  haga sentir que algo esta mal. Lo mas probable es que hayamos encontrado un issue/bug (problema, defecto) que debe ser resuelto. Cuando eres nuevo reportando issues esa página te ayudará a entender la forma en que un &#039;issue&#039; es tratado desde que es encontrado hasta que finalmente se soluciona.&lt;/p&gt;<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;<br /> #Se recomienda que empieces iniciando sesión en un &#039;IssueTracker&#039;. Si deseas aprender sobres los beneficios de ser un Issue Tracker lee esto.<br /> #Por favor  busca en la base de datos del &#039;IssueTracker&#039; para asegurarte que tu &#039;issue&#039; aún no existe. Haz una búsqueda rápida de duplicados o haz una más avanzada con los criterios que creas necesarios aqui. Si tu &#039;issue&#039; ya existe, quizá te gustaría registrarlo (en el bookmark) o establecerte en el CC para darle seguimiento.<br /> #¿No encontraste tu &#039;issue&#039; en la base de datos? Bueno, adelante reporta uno nuevo usando un formulario como éste. Si tu no estas familiarizado reportando buenos reportes de bugs, te recomendamos leer esto. Siguiendo estas simples reglas realmente te hará la vida mas sencilla, si quisieras saber un poco mas, quizá podrías leer también estodetalladamente. (link no disponible por el momento :S)<br /> #El &#039;issue&#039; necesita ser confirmado, cuando eres nuevo en OOo, no estas autorizado para confirmar tus &#039;ssues&#039; tu mismo, así que alguien con los permisos requeridos tomará cartas en el asunto. El voluntario OOo tratará de reproducir tu mismo problema y -en caso de falla- te contactará y pedirá mas información. Si la reproducción tiene éxito, al &#039;issue&#039; se le asigna un &#039;target&#039; (un objetivo/blanco), y será entregado al equipo de desarrollo para solucionarlo. Si el &#039;issue&#039; no puede ser reproducido es cerrado.<br /> #Tu &#039;issue&#039; es añadido a un CWS (ChildWorkSpace). El CWS es creado, y es en el cual tu &#039;issue&#039; es solucionado por un desarrollador. Cuando la solución esta lista el CWS es enviado a Control de Calidad (QA).<br /> #El &#039;issue&#039; necesita ser verificado en el CWS tu issue ahora será verificado, lo cual significa que alguien (que también podría ser tu), echa un vistazo, ejecutando una compilación de desarrollo del CWS. Si la solución no es buena (falló completamente o es insuficiente) regresa a desarrollo.<br /> #La solución es buena, y se integra dentro del MWS. El &#039;issue&#039; ahora tiene el status de fixed/verified (solucionado/verificado) y se integra dentro de la línea de desarrollo principal y puedes descargarla.<br /> #Verificación final de la solución, de nuevo alguien verifica que la solución no se corrompió o perdió por accidente. Si todo salió bien, el status es cambiado a closed/fixed (cerrado/solucionado). Cualquier problema, la tarea regresa a desarrollo y el ciclo comienza de nuevo.<br /> &lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Anatomia_de_un_Bug&diff=198415 2011-11-14T19:43:00Z

<p>Hohenheim: </p> <hr /> <div>==Anatom&amp;iacute;a de un Bug==<br /> Para poder tener un mayor conocimientos sobre los elementos que conforman el reporte de un bug, aquí esta la explicación de los elementos que intervienen en este proceso.<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;1.- Producto y componente: Los bugs estan divididos por producto y componente, con un producto teniendo uno o mas compoenentes en el. Por ejemplo, el producto Bugzilla de bugzilla.mozilla.org esta compuesto de muchos componentes. Administración: La administración de una instalación de Bugzilla.&lt;br&gt;<br /> &lt;br&gt;Bugzilla General: Todo lo que no cabe en los otros componentes, o se extiende por varios componentes.<br /> Creación / Modificación de Bugs: La creación, modificación y visualización de errores.&lt;br&gt;<br /> Documentación: La documentación Bugzilla, incluyendo la guía de Bugzilla.&lt;br&gt;<br /> Email: Todo lo relacionado con el correo electrónico enviado por Bugzilla.&lt;br&gt;<br /> Instalación: El proceso de instalación de Bugzilla.&lt;br&gt;<br /> Consulta / Buglist: Todo lo relacionado con la búsqueda de errores y ver la buglists.<br /> Informes / Gráficos: Cómo los informes de Bugzilla.<br /> Cuentas de usuario: Todo sobre el manejo de una cuenta de usuario desde la perspectiva del usuario. Las consultas guardadas, crear cuentas, cambiar contraseñas, acceder al sistema, etc.<br /> Interfaz de usuario: temas generales que tienen que ver con la cosmética de interfaz de usuario (no funcionalidad), incluyendo problemas estéticos, plantillas HTML, etc.&lt;br&gt;<br /> &lt;br&gt;<br /> 2.- Estado y la Resolución: Estos definen exactamente el estado en el que esta el error - ni siquiera de ser confirmado como un error, a través de ser arreglado y el arreglo confirmado por Aseguramiento de la Calidad. Los diferentes valores posibles para el estado y la Resolución de la instalación debe estar documentada en la ayuda contextual para esos elementos.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> 3.- Asignado a: La persona responsable de corregir el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 4.- Contacto Control de calidad: La persona responsable de la garantía de calidad en este error.&lt;br&gt;<br /> &lt;br&gt;<br /> 5.- URL: Un URL asociada con el error, en su caso.&lt;br&gt;<br /> &lt;br&gt;<br /> 6.- Resumen: Un resumen de una sentencia del problema.&lt;br&gt;<br /> &lt;br&gt;<br /> 7.- Pizarra de Estado: (también conocido como pizarra) Una forma libre del área de texto para agregar notas breves y las etiquetas a un error.&lt;br&gt;<br /> &lt;br&gt;<br /> 8.- Palabras clave: El administrador puede definir palabras clave que puede utilizar para etiquetar y clasificar los errores - por ejemplo, El Proyecto Mozilla tiene como palabras clave accidente y la regresión.&lt;br&gt;<br /> &lt;br&gt;<br /> 9.- Plataforma y sistema operativo: Indican el entorno informático, donde se encontró el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 10.- Versión: El campo de &quot;version&quot; se utiliza generalmente para las versiones de un producto que han sido liberados, y se fija para indicar qué versiones de un componente sobre el cual un reporte de bug tiene un problema particular.&lt; br&gt;<br /> &lt;br&gt;<br /> 11.- Prioridad: El cesionario de errores utiliza este campo para priorizar sus errores. Es una buena idea de no cambiar esta situación en los errores de otras personas.&lt;br&gt;<br /> &lt;br&gt;<br /> 12.- Gravedad: Esto indica qu￩ tan grave es el problema - de bloqueo (&quot;aplicación inservible&quot;) a lo trivial (&quot;cuestión estética menor&quot;). También puede utilizar este campo para indicar si un error es una solicitud de mejora.&lt;br&gt;<br /> &lt;br&gt;<br /> 13.- Objetivo: (Milestone objetivo aka) Una versión futura por la cual  el bug sera arreglado. por ejemplo Los hitos del proyecto Bugzilla, Bugzilla para las versiones futuras son 2.18, 2.20, 3.0, etc hitos no se limitan a los números, el pensamiento - puede utilizar cualquier cadena de texto, como las fechas.&lt;br&gt;<br /> &lt;br&gt;<br /> 14.- Reportero: La persona que presentó el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 15.- Lista de CC: Una lista de las personas que reciben correo electrónico cuando cambia el error.&lt;br&gt;<br /> &lt;br&gt;<br /> 16.- Time tracking:  Este formulario se puede utilizar para el seguimiento del tiempo. Para utilizar esta función, tienes que ser bendecido pertenencia a un grupo especificado por el parámetro &quot;timetrackinggroup&quot;.&lt;br&gt;<br /> &lt;br&gt;<br /> 17.- Adjuntos: Se pueden adjuntar archivos (por ejemplo, casos de prueba o parches) para los bugs. Si hay algn archivo adjunto, que se enumeran en esta sección. Los archivos adjuntos se almacenan normalmente en la base de datos Bugzilla, a menos que están marcados <br /> como archivos grandes, que se almacenan directamente en el disco.&lt;br&gt;<br /> &lt;br&gt;<br /> 18.- Dependencias: Si este error no se puede solucionar a menos que los errores son fijos (depende), o este error deja de otros bugs <br /> que se fija (bloques), sus números se registran aquí.&lt;br&gt;<br /> &lt;br&gt;<br /> 19.- Votos: Si este error se ha asignado ningn voto.&lt;br&gt;<br /> &lt;/p&gt;<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Reporte_de_Bugs&diff=198414 2011-11-14T19:42:45Z

<p>Hohenheim: </p> <hr /> <div>==Reporte de Bugs==<br /> <br /> Como bien se sabe, para poder reportar o dar seguimiento a diferentes issues/bugs se debe utilizar un issue tracker, el que esta utilizando OpenOffice.org actualmente es Bugzilla, al cual puedes acceder dando clic [https://bugs.freedesktop.org aquí] , y posteriormente te mostramos una guía útil de como usar este issue tracker.<br /> <br /> <br /> El procedimiento para reportar un bug es el siguiente:<br /> <br /> 1. Clic en link &quot;New&quot; disponible en el pie de pagina de las paginas, o en el link &quot;Enter a new bug report&quot; mostrado en la pagina de inicio de la Instalacion de Bugzilla.<br /> <br /> 2. Primero debes seleccionar el producto en el cual encontraste el bug.<br /> <br /> 3.Ahora aparecerá un formulario donde puede especificar el componente (parte del producto que se ve afectado por el error que has descubierto, y si no tienes ni idea, sólo tienes que seleccionar &quot;General&quot; si existe un componente), la versión del programa que el uso, el sistema operativo y la plataforma de su programa se está ejecutando y la gravedad del error ( si el error encontrado bloquea el programa), es probablemente un error mayor o critico, si hay un error en alguna otra parte es es algo menor, si se trata de algo que te gustaria ver implementado, entonces es una mejora.<br /> <br /> 4. Ahora tiene que dar un resumen corto pero descriptivo del error que has encontrado. &quot;Mi programa se bloquea todo el tiempo&quot; es un resumen muy pobre y no ayuda a los desarrolladores de todos. Intente algo más significativo,o tu bug era probablemente ignorado ebido a tu falta de precision. El siguiente paso es dar una lista muy detallada de los pasos para reproducir el problema que has encontrado. Trate de limitar estos pasos para un conjunto mínimo necesario para reproducir el problema, esto hará mas facil la vida del desarrollador, y la probabilidad de que se considere su error en un plazo razonable, sera mucho mayor.<br /> <br /> Nota: Trata de asegurarte que todo en el resumen esta tambien en el primer comentario. Los resumenes son a menudo actualizados y esto asegurara que su informacion original sea de facil acceso.<br /> <br /> 5. A medida que el archivo de errores, también puede adjuntar un documento (caso_prueba, parche o captura de pantalla del problema).<br /> <br /> 6. Dependiendo de la instalación de Bugzilla que está utilizando y el producto en el que está presentando el error, también puede solicitar a los desarrolladores a considerar si el fallo de diferentes maneras (por ejemplo, solicitar la revisión por el parche que acabas de adjuntar, solicitando su error al bloquear la próxima lanzamiento del producto, y muchas solicitudes de otros productos específicos).<br /> <br /> 7. Ahora es un buen momento para leer su informe de error de nuevo. Eliminar todas las faltas de ortografía, de lo contrario el error no puede ser encontrado por los desarrolladores ejecutar consultas de algunas palabras específicas, por lo que su error no tendría la menor atención. Además, asegúrese de no olvidar ninguna información importante a los desarrolladores deben saber con el fin de reproducir el problema, y asegúrese de que su descripción del problema es lo suficientemente explícito y claro. Cuando usted piensa en su informe de error está listo para ir, el último paso es hacer clic en el &quot;Comité&quot; para añadir su informe en la base de datos.<br /> <br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Software_Testing&diff=198413 2011-11-14T19:42:11Z

<p>Hohenheim: </p> <hr /> <div>==Software Testing==<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Pruebas del Software (Software Testing) <br /> <br /> Es una investigaci&amp;oacute;n llevada a cabo para proporcionar a los interesados ​​informaci&amp;oacute;n sobre la calidad del producto o servicio bajo prueba. También provee una objetiva e independiente vista hacia el software que permite apreciar y entender los riesgos de la implementaci&amp;oacute;n del software.&lt;br&gt; <br /> &lt;br&gt;<br /> Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería del software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.&lt;br&gt;<br /> <br /> &lt;br&gt;<br /> Las técnicas de prueba incluyen el proceso de un programa o aplicaci&amp;oacute;n con la intenci&amp;oacute;n de encontrar errores de software (software bugs).<br /> &lt;br&gt;<br /> Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigaci&amp;oacute;n más que seguir un procedimiento al pie de la letra. Una definici&amp;oacute;n de &quot;testing&quot; es: proceso de evaluaci&amp;oacute;n de un producto desde un punto de vista crítico, donde el &quot;tester&quot; (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacci&amp;oacute;n. Por supuesto, nunca se debe testear el software en un entorno de producci&amp;oacute;n. Es necesario testear los nuevos programas en un entorno de pruebas separado físicamente del de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producci&amp;oacute;n es necesario crear las mismas condiciones que en la máquina de producci&amp;oacute;n. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.&lt;br&gt;<br /> &lt;br&gt;<br /> En general, los infromáticos distinguen entre errores de programación (o &quot;bugs&quot;) y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo.&lt;br&gt;<br /> &lt;br&gt;<br /> Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de &quot;testers&quot; al finalizar su desarrollo y antes de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versi&amp;oacute;n no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versi&amp;oacute;n del producto en pruebas y que es anterior a la versión final (o &quot;master&quot;) se denomina beta, y a dicha fase de pruebas, beta testing.&lt;br&gt;<br /> &lt;br&gt;<br /> Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM testing (Release To Market), dónde se comprueba cada funcionalidad del programa completo en entornos de producción. Otra práctica es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y continúe hasta que finaliza.&lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Soporte_de_Control_de_Calidad&diff=198412 2011-11-14T19:41:40Z

<p>Hohenheim: </p> <hr /> <div>==Soporte de Control de Calidad==<br /> <br /> Contribuir en OOo es muy fácil, mas de lo que piensas, primero debes registrarte como usuario en OOo.&lt;br&gt;<br /> &lt;br&gt;<br /> El soporte de Control de Calidad en OOo esta graduada en 3 pasos de participación.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> *El primer paso es &quot;Reportar Bugs&quot;, significa para los novatos adquirir conocimiento general sobre &#039;issues&#039; en común. Los participantes en la primera etapa son capaces de encontrar y escribir &#039;issues&#039;  solos. El link contiene toda la información que necesitas para saber como empezar a contribuir.&lt;br&gt;<br /> &lt;br&gt;<br /> <br /> *El segundo paso es &quot;Pruebas manuales&quot;, el cual esta dirigido a los participantes con mas habilidades. Son capaces de hacer pruebas manuales por su cuenta. Pueden ejecutar y escribir Test-Case-Specifications (TCS), y presentar &#039;issues&#039; encontrados al tratar con TCS. La página contiene toda la información necesaria para contribuir en el segundo paso de participación.&lt;br&gt;<br /> &lt;br&gt;<br /> *En el tercer paso de participación &quot;&#039;Únete a QA&quot; puedes aplicarte para unirte al aquipo QA de OOo en una de las OOo &#039;Teamleads&#039;. Ahora has recolectado suficiente conocimientos sobre manejo de &#039;issues&#039;  (issue handling) para confirmarlos y cerrarlos por ti mismo. El llegar a esta etapa de participación trae muchas ventajas: tienes contacto directo con los desarrolladores de StarOffice / OpenOffice.org y con ingenieros QA. Será listado directamente como un miembro del equipo QA de OOo. Serás capaz de enviar  &#039;issues&#039; por ti mismo directo al ingeniero responsable , obtienes una responsabilidad  directa, más derechos (como &#039;caconfirm&#039;) y mas peso en las decisiones.<br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad&diff=198411 2011-11-14T19:41:26Z

<p>Hohenheim: </p> <hr /> <div>== Control de Calidad ==<br /> <br /> En este apartado podr&amp;aacute;s encontrar informaci&amp;oacute;n de mucha ayuda para el &amp;aacute;rea de aseguramiento de la calidad, as&amp;iacute; como el proceso de testing.<br /> <br /> A continuaci&amp;oacute;n se listan los temas que te pueden ser de gran ayuda,<br /> <br /> === Control de la Calidad del Software ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Control de Calidad del Software|Control de Calidad del Software]]<br /> <br /> === Soporte de Control de Calidad ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Soporte de Control de Calidad|Soporte de Control de Calidad]]<br /> <br /> === Software Testing (Pruebas de Software) ===<br /> [[OOoES/Calidad/Gestion de la Calidad: Software Testing|Software Testing]]<br /> <br /> ===Reporte de Bugs===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reporte de Bugs|Reporte de Bugs]]<br /> <br /> ===Anatom&amp;iacute;a de un Bug===<br /> [[OOoES/Calidad/Gestion de la Calidad: Anatomia de un Bug|Anatomia de un Bug]]<br /> <br /> ===Manejo de Issues===<br /> [[OOoES/Calidad/Gestion de la Calidad: Manejo de Issues|Manejo de Issues]]<br /> <br /> ===Reglas b&amp;aacute;sicas para usar un Issue Tracker===<br /> [[OOoES/Calidad/Gestion de la Calidad: Reglas para usar un Issue Tracker|Reglas para usar un Issue Tracker]]<br /> <br /> <br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Control_de_Calidad_del_Software&diff=198410 2011-11-14T19:41:06Z

<p>Hohenheim: </p> <hr /> <div>==Control de Calidad del Software==<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Las pruebas del software (software testing) son parte del proceso de control de calidad del software (SQA), donde especialistas en procesos de software y auditores están preocupados por el proceso de desarrollo de software en lugar de los artefactos, tales como documentación, código y sistemas. Ellos examinan y cambian el proceso de ingeniería del software en sí para reducir la cantidad de errores en el software entregado: denominada tasa de defectos.&lt;br&gt;<br /> &lt;br&gt;<br /> Lo que constituye una “Aceptable tasa de defectos” depende de la naturaleza del software; un simulador de vuelo de un juego de video podría tener una tolerancia mucho más alta que un software para un avión real.&lt;br&gt;<br /> &lt;br&gt;<br /> Aunque existe una estrecha relación con SQA, los departamentos de pruebas a menudo existen de forma independiente, y podría no haber funciones SQA en algunas compañías.&lt;br&gt;<br /> &lt;br&gt;<br /> Las pruebas de software son una tarea destinada a detectar los defectos en el software contrastando los resultados esperados de un programa informático con los resultados reales de un conjunto dado de entradas. Por el contrario, QA (control de calidad) es la implementación de las políticas y procedimientos destinados a prevenir los defectos que se produzcan en primer lugar.&lt;br&gt;<br /> &lt;br&gt;<br /> OpenOffice.org cuenta con un Departamento de SQA, el cual mantiene relación con las pruebas del software. Su comunidad de QA es un importante grupo creciente. El proyecto es liderado por Nakata Maho y los co-líderes son Caio Tiago Oliveira y Joost Andrae. Un equipo de más de 20 ingenieros QA a tiempo completo de Oracle. Los gerentes de los equipos son Thorsten Ziehm y Joerg Jahnke.<br /> &lt;/p&gt;<br /> <br /> [[Category:ES]]<br /> [[Category:Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Control_de_Calidad_del_Software&diff=198409 2011-11-14T19:36:35Z

<p>Hohenheim: /* Control de Calidad del Software */</p> <hr /> <div>==Control de Calidad del Software==<br /> <br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Las pruebas del software (software testing) son parte del proceso de control de calidad del software (SQA), donde especialistas en procesos de software y auditores están preocupados por el proceso de desarrollo de software en lugar de los artefactos, tales como documentación, código y sistemas. Ellos examinan y cambian el proceso de ingeniería del software en sí para reducir la cantidad de errores en el software entregado: denominada tasa de defectos.&lt;br&gt;<br /> &lt;br&gt;<br /> Lo que constituye una “Aceptable tasa de defectos” depende de la naturaleza del software; un simulador de vuelo de un juego de video podría tener una tolerancia mucho más alta que un software para un avión real.&lt;br&gt;<br /> &lt;br&gt;<br /> Aunque existe una estrecha relación con SQA, los departamentos de pruebas a menudo existen de forma independiente, y podría no haber funciones SQA en algunas compañías.&lt;br&gt;<br /> &lt;br&gt;<br /> Las pruebas de software son una tarea destinada a detectar los defectos en el software contrastando los resultados esperados de un programa informático con los resultados reales de un conjunto dado de entradas. Por el contrario, QA (control de calidad) es la implementación de las políticas y procedimientos destinados a prevenir los defectos que se produzcan en primer lugar.&lt;br&gt;<br /> &lt;br&gt;<br /> OpenOffice.org cuenta con un Departamento de SQA, el cual mantiene relación con las pruebas del software. Su comunidad de QA es un importante grupo creciente. El proyecto es liderado por Nakata Maho y los co-líderes son Caio Tiago Oliveira y Joost Andrae. Un equipo de más de 20 ingenieros QA a tiempo completo de Oracle. Los gerentes de los equipos son Thorsten Ziehm y Joerg Jahnke.<br /> &lt;/p&gt;<br /> <br /> [[Category:ES|Quality Assurance]]</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Ponga_toda_la_informaci%C3%B3n_relevante_dentro_del_isssue&diff=198408 2011-11-13T23:46:25Z

<p>Hohenheim: Created page with &quot;==Ponga toda la información relevante dentro del &#039;issue&#039;== No solo uses links para referenciar las descripciones del bug. Los links tienen a volverse obsoletos, asi que si en …&quot;</p> <hr /> <div>==Ponga toda la información relevante dentro del &#039;issue&#039;==<br /> <br /> <br /> No solo uses links para referenciar las descripciones del bug. Los links tienen a volverse obsoletos, asi que si en medio año, alguien ve tu &#039;issue&#039;,  éste ha perdido su significado.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Usar_adjuntos_cuando_sea_posible&diff=198407 2011-11-13T23:46:07Z

<p>Hohenheim: Created page with &quot;==Usa adjuntos cuando sea posible== No adjuntes grandes archivos en la descripción. Si se le solicita proporcionar un ejemplo del problema, copie el ejemplo del problema en un…&quot;</p> <hr /> <div>==Usa adjuntos cuando sea posible==<br /> <br /> <br /> No adjuntes grandes archivos en la descripción. Si se le solicita proporcionar un ejemplo del problema, copie el ejemplo del problema en un archivo y adj&amp;uacute;ntelo.</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Proporcionar_documentos_de_ejemplo_si_es_posible&diff=198406 2011-11-13T23:45:49Z

<p>Hohenheim: Created page with &quot;==Proporcionar documentos de ejemplo, si es posible== &lt;p style=&quot;text-align:justify;&quot;&gt;Si hay un problema con un documento en particular, entonces adjuntalo. Esto a menudo le perm…&quot;</p> <hr /> <div>==Proporcionar documentos de ejemplo, si es posible==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Si hay un problema con un documento en particular, entonces adjuntalo. Esto a menudo le permite y facilita realmente a las personas a reproducir tu problema solo abriendo el documento adjunto. Si la descripción de como se reproduce un defecto excede cierto limite, pregúntate si puedes  reportar el resultado de la descripción con un documento de ejemplo y adjuntalo al &#039;issue&#039;.&lt;br&gt;<br /> &lt;br&gt;<br /> Si un problema aparece en la página 3 de tu tesis de titulación de 1000 páginas, entonces primero intenta ver si el problema tambien ocurre si quitas toda las páginas excepto la tercera, si es así, entonces adjunta una versión simplificada del documento y no todas las 1000 páginas.&lt;/p&gt;</div>

Hohenheim https://wiki.openoffice.org/w/index.php?title=OOoES/Calidad/Gestion_de_la_Calidad:_Proporcionar_descripciones_paso_por_paso&diff=198405 2011-11-13T23:45:34Z

<p>Hohenheim: Created page with &quot;==Proporcionar descripciones paso por paso== &lt;p style=&quot;text-align:justify;&quot;&gt;Usted como el &#039;Submiter&#039; de un problema, sabe exactamente lo que estaba haciendo cuando se vio afecta…&quot;</p> <hr /> <div>==Proporcionar descripciones paso por paso==<br /> <br /> &lt;p style=&quot;text-align:justify;&quot;&gt;Usted como el &#039;Submiter&#039; de un problema, sabe exactamente lo que estaba haciendo cuando se vio afectado por el problema.<br /> Sin embargo, la mayoria probablemente no. Por ejemplo puede tener un flujo de trabajo completamente diferente de hacer las mismas cosas que esta haciendo. Incluso una expresión tan inocente como &quot;dar formato al texto en negrita&quot; tiene el  potencial de un mal entendido. Por lo tanto un problema de descripción tal como &quot;Cuando trato de dar formato al texto en negrita OpenOffice.org deja de funcionar.&quot; No solo es de poca ayuda, sino que obliga a la gente a preguntar que quisiste decir.<br /> Este puede ser un ejemplo trivial, y podrias argumentar que otras persoans simplemente pueden intentar, y<br /> después eventualmente podrán encontrar el problema y así saber lo que querias decir.&lt;/p&gt;</div>

Hohenheim