Jul 24
Bueno, depende de la empresa…hay algunas empresas que aunque parezca mentira no tienen claro o no tienen definido apropiadamente cuales son las responsabilidades de un puesto como este (de gran responsabilidad, valga la redundancia). Como he dicho antes, todo depende de vuestra empresa aunque si que hay algunas responsabilidades que se debe considerar:
- Liderazgo.
- Gestión del Departamento de testing por tanto es importante que la persona tenga amplios conocimientos sobre testing.
- Asignar recursos a los proyectos.
- Revisar semanalmente los scorecards. (progreso del proyecto)
- Preparar las Work Orders en el caso que se trabaje con proveedores.
- Revisión de los SLA (Service Level Agreement) con los proveedores.
Read more
Ya está disponible el programa de 
uTest es la empresa ganadora del “7th Annual America Awards – The Stevies“. uTest es considerada una una de las empresas con mayores servicios de pruebas, ya que la compañía proporciona servicios de pruebas con una comunidad de +17.000 testers profesionales de 152 países de todo el mundo. Fundada en agosto del 2008, es una de las empresas pioneras del Crowdsourcing Software Testing. En menos de un año, la compañía ha adquirido más de 120 nuevos clientes y ha duplicado el número de empleados.
He encontrado una nueva revista sobre software testing llamada TEST. Una revista que empezó a publicarse hace muy poco tiempo y que pretende divulgar el testing por medio de casos de estudio, artículos de noticias, artículos de opinión, las mejores prácticas, estrategias y liderazgo.
En muchas empresas (en grandes multinacionales sobre todo) existen los “roles” de “Quality control” y “Quality Assurance“…profundicemos un poco más en cuáles son los roles y responsabilidades de uno y otro. El Quality Control realiza las actividades técnicas y operativas necesarias para cumplir con los requisitos de calidad…mientras que el Quality Assurance realiza todas las actividades planificadas dentro del sistema de calidad, y proporcionar la confianza necesaria en la organización en el cumplimiento de los estándares de calidad.
Recientemente, en una reunión, un compañero afirmaba rotundamente que un requerimiento no necesita ser analizado para ver si se puede testear, es decir, si es “testeable”. Afirmaba lo siguiente: “Si el cliente pide ese requisito, se puede y se debe testear…no es necesario analizar nada, lo quiere el cliente y punto”. Desde mi punto de vista era una afirmación un poco arriesgada. Esto me hizo pensar, ¿realmente sabemos que quiere decir que un requisito sea “testeable”? Un requerimiento testeable nos asegura que podremos ejecutar nuestras baterías de pruebas llegado el momento de ejecución. Probablemente para un analista de negocio (Business Analysis) no sea un asunto demasiado importante, pero para los equipos de testing si que es un factor crítico a considerar. En principio, todo requerimiento debe poder ser testeado, pero en la práctica la cosa es diferente. 
Un requisito no funcional (NFR) especifica los criterios que se deben usr para juzgar el funcionamiento de un sistema (operation of a system), en lugar de un comportamientos específico (specific behavior). En general, los requisitos funcionales definen lo que el sistema debería de hacer, mientras que los requisitos no funcionales verifican cómo un sistema debería de ser. Requisitos no funcionales son a menudo llamados las “cualidades de un sistema”. Puede dividirse en dos categorías:
El próximo 21 y 22 de octubre se celebra en Zurich (Suiza), la cuarta edición de la “Google Test Automation Conference” que concentra un año más a los mejores profesionales del sector en materia de “software testing and automation”. Este año, la organización propone los siguientes temas:
