No todos, pero muchos obst\u00e1culos en la gesti\u00f3n de pruebas pueden eliminarse de antemano con las siguientes reglas.<\/p>\n
Redactar un concepto de prueba: con recursos limitados y plazos ajustados, \u00bfpor qu\u00e9 deber\u00eda el equipo de gesti\u00f3n de pruebas tomarse la molestia de crear y aprobar un concepto de prueba?<\/p>\n
El truco est\u00e1 en mantener el concepto lo m\u00e1s breve y conciso posible y visualizar mediante gr\u00e1ficos cuestiones complejas, como un entorno de pruebas con muchas interfaces.<\/p>\n
Los componentes esenciales de un concepto de prueba incluyen, por ejemplo, la definici\u00f3n de los objetos y objetivos de la prueba, los criterios de aceptaci\u00f3n y el procedimiento de aceptaci\u00f3n, as\u00ed como la presentaci\u00f3n de la infraestructura de la prueba (sistemas SAP, rutas de transporte, fechas de transporte). Haga aprobar el concepto por el departamento de desarrollo y la parte empresarial.<\/p>\n
Invertir tiempo suficiente en la calidad de los casos de prueba. Los departamentos especializados suelen carecer de tiempo para crear los casos de prueba. Como resultado, estos se \"reciclan\" de proyectos antiguos, son demasiado generales, demasiado granulares o no cubren las funciones que hay que probar y aceptar.<\/p>\n
El resultado: los probadores especializados prueban demasiado o demasiado poco, pero no las funciones necesarias. El progreso es demasiado lento, la tasa de error es demasiado alta y las mejoras de calidad son demasiado peque\u00f1as. Los departamentos especializados (y no los de TI) deber\u00edan tomarse el tiempo necesario para crear los casos de prueba.<\/p>\n
Priorice sus casos de prueba. El Departamento A suele querer probar todas las funciones nuevas hasta el \u00faltimo detalle y someter el software ya implantado a una prueba de integraci\u00f3n completa que incluya pruebas por lotes y pruebas de extremo a extremo con terceros y otros sistemas.<\/p>\n
El Departamento B, por su parte, opta por un enfoque pragm\u00e1tico con s\u00f3lo unos pocos casos de prueba, en funci\u00f3n de los plazos y la situaci\u00f3n de los recursos. Es importante encontrar la medida adecuada para el alcance de las pruebas.<\/p>\n
La mejor pr\u00e1ctica consiste en priorizar los casos de prueba. Un buen m\u00e9todo son las pruebas basadas en el riesgo. En este caso, se priorizan los casos de prueba, sobre todo en funci\u00f3n del alcance de los da\u00f1os en caso de mal funcionamiento.<\/p>\n
Planifique varios ciclos de pruebas. El primer ciclo de pruebas suele tener un comienzo muy accidentado. Hay bloqueos, los probadores a\u00fan no est\u00e1n familiarizados con la aplicaci\u00f3n y se producen muchos errores.<\/p>\n
El elevado n\u00famero de correcciones puede provocar efectos secundarios que obliguen a volver a probar casos de prueba que ya se han completado con \u00e9xito. Antes de que se d\u00e9 cuenta, el ciclo de pruebas ha terminado.<\/p>\n
Por lo tanto, t\u00f3mese un descanso despu\u00e9s del primer ciclo y d\u00e9 al equipo de desarrollo la oportunidad de rectificar todos los errores cr\u00edticos. A continuaci\u00f3n, inicie otro ciclo con un estado consolidado del software y los datos, en el que pruebe al menos todos los casos de prueba de calificaci\u00f3n alta y media del primer ciclo.<\/p>\n
Oc\u00fapese a tiempo del entorno de pruebas. Una situaci\u00f3n t\u00edpica: los casos de prueba est\u00e1n listos, los empleados del departamento quieren empezar, pero la prueba no puede iniciarse porque el sistema SAP no est\u00e1 disponible.<\/p>\n
Hay muchas razones para ello. El sistema no se reserv\u00f3 a tiempo y est\u00e1 ocupado por otros proyectos. O el equipo de desarrollo no fue capaz de desplegar el software en los sistemas de prueba, o no del todo.<\/p>\n
A menudo faltan interfaces importantes y necesarias o identificadores y autorizaciones de usuario adecuados. Por lo tanto, debe planificar su entorno de pruebas en una fase temprana y supervisar el despliegue completo y correcto.<\/p>\n
El primer pilar se establece definiendo los criterios de entrada en el concepto de prueba. Si no se cumplen las condiciones esenciales, no se inicia.<\/p>\n
Defina en el concepto o en un plan de entorno de prueba exactamente qu\u00e9 sistemas SAP con qu\u00e9 stock de datos son necesarios y cu\u00e1ndo, qu\u00e9 interfaces deben conectarse a trav\u00e9s de qu\u00e9 sistemas de terceros, qu\u00e9 ID de usuario deben disponer de qu\u00e9 autorizaciones y cu\u00e1ndo deben transportarse las correcciones de software.<\/p>\n
Utilice una herramienta integrada de gesti\u00f3n de pruebas y defectos. La herramienta m\u00e1s utilizada para la gesti\u00f3n de pruebas y defectos es Excel.<\/p>\n
Funciona bastante bien hasta un n\u00famero de 100 a 150 casos de prueba con un bajo volumen de defectos. En cuanto aumenta el volumen, resulta cada vez m\u00e1s problem\u00e1tico gestionarlo con soluciones Excel propias.<\/p>\n
En particular, a menudo no hay una visi\u00f3n general de qu\u00e9 defectos afectan a qu\u00e9 casos de prueba. Tambi\u00e9n es dif\u00edcil generar el estado general actual o el progreso de las pruebas, posiblemente con previsiones.<\/p>\n
A menudo, las hojas de c\u00e1lculo de Excel (y especialmente las macros) s\u00f3lo pueden ser mantenidas por unas pocas personas o, en el peor de los casos, por un experto, y el uso de una herramienta integrada de gesti\u00f3n de pruebas y defectos es la mejor opci\u00f3n.<\/p>\n
Los componentes Test Workbench y Help Desk de SAP Solution Manager son ideales para los usuarios de SAP. No conllevan gastos de licencia, el esfuerzo de implantaci\u00f3n es manejable, de tres a cinco d\u00edas-persona, y los usuarios est\u00e1n familiarizados con las interfaces SAP.<\/p>\n
Realice una puesta en marcha de la prueba. El esfuerzo que invierta en una puesta en marcha bien preparada se recuperar\u00e1 en las operaciones de prueba diarias.<\/p>\n
El orden del d\u00eda debe incluir temas como objetivos, procedimientos, plazos, puertas de calidad, restricciones a las pruebas, informes de pruebas y defectos, as\u00ed como reuniones peri\u00f3dicas y conferencias telef\u00f3nicas.<\/p>\n
Aunque haya muchos participantes, invite a la inauguraci\u00f3n a todos los implicados, como los probadores especializados, el equipo de gesti\u00f3n de pruebas, el equipo de desarrollo, el equipo de control de lotes y el equipo de gesti\u00f3n del proyecto.<\/p>\n
Esto facilita la comunicaci\u00f3n posterior y ayuda a evitar muchas consultas innecesarias. Hacer que los documentos de lanzamiento y los informes de situaci\u00f3n, as\u00ed como los conceptos, est\u00e9n disponibles en un medio de f\u00e1cil acceso como MS SharePoint ha demostrado ser una buena idea.<\/p>\n
No empieces las pruebas demasiado pronto. El escenario habitual: las fechas de prueba y aceptaci\u00f3n est\u00e1n firmemente programadas. Los especialistas en pruebas est\u00e1n programados. Los responsables de la toma de decisiones quieren que el proyecto sea un \u00e9xito.<\/p>\n
Y el equipo de desarrollo sigue luchando contra las graves y\/o numerosas deficiencias del software. El jefe de desarrollo quiere aplazar la prueba; la direcci\u00f3n del proyecto quiere cumplir el plazo a toda costa.<\/p>\n
Los responsables suelen ceder a sus deseos e inician la prueba con conocimiento de los d\u00e9ficits y los riesgos asociados. \u00bfQu\u00e9 ocurre?<\/p>\n
Las primeras pruebas de aceptaci\u00f3n pueden seguir siendo positivas. Pero luego se encuentran muchos errores y se producen bloqueos en las pruebas. Los probadores se sienten frustrados. Y, sobre todo, esto repercute negativamente en los comit\u00e9s de proyecto, los departamentos implicados y, en algunos casos, el Consejo de Administraci\u00f3n.<\/p>\n
De ah\u00ed la recomendaci\u00f3n: aunque est\u00e9 muy presionado para cumplir la fecha prevista de inicio de las pruebas especializadas, posponga las pruebas si el software a\u00fan no est\u00e1 listo para ser probado. Te ahorrar\u00e1s muchos problemas a ti y a los probadores y, sobre todo, evitar\u00e1s da\u00f1ar la imagen de tu proyecto.<\/p>\n
\u00bfQu\u00e9 se puede hacer de forma preventiva? Definir y comprobar las puertas de calidad ha demostrado ser una buena idea. Definir en el concepto de prueba qu\u00e9 condiciones previas deben cumplirse para que las pruebas comiencen.<\/p>\n
Esto incluye, por ejemplo, pruebas de desarrolladores documentadas, la creaci\u00f3n de documentaci\u00f3n para el usuario, la puesta a disposici\u00f3n de la infraestructura de pruebas y el listado de errores sin resolver con fecha de correcci\u00f3n. Si no se cumple el requisito de calidad o no se cumple en grado suficiente, no se da luz verde a la prueba.<\/p>\n
Interrumpir las pruebas en caso de bloqueos. La ausencia de funciones importantes, un elevado n\u00famero de errores o restricciones en la infraestructura de pruebas, como sistemas que no funcionan, pueden provocar bloqueos en las pruebas.<\/p>\n
Los probadores no pueden empezar debido a la situaci\u00f3n general actual. Al mismo tiempo, hay mucha presi\u00f3n para completar el trabajo rutinario en el escritorio. Por supuesto, no es divertido enviar a los probadores a casa en ventanas de tiempo muy ajustadas.<\/p>\n
Sin embargo, en caso de duda, son m\u00e1s importantes las consecuencias negativas, como probadores insatisfechos y p\u00e1nico en los departamentos especializados o, posiblemente, en el consejo de administraci\u00f3n debido a la mala calidad del software. Puede aprovechar la interrupci\u00f3n para consolidar el software.<\/p>\n
Comun\u00edquese con los probadores. La comunicaci\u00f3n regular con los probadores es un factor clave para el \u00e9xito de su proyecto. Es importante la transparencia sobre la situaci\u00f3n actual, el estado de los errores, las restricciones, etc. Celebre reuniones peri\u00f3dicas sobre la situaci\u00f3n y los errores con los probadores y el equipo de desarrollo.<\/p>\n
Las reuniones diarias, por ejemplo, han dado buenos resultados. Intente hablar directamente con todo el mundo todos los d\u00edas para saber m\u00e1s sobre situaciones concretas de pruebas y supuestos errores. Implicar a los desarrolladores en las pruebas o para volver a probar los errores tambi\u00e9n ha demostrado ser una buena idea en situaciones complejas.<\/p>\n
Cada proyecto de gesti\u00f3n de pruebas en el entorno SAP es diferente y probablemente nunca habr\u00e1 un proceso de proyecto perfecto. Pero muchas cosas ser\u00e1n m\u00e1s f\u00e1ciles con las reglas b\u00e1sicas mencionadas anteriormente.<\/p>\n
En \u00faltima instancia, el objetivo es llevar la calidad del software al nivel necesario para un funcionamiento productivo en un proceso aceptado por todas las partes implicadas. El hecho de que no todos los errores se rectifiquen antes de la puesta en marcha es la norma y no la excepci\u00f3n.<\/p>","protected":false},"excerpt":{"rendered":"
Los proyectos de gesti\u00f3n de pruebas suelen ser dif\u00edciles: el software no est\u00e1 listo a tiempo, faltan sistemas de prueba y autorizaciones y los casos de prueba, si existen, son de mala calidad. <\/p>","protected":false},"author":1378,"featured_media":61274,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[4,1553],"tags":[10193,286],"coauthors":[21844],"class_list":["post-61786","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-management","category-1553","tag-sap-solution-manager","tag-solman","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",400,155,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-768x297.jpg",768,297,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-100x39.jpg",100,39,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-480x186.jpg",480,186,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-640x248.jpg",640,248,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-720x279.jpg",720,279,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-960x372.jpg",960,372,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",18,7,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",1000,387,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",600,232,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015.jpg",600,232,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/07\/2015-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"
Testmanagement-Projekte gestalten sich oft schwierig: Die Software ist nicht rechtzeitig fertig, Testsysteme und Berechtigungen fehlen und Testf\u00e4lle, falls vorhanden, sind von schlechter Qualit\u00e4t. <\/p>\n","category_list_v2":"Business-Management<\/a>, MAG 15-07<\/a>","author_info_v2":{"name":"Dieter Koenen, Innobis","url":"https:\/\/e3mag.com\/es\/author\/dieter-koenen\/"},"comments_num_v2":"0 comentarios","_links":{"self":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/61786","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/users\/1378"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/comments?post=61786"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/61786\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media\/61274"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media?parent=61786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/categories?post=61786"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/tags?post=61786"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/coauthors?post=61786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}