![\"\"](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2022\/04\/Atrevete-a-conocer-que-es-QA-segunda-parte.jpg\")
<\/p>\n<\/p>\n
Si est\u00e1s leyendo este art\u00edculo, entiendo que vienes de leer la primera parte<\/a>, donde os habl\u00e9 sobre los conceptos generales del software testing. Si no has le\u00eddo ese art\u00edculo,<\/a>\u00a0te recomiendo encarecidamente que lo hagas, ya que algunas cosas de las que voy a hablar a continuaci\u00f3n, est\u00e1n relacionadas con la primera parte<\/a>.<\/p>\n 1.1 Modelo en cascada (Waterfall)<\/strong><\/p>\n En la fase de prueba, un producto, ya dise\u00f1ado y codificado, se prueba exhaustivamente antes del lanzamiento. Sin embargo, la pr\u00e1ctica muestra que los errores y defectos de software detectados en esta etapa pueden ser demasiado caros de corregir, ya que el coste de un defecto tiende a aumentar a lo largo del proceso de desarrollo de software.<\/p>\n \u00bfQu\u00e9 se quiere decir con esto? Si se da un error en las especificaciones, detectarlo temprano en la etapa de planificaci\u00f3n no causar\u00eda p\u00e9rdidas significativas. Sin embargo, el da\u00f1o crece exponencialmente a lo largo de las etapas posteriores del proceso. Si se detecta un error de este tipo en la etapa de dise\u00f1o, se tendr\u00e1 que volver a trabajar en los dise\u00f1os. Pero si no se detecta el error antes de que se construya el producto, es posible que se tengan realizar cambios importantes en el dise\u00f1o y en el c\u00f3digo fuente. Esto requerir\u00e1 una cantidad significativa de esfuerzo e inversi\u00f3n.<\/p>\n Por lo tanto, es mejor probar cada parte mientras el producto a\u00fan se est\u00e1 construyendo. Aqu\u00ed es donde la metodolog\u00eda AGILE resulta interesante.<\/p>\n 1.2 Pruebas AGILE<\/strong><\/p>\n AGILE divide el proceso de desarrollo en partes m\u00e1s peque\u00f1as, iteraciones y sprints. Esto permite que sea el propio equipo el que eval\u00faa lo que hay que hacer en el proceso y corrija las fallas y los errores inmediatamente despu\u00e9s de que ocurran.<\/p>\n El objetivo principal del proceso es ofrecer nuevas funciones de software de forma r\u00e1pida y con la mejor calidad. Por lo tanto, este enfoque es menos costoso: corregir los errores al principio del proceso de desarrollo, antes de que aumenten los problemas, es significativamente m\u00e1s econ\u00f3mico y requiere menos esfuerzo. Adem\u00e1s, la comunicaci\u00f3n eficiente dentro del equipo y la participaci\u00f3n de todas las partes acelera el proceso y permite tomar decisiones m\u00e1s adecuadas.<\/p>\n El foco de prueba AGILE se trata m\u00e1s de construir una pr\u00e1ctica de control de calidad en lugar de tener un equipo de control de calidad.<\/p>\n 1.3 Pruebas en DevOps<\/strong><\/p>\n Para aquellos que tienen experiencia Agile, DevOps se convierte gradualmente en una pr\u00e1ctica com\u00fan. Esta nueva metodolog\u00eda de desarrollo de software requiere un alto nivel de coordinaci\u00f3n entre varias funciones de la cadena de entrega, a saber, desarrollo, control de calidad y operaciones.<\/p>\n DevOps a menudo se conoce como una extensi\u00f3n de Agile que cierra la brecha entre el desarrollo con el control de calidad y las operaciones. Sin embargo, a diferencia de Agile, DevOps incluye el concepto de desarrollo continuo donde el c\u00f3digo, escrito y comprometido con el control de versiones, se construir\u00e1, implementar\u00e1, probar\u00e1 e instalar\u00e1 en el entorno de producci\u00f3n que est\u00e1 listo para ser consumido por el usuario final. DevOps pone un gran \u00e9nfasis en la automatizaci\u00f3n y las herramientas de integraci\u00f3n continua que permiten la entrega de aplicaciones y servicios a alta velocidad.<\/p>\n El hecho de que las pruebas se realicen en cada etapa del modelo DevOps cambia el rol de los evaluadores y la idea general de las pruebas. Por lo tanto, para poder llevar a cabo actividades de prueba de manera efectiva, ahora se espera que los evaluadores tengan habilidades t\u00e9cnicas e incluso conocimientos de programaci\u00f3n, por eso ser\u00e1n los integrantes del equipo de desarrollo.<\/p>\n – \u00a0\u00a0\u00a0\u00a0\u00a0 Black box Testing<\/u><\/p>\n Este m\u00e9todo recibe su nombre, \u201ccaja negra\u201d, porque el ingeniero de control de calidad se enfoca en las entradas y las salidas esperadas sin saber c\u00f3mo funciona internamente la aplicaci\u00f3n (software). El prop\u00f3sito de este m\u00e9todo es verificar la funcionalidad del software asegur\u00e1ndose de que funcione correctamente y cumpla con las demandas del usuario. Este m\u00e9todo se puede aplicar a cualquier nivel de prueba, pero se usa principalmente para pruebas de aceptaci\u00f3n del sistema y del usuario, de las que hablamos en el art\u00edculo anterior.<\/p>\n A diferencia de las pruebas de caja negra, este m\u00e9todo requiere un conocimiento profundo del c\u00f3digo, ya que implica probar alguna parte estructural de la aplicaci\u00f3n. Por lo tanto, generalmente, los desarrolladores directamente involucrados en la escritura del c\u00f3digo son los responsables de este tipo de pruebas. El prop\u00f3sito de las pruebas de caja blanca es mejorar la seguridad, el flujo de entradas\/salidas a trav\u00e9s de la aplicaci\u00f3n y mejorar el dise\u00f1o y la usabilidad. Este m\u00e9todo se utiliza principalmente en los niveles de pruebas unitarias y de integraci\u00f3n.<\/p>\n Este m\u00e9todo es una combinaci\u00f3n de los dos anteriores, ya que implica probar tanto las partes funcionales como las estructurales de la aplicaci\u00f3n. Con este m\u00e9todo, un tester experimentado tiene un conocimiento parcial de la estructura interna de la aplicaci\u00f3n y, en base a este conocimiento, puede dise\u00f1ar casos de prueba mientras sigue probando desde la perspectiva de la caja negra. Este m\u00e9todo es principalmente aplicable al nivel de prueba de integraci\u00f3n.<\/p>\n Este es un m\u00e9todo de prueba informal ya que se realiza sin planificaci\u00f3n ni documentaci\u00f3n. Al realizar pruebas de manera informal y aleatoria sin ning\u00fan resultado esperado formal, el tester improvisa los pasos y los ejecuta arbitrariamente. Aunque los errores encontrados con este m\u00e9todo son m\u00e1s dif\u00edciles de reproducir dada la ausencia de casos de prueba, este enfoque ayuda a encontrar defectos importantes r\u00e1pidamente, algo que no se puede hacer con m\u00e9todos formales.<\/p>\n Para acelerar y mejorar la calidad de las pruebas de software y mejorar su calidad, es importante adoptar una automatizaci\u00f3n de pruebas.<\/p>\n La automatizaci\u00f3n de pruebas es fundamental, ya que alivia la carga de administrar todas las necesidades de las pruebas, lo que permite dedicar m\u00e1s tiempo y esfuerzo a la creaci\u00f3n de casos de prueba (test cases). La tendencia de automatizaci\u00f3n de pruebas est\u00e1 respaldada por la adopci\u00f3n cada vez mayor de metodolog\u00edas \u00e1giles, que promueven tanto la automatizaci\u00f3n de pruebas como las pr\u00e1cticas de integraci\u00f3n continua.<\/p>\n El proceso de automatizaci\u00f3n de pruebas normalmente se lleva a cabo en varios pasos consecutivos:<\/p>\n La automatizaci\u00f3n se puede aplicar a casi todos los tipos de pruebas, en todos los niveles. Como resultado, la automatizaci\u00f3n minimiza el esfuerzo humano requerido para ejecutar las pruebas de manera eficiente, reduce el tiempo de comercializaci\u00f3n y el costo de los errores porque las pruebas se realizan hasta 10 veces m\u00e1s r\u00e1pido en comparaci\u00f3n con el proceso de prueba manual.<\/p>\n La prueba de regresi\u00f3n es la pr\u00e1ctica de verificar el comportamiento del software despu\u00e9s de las actualizaciones para garantizar que los cambios no hayan afectado las funciones, la estabilidad y la integridad general del sistema existente. Las pruebas de regresi\u00f3n se pueden aplicar a todos los niveles y con todo tipo de procedimientos de prueba, pero la forma m\u00e1s com\u00fan es ejecutar pruebas de regresi\u00f3n seg\u00fan los casos de uso. El flujo de trabajo de control de calidad de regresi\u00f3n se puede automatizar para evitar pruebas manuales repetitivas despu\u00e9s de cada actualizaci\u00f3n. Existen m\u00faltiples t\u00e9cnicas de prueba de regresi\u00f3n:<\/p>\n CONCLUSI\u00d3N<\/strong><\/p>\n Espero que, con la explicaci\u00f3n de los conceptos en este art\u00edculo, se haya completado lo que se expon\u00eda en el art\u00edculo anterior<\/a>. He tratado de exponerlos de una manera simple y sin caer en ciertos debates siempre presentes en la sociedad de QA. La verdadera intenci\u00f3n de estos dos art\u00edculos, adem\u00e1s de acercar a los no iniciados a los procesos de QA, es tambi\u00e9n sentar las bases para formular lo que puede ser el QA en un futuro no muy lejano, que es de lo que se va a ocupar el tercer y \u00faltimo art\u00edculo. El futuro del software testing.<\/p>\n Espero haber acertado en la selecci\u00f3n de conceptos y que sigas con ganas de descubrir la tercera parte de este art\u00edculo: Atr\u00e9vete a conocer qu\u00e9 es QA (III): el futuro del Testing | ENCAMINA<\/a><\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" Si est\u00e1s leyendo este art\u00edculo, entiendo que vienes de leer la primera parte, donde os habl\u00e9 sobre los conceptos generales del software testing. Si no has le\u00eddo ese art\u00edculo,\u00a0te recomiendo encarecidamente que lo hagas, ya que algunas cosas de las … Continue reading
\nDej\u00e9 fuera del anterior art\u00edculo los conceptos de los que trato aqu\u00ed, por motivos de comodidad narrativa y porque no quer\u00eda sobrecargar el art\u00edculo de conceptos. Espero que encuentres en \u00e9ste la claridad necesaria para ver c\u00f3mo desmontamos Legos \u00a1Vamos a ello! \ud83d\ude42<\/p>\n1. \u00bfCu\u00e1l es el rol del Testing en el ciclo de desarrollo?<\/h1>\n
\n<\/strong>Cuando John Ford cre\u00f3 el modelo de producci\u00f3n en l\u00ednea, tambi\u00e9n cre\u00f3 el modelo de desarrollo en cascada (bueno, no fue as\u00ed exactamente, pero podr\u00eda haberlo sido perfectamente \ud83d\ude05). En realidad, fue Wiston W. Royce el primero que formul\u00f3 el t\u00e9rmino, haciendo hincapi\u00e9 en que las pruebas se deber\u00edan hacer una vez concluido el desarrollo del producto.<\/p>\n![\"\"](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2022\/04\/Foto-1.png\")
<\/a><\/p>\n![\"\"](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2022\/04\/Foto-2.png\")
<\/a><\/p>\n2. M\u00e9todos del software testing<\/h1>\n
\n
\n
\n
3. Automatizaci\u00f3n<\/h1>\n
\n
4. Regresi\u00f3n<\/h1>\n
\n