Servicios de Pruebas de Software QA
Beneficios de nuestras soluciones
Compilaciones automatizadas para entregas más rápidas
Trabajamos con herramientas DevOps para que nuestro equipo automatice la mayoría de las operaciones críticas, las que requieren mucho tiempo. También diseñamos conjuntamente flujos de CI y CD enfocados a mejorar la cobertura de las pruebas de unidad y regresión.
Transparencia completa con tus objetivos de QA
Con nosotros podrás alinear tus KPI de QA más importantes con los objetivos del proyecto. Así obtendrás siempre tiene el control, con acceso completo a los informes de control de calidad, que incluyen resultados de pruebas, cobertura de pruebas, tendencias de calidad, informes de cierre de sesión y más.
Cobertura de pruebas End-to-End
Una cobertura de pies a cabeza podrá mostrarte errores difíciles, está prueba te ayudará a detectar errores y defectuosidades difíciles de preveer. Para ello aplicamos toda clase de pruebas como funcional, GUI, de usabilidad, seguridad, de bases de datos, multiplataformas, accesibilidad, entre otras.
Expertos en pruebas para la calidad integral
Nuestro equipo de profesionales está totalmente capacitado para proveerte las mejores pruebas de software End to End, integrando metodologías ágiles para una colaboración continua entre pruebas y desarrollo. Te entregamos un plan de pruebas, también ayudaremos a que tus desarrolladores se centren en la calidad y logren enfocarse en sus actividades de valor
¿Quieres saber más? Lee algunas preguntas frecuentes
El desarrollo impulsado por las pruebas de aceptación (ATDD) tiene como objetivo ayudar a un equipo a desarrollar historias de usuarios en pruebas de aceptación, para cuando se ejecuten determinar si existe la funcionalidad deseada.
Acceptance Test-Driven Development (ATDD) aims to help a team develop user stories in acceptance tests, by the time they run to determine if the desired functionality exists.
Según aplique, los escenarios y cobertura de las pruebas es posible que se base en el Testing Agile:
Pruebas unitarias
•Por qué: para asegurar código se desarrolla correctamente
•Quienes: desarrolladores, arquitectos / técnicos
•Qué: todo nuevo código + re-factorización de código heredado, así como la unidad de pruebas Javascript
•Cuándo: tan pronto como se escriba el nuevo código
•Dónde: Dev + CI local
•Cómo: automatizado, Junit, TestNG, PHPUnit
Pruebas de API / servicio
•Por qué: para garantizar la comunicación entre los componentes que funcionan
•Quienes: desarrolladores, arquitectos / técnicos
•Qué: nuevos servicios web, componentes, controladores, entre otros.
•Cuándo: tan pronto como se desarrolle y esté listo el nuevo API
•Dónde: Dev + CI local
•Cómo: automatizado, interfaz de usuario SOAP, cliente REST
Prueba de Aceptación
•Por qué: para garantizar las expectativas del cliente se estén trabajando
•Quienes: desarrolladores, SDET / QA manual
•Qué: verificación de las pruebas de aceptación en las historias, características, entre otras.
•Cuándo: la función este lista y probada en la unidad
•Dónde: CI / entorno de prueba
•Cómo: prueba del sistema automatizado
Prueba del sistema automatizado (pepino) / Prueba de regresión / UAT
•Por qué: para garantizar que todo funcione cuando esté integrado
•Quienes: SDET / QA manual / Analista de Negocio / Dueño del Producto
•Qué: prueba de escenario, flujos de usuarios y típicos Customer Journey, pruebas de rendimiento y seguridad
•Cuándo: se complete la prueba de aceptacion
•Dónde: entorno de ensayo
•Cómo: pruebas exploratorias automatizadas (web driver)
As applicable, test scenarios and coverage may be based on Testing Agile:
Unit tests
•Why: To ensure code is developed correctly
•Who: developers, architects/technicians
•What: All new code + legacy code refactoring, as well as the Javascript test unit
•When: As soon as the new code is written
•Where: Dev + local CI
•How to: Automated, Junit, TestNG, PHPUnit
API/Service Testing
•Why: to ensure communication between working components
•Who: developers, architects/technicians
•What: New web services, components, drivers, among others.
•When: As soon as the new API is developed and ready
•Where: Dev + local CI
•How to: Automated, SOAP User Interface, REST Client
Acceptance Test
•Why: to ensure customer expectations are being worked on
•Who: developers, SDET/QA manual
•What: Verification of acceptance tests in stories, features, among others.
•When: The function is ready and tested on the unit
•Where: CI/test environment
•How to: Automated System Test
Automated System Test (Cucumber) / Regression Test / UAT
•Why: to ensure everything works when integrated
•Who: SDET / MANUAL QA / Business Analyst / Product Owner
•What: Scenario test, user flows and typical Customer Journey, performance and security tests
•When: Acceptance test completes
•Where: test environment
•How to: Automated Exploratory Testing (web driver)
Elegir la estrategia de pruebas correcta es como preguntarte con que clase de brocha pintarás una pared. No puedes usar el mismo para delinear las esquinas, ¿cierto? Si usas uno muy delgado quizás pases mucho tiempo pintandola; y si usas uno muy grande probablemente no te servirá para las areas pequeñas.
Por un lado, nos tomaría tiempo y no seria perfecto, o seria rápido y realmente luciría muy mal. Por ello hay diferentes pinceles para diferentes casos de uso y lo mismo se aplica a las pruebas.
Un plan de prueba es útil disciplinar el proceso de pruebas. Por lo que el mejor resultado que podemos obtener es cuando todo nuestro equipo está alineado de inicio a fin. De lo contrario, sin esa clase de guías seria un desastre cuando los miembros del equipo extraen conclusiones diferentes sobre el alcance, el riesgo y la priorización de las características del producto.
En Trycore trabajamos en un ambiente ágil donde llevamos a cabo sprints cortos; en ocasiones cada sprint se enfoca solo en algunas historias de usuario, por lo que es normal que la documentación no sea extensa pero si de calidad.Este plan de prueba de alto nivel hace las veces de guía para nuestros equipos afiles. Este documento enumera las mejores prácticas y estructura como podemos avanzar. Ágil no es sinónimo de desestructurado.
Queremos que los interesados lean este documento con los elementos más importantes como el alcance, qué probará; el objetivo del cliente; lo que no se probará; roles del equipo, cuántos QA, líderes, automatizadores, analistas, entre otros, y cual será su papel en el proyecto; qué metodología se usará; navegadores / SO / dispositivos para probar; tipos de pruebas, como seguridad, rendimiento, automatización, entre otras; pautas para la notificación de errores; herramientas a usar; riesgos; criterios de lanzamiento.
Choosing the right test strategy is like wondering what kind of brush you’ll paint a wall with. You can’t use the same one to outline the corners, can you? If you wear a very thin one you may spend a lot of time painting it; and if you use a very large one it probably won’t do you good for the small areas.
On the one hand, it would take us time and it wouldn’t be perfect, or it would be fast and it would really look really bad. That’s why there are different brushes for different use cases and the same applies to tests.
A test plan is useful to discipline the testing process. So the best result we can get is when our whole team is aligned from start to finish. Otherwise, without such guidance it would be a disaster when team members draw different conclusions about the scope, risk, and prioritization of product characteristics.
At Trycore we work in an agile environment where we perform short sprints; sometimes each sprint focuses only on some user stories, so it is normal that the documentation is not extensive but of quality. This high-level test plan makes the times a guide for our agile teams.
We want stakeholders to read this document with the most important elements such as scope, what will it try; the customer’s goal; what will not be proven; team roles, how many QA, leaders, automateds, analysts, among others, and what their role will be in the project; what methodology will be used; browsers/OS/devices to test; types of tests, such as security, performance, automation, and more; guidelines for reporting errors; tools to use; risks; launch criteria.
Automatizamos las pruebas para la repetibilidad. Lo que quiere decir que requerimos ejecutar las mismas pruebas una y otra vez. No automatizaríamos una prueba si solo la fuéramos a ejecutar una vez, pues el tiempo y el esfuerzo que implica automatizar la prueba, podría haberse ejecutado manualmente.
Implementar una solución robusta de pruebas de automatización no es tarea fácil y resulta un desafío para muchas empresas: nuestro equipo dinámico y altamente experimentado permite que entreguemos un servicio óptimo y de calidad en términos de automatización.
Diseñamos procesos de prueba estratégicos enfocados a entregar una cobertura confiable y de alto rendimiento: creamos marcos de automatización de control de calidad, configuramos scritps automáticos robustos y ejecutamos scripts de prueba automatizados.
-Utilizamos pruebas automatizadas porque:
-Las manuales toman mucho tiempo
-De manera manual es posible tener errores
-La automatización permite que las personas hagan mejor su trabajo
-Las pruebas tienen mayor cobertura
-La automatización permite tener comentarios
-Las pruebas de automatización brindan retroalimentación de forma rápida, lo cual permite ahorrar tiempo
-Brindan un ROI
We automate testing for repeatability. Which means we require running the same tests over and over again. We wouldn’t automate a test if we only were to run it once, because the time and effort involved in automating the test could have been run manually.
Implementing a robust automation testing solution is no easy task and is a challenge for many businesses: our dynamic and highly experienced team enables us to deliver optimal, quality service in terms of automation.
We design strategic testing processes focused on delivering reliable, high-performance coverage: we create quality control automation frameworks, set up robust automatic scripts, and run automated test scripts.
-We use automated testing because:
-Manuals take a long time
-Manually it is possible to have errors
-Automation allows people to do their jobs better
-Tests have greater coverage
-Automation allows you to have feedback
-Automation tests provide feedback quickly, saving time
-They provide an ROI
¿Tienes una idea sobre como aprovechar esta tecnología?
Contáctanos y nuestro equipo te ayudará a construir el mejor Caso de Negocio para evaluar el beneficio, el costo y el riesgo de implementarla.
