Principios del testing moderno

Lean Thinking: es un sistema enfocado en la creación de valor para el cliente, a través de la persistente búsqueda y eliminación de desperdicio, así como también la mejora continua, el respeto hacia las personas, el trabajo en equipo y abordar desafíos.

Theory of Constraints: en una organización siempre habrán restricciones (maquinaria, procesos, políticas, personas…), en las cuales debemos enfocarnos y atacarlos de la sigueinte manera:

1. Identificar el cuello de botella
2. Explotarlo, llevándolo a su máxima capacidad.
3. Subordinar todo lo demás con el fin de solucionar el cuello de botella.
4. Elevar la capacidad con más maquinaria, personas, etc.
5. Iterar: siempre habrán más restricciones. Se debe evitar la inercia.

Curso de Appium y Selenium porfa

Apuntes:

Principios del testing moderno

Los principios creados por Allan Page y Brenn Jensen es acerca del testing moderno, que es la evolución natural del testing ágil. Veían la necesidad de que el tester y el desarrollador evolucionen en su perspectiva, ambos hacen software y entregan al mismo cliente, por lo tanto deben trabajar más como un equipo y no como entidades separadas. El tester debería enfocarse en la calidad del sowftware, el desarrollador debería enfocarse a desarrollar la solución. El tester va a ayudar al desarrollador a utilizar las mejores herramientas, a entender los procesos de pruebas, a mejorar la calidad de su desarrollo.

Los 7 principios del testing moderno

“Los testers podemos comenzar a pasar de ser los dueños de las pruebas o la calidad, a ser los embajadores de la calidad del producto”.

1. Nuesta prioridad es mejorar el negocio.
2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teoría de las Restricciones para ayudar a identificar, mitigar, priorizar y mitigar cuellos de botella en el sistema.
3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener éxito, en lugar de proporcionar una red de seguridad para detectar fallas.
4. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos al equipo para llevarlos a una cultura de calidad más madura.
5. Nosotros creemos que le cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto.
6. Nosotros usamos datos de manera extensa y profunda para entender los casos de usos del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.
7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

En donde estoy trabajando actualmente son muy abiertos a los cambios positivos, a las mejoras y a obtener mayor productividad, sin embargo hace falta quien tenga conocimientos y visión amplia para tener en cuenta todo el espectro que conlleva el desarrollo de nuestros productos, por lo que, al capacitarme con este tipo de cursos espero ser yo quien involucre en un futuro no muy lejano las mejores estrategias de análisis de calidad y productividad al desarrollo. ¡Me emociona aprender algo que sí voy a utilizar! 😃

“El cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto”. Pero cómo encaja lo que decía Steve Jobs sobre como él creaba sus productos?. Según él
"Algunas personas dicen: “Ofrezca a los clientes lo que quieren”. Pero ese no es mi enfoque. Nuestro trabajo es descubrir qué van a querer antes de hacerlo. Creo que Henry Ford dijo una vez: “Si hubiera preguntado a los clientes qué querían, me habrían dicho: ‘¡Un caballo más rápido!’”. La gente no sabe lo que quiere hasta que se lo enseñas. Es por eso que nunca confío en la investigación de mercado. Nuestra tarea es leer cosas que aún no están en la página."

Necesitariamos Cursos de pruebas de rendimiento usando JMeter como herramienta para mejorar la arquitectura de la aplicación.

Curso de Selenium por favor …

• la evolución del testing moderno es la evolución del testing ágil
  el tester y el desarrollador deben trabajar mas como un equipo

• el tester debe enfocarse en la calidad el producto
• el desarrollador enfocarse en desarrollar la aplicación
  los 7 principios del Testing moderno

1. nuestra prioridad mejorar el negocio
2. buscamos modelos Lean Thinking priorizar y mitigar cuellos de botella en el sistema (crear módulos de forma ágil)
3. para la mejora continua hay que adaptarse y optimizar
4. Nos preocupamos profundamente acerca de la cultura de calidad (el tester tiene que hacer recomendación de herramientas), la calidad es prioridad numero 1
5. Quien define la calidad es el usuario final (el cliente), el cliente es el único capaz de juzgar y evaluar
6. la falta de de datos de prueba, Nosotros usamos datos de manera extensa y profunda
7. Expandir las habilidades del testing a todo los compañeros, debemos entender y conocer toda la necesidad del producto

El tester debe enfocarse en la calidad
el desarrollador debe enfocarse en el desarrollo
pero deben de trabajar en conjunto para obtener un buen producto

7 Principios del testing moderno:

1. Nuestra prioridad es mejorar el negocio
2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teorías de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener éxito, en lugar de proporcionar una red de seguridad para detectar fallas.
4. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad más madura.
5. Nosotros creemos que el cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto.
6. Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.
7. Expandir las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

Todo el equipo son responsables de la calidad del producto.

Es bueno recalcar que el camino del tester es fundamental para las empresas, aunque hay muchas que no dependen de un tester por que consume recursos y que las pruebas las lleven a cabo el desarrollador, a simple vista del desarrollador no puede encontrar errores fácilmente para esto se necesita un especialista en calidad de software y es necesario llevar a cabo herramientas para realizar las pruebas mas efectivas como selenium java, que me gustaría que se dictara en esta plataforma platzi.

La teoría de las restricciones es una metodología que busca la mejora continua. identificando las restricciones o limitaciones encontradas en un sistema que lo hacen lento.

El método primero busca identificar las restricciones que son denominadas cuellos de botella. Luego se debe actuar sobre ellas para lograr la mejora. De manera que se pueda aumentar la capacidad del sistema o lograr que no se produzcan fallas.

La teoría de la restricción hace uso de diferentes herramientas para lograr un proceso de mejora continua. Utilizando la relación lógica de causa y efecto para entender como operan los procesos y encontrar la forma de mejorarlos.

Hi! I was a manual tester many years ago, this area has been improved so much. There are seven specialties: Manual Tester, Automation Tester, Security Tester, Data Science Tester, SDET (Software Development Engineer in Test), DevOps (Development and operations), QA Engineer, QE.
Actually, I want to learn more about it and get back soon to work.

a lo que le hace falta aplicar muchas normas de calidad, es a sitios donde atascan de publicidad, banners, etc, por ética, no deberían de subir esas páginas y quizá no deberían estar permitidas en la red comercial pública, o bajo propio riesgo del usuario, pero nisiquiera el proveedor del servidor debería de permitir que ahí se hospeden.

Si se siente mucho la separación entre desarrolladores y tester. Los defectos rara vez son bien recibidos y noto que siempre se busca un culpable… lo cuál reduce el tiempo de solución de dichos defectos.

1. Nuestra prioridad es mejorar el negocio
   El producto que se va a entregar al cliente es lo que permite funcionar al negocio. Si en algún momento no quieres hacerlo, estás poniendo en riesgo ese negocio porque si el producto no se vende o no es aceptado la empresa puede cerrar o puedes perder el trabajo.
   2. Nosotros aceleramos el equipo y usamos modelos como Lean Thinking y Teoría de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
   Cuando queremos hacer algo, lo queremos hacer perfecto y eso puede ser demasiado. Deberías construir en base a procesos cortos para poder encontrar los defectos de una manera más rápida.
   3. Nosotros somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener éxito, en lugar de proporcionar una red de seguridad para detectar fallas.
   El cliente puede entender que el producto se va a liberar por fases, es importante que nosotros enfoquemos nuestras pruebas en cada una de esas fases. No tiene que ser todo al inicio y al final, debe haber una distribución que nos permita manejar el riesgo del software
   4. Nos preocupamos profundamente acerca de la cultura de calidad en nuestro equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad más madura.
   Al inicio los testers eran personas desarrollando software y un día con tantos defectos y trabajo, separaron los roles y así hubiese una persona dedicada a realizar las pruebas. El tester puede hacer recomendaciones de herramientas, mejorar el proceso o volverse un coach.
   5. Nosotros creemos que el cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto
   Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.
   6. Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.
   7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

Es interesante y de gran responsabilidad comprender que el tester debe estar en todas las áreas del negocio, pensé que estaba limitado a las pruebas y algo de documentación.

Pronto entrare a una empresa como QA tester, este curso me esta ayudando a empaparme del tema antes de entrar a laborar.

Que es el modelo de Lean Thinking ?

Está demasiado cargada esa web. No permite agregar ni realizar nada. “Curso de Selenium porfa”

“El Tester pasa a tener una visión general de la empresa y además dominar temas técnicos asociados a cada una de las áreas: Desarrollo, diseño, documentación, análisis de requerimiento, documentación técnica que se entrega al final al usuario como guías de ayuda etc. El rol del Tester es: Acompañar en todo el proceso y la política la CALIDAD del producto”. Esto define la responsabilidad e importancia de los tester. Amando este curso!!!

la evolución del testing moderno es la evolución del testing ágil
el tester y el desarrollador deben trabajar mas como un equipo
el tester debe enfocarse en la calidad el producto
el desarrollador enfocarse en desarrollar la aplicación

Cada uno de estos principios son importantes para el buen funcionamiento de los procesos de desarrollo del software, además que cada uno de ellos contribuyen a la entrega de un producto de calidad y bien elaborado cumpliendo con los requerimientos dados por el cliente o el ProductOwner…!

En la teoría de las restricciones es importante tener en cuenta que es lo que hace que la empresa o el producto en nuestro caso, no funcione correctamente o que presente fallas en la calidad, para esto según la teoría, es importante :

1. identificar la restricción (Lo que no nos permite llegar a la meta)
2. explotar la restricción, es decir garantizar que la restricción siempre este en funcionamiento
3. subordinar todo a la restricción, se deben sincronizar los procesos al ritmo que trabaje la restricción
4. Elevar la restricción, aumentar la capacidad de las restricciones
5. Evaluar si hay una nueva restricción, suele ocurrir que al mejorar una restricción aparezca otra, por eso es necesario volver al paso 1

Todo esto con el fin de estar en el proceso de mejora continua

tambien de SonarQube

Por el minuto 7 dice que quien evalúa la calidad de nuestro producto es el usuario final, nuestro cliente.
Pero cliente y usuario final son distintos por ejemplo desde el UX.

Es mi imaginación o efectivamente son lo mismo?

• Nuestra prioridad es mejorar el negocio
  El producto que se va a entregar al cliente es lo que permite funcionar al negocio. Si en algún momento no quieres hacerlo, estás poniendo en riesgo ese negocio porque si el producto no se vende o no es aceptado la empresa puede cerrar o puedes perder el trabajo.

• Nosotros aceleramos el equipo y usamos modelos como Lean Thinking y Teoría de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
  Cuando queremos hacer algo, lo queremos hacer perfecto y eso puede ser demasiado. Deberías construir en base a procesos cortos para poder encontrar los defectos de una manera más rápida.

• Nosotros somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener éxito, en lugar de proporcionar una red de seguridad para detectar fallas.
  El cliente puede entender que el producto se va a liberar por fases, es importante que nosotros enfoquemos nuestras pruebas en cada una de esas fases. No tiene que ser todo al inicio y al final, debe haber una distribución que nos permita manejar el riesgo del software

• Nos preocupamos profundamente acerca de la cultura de calidad en nuestro equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad más madura.
  Al inicio los testers eran personas desarrollando software y un día con tantos defectos y trabajo, separaron los roles y así hubiese una persona dedicada a realizar las pruebas. El tester puede hacer recomendaciones de herramientas, mejorar el proceso o volverse un coach.

• Nosotros creemos que el cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto
  Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.

• Nosotros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.

• Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

El tester debe dominar varias areas necesita entender y tener toda la visión del producto y negocio. Saber sobre herramientas que optimicen el trabajo.

El principio que más me llamó la atención es el uso extenso y profundo de datos de prueba, yo he intentado hacer mockups de datos pero la verdad siempre me faltan opciones, uno tiende a hacer mockups con los valores más comunes y no recuerda incluir los casos extremos o poco comunes.

Yo creo que para que estos principios se apliquen tiene que ver con la cultura de la organización. Por ejemplo el principio que dice que “Los testers comparten estrategias y conocimiento relacionado al testing para que se dependa menos de un especialista”. Esto depende de todos, de la cultura, si es una cultura abierta entonces va a funcionar, si no, pues no

curso de appium por favor!!!

Yo no he trabajado tanto en la parte de desarrollo de Software comercial, pero si en la parte de software para la industria manufacturera, es decir, PLC y esas cosas. Y en efecto, nada de esto se hace. Las únicas pruebas que se hacen de manera exhaustiva es el funcionamiento de la parte física, más no de la parte de programación.

Muchos de estos principios casi todos, lo realizan donde trabajo actualmente, pero ahora entiendo mucho más el valor de cada uno y que podria llegar aportar a la empresa cliente y hasta yo como desarrollador.

El tester debe dominar varias áreas, necesita entender y tener toda la visión del producto y negocio. Saber sobre herramientas que optimicen el trabajo. Si el cliente esta satisfecho con lo entregado y cumple las expectativas entonces has alcanzado la calidad deseada.

El tester debería de enfocarse en la calidad del producto, del proceso.

El desarrollador debería enfocarse en desarrollar la aplicación.

Entonces el tester ayudará al desarrollador con las mejores herramientas de desarrollo.

Los testers podemos comenzar a pasar de ser los dueños de las pruebas o la calidad, a ser los embajadores de la calidad del producto.

1. Nuestra prioridad es mejorar el negocio.
2. Nosotros aceleramos al equipo, usamos modelos como Lean Thinking y Teoría de las Restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.
3. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener éxito, en lugar de proporcionar una red de seguridad para detectar fallas.
4. Nos preocupamos profundamente acerca de la historia de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad más madura.
5. Nosotros creemos que el cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto.
6. Nostros usamos datos de manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.
7. Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

Empecé a trabajar como Tester Manual este año y me gustaría aportar mas en mi equipo, no solo quiero dedicarme a encontrar bugs y mejoras, quiero involucrarme mas con el proyecto

1. Tests show the presence of defects
   It means that the tests can show that problems EXIST, but not that problems DO NOT EXIST.
   The main purpose of conducting a test is to detect defects. Working on the premise that every product contains defects of some kind, a test that reveals the errors is generally better than one that does not. All tests must therefore be designed to reveal as many errors as possible.
2. Thorough testing is impossible
   Comprehensive testing attempts to cover all possible combinations of data in the software, in order to ensure that no situation can arise after testing the software has been released. Except in very simple applications, the number of possible data combinations is too high, it is more effective and efficient for test engineers to focus on functionalities according to risks and priorities.
3. Early testing.
   A product (including documents, such as the product specification) can be tested as soon as it has been created. ISTQB recommends testing a product as soon as possible, correcting errors as quickly as possible. Studies have shown that bugs identified late in the development process generally cost more to resolve.
   For example: an error found in the specifications can be quite easy to fix. However, if that bug is carried over to software coding, once discovered the bug can be very costly and time consuming.
4. Grouping of Defects
   Studies suggest that problems in a piece of software tend to cluster around a limited set of modules or areas. Once these areas have been identified, efficient test administrators are able to focus testing on sensitive areas, while continuing to search for bugs in the remaining software modules. It reminds me of 80/20.
5. The “Pesticide” paradox
   Like overuse of a pesticide, a set of tests that are used repeatedly in the pesticide will decrease its effectiveness. Using a variety of tests and techniques you will expose a number of defects across the different areas of the product.
6. The test is context dependent
   The same tests should not apply across the board. Different software products have different requirements, functions, and purposes. A test designed to be performed on a website, for example, may be less effective when applied to an intranet application. A test designed for a credit card payment method can be unnecessarily rigorous if done in a discussion forum.
   In general, the greater the probability and impact of damage from failed software, the greater the investment in software testing.
7. The fallacy of absence of errors
   Stating that a test has not discovered any bugs is not the same as stating that the software is “bug free.” In order to ensure that proper software testing procedures are carried out in all situations, testers should assume that all software contains some (albeit disguised) bugs.

Principios del testing moderno:

1. Nuestra prioridad es mejorar el negocio.

• El hacer, ejecutar y actuar de manera resposable y encaminada a la consecusión de objetivos hara sustentable el negocio.

1. Nosotros aceleramos al equipo, usamos modelos como Lean thinking y teoria de las restricciones para ayudar a identificar, priorizar y mitigar cuellos de botella en el sistema.

• construir en base a procesos cortos que te permitan encontrar de una manera más rapida los defectos.
• creando modulos en vez de piezas grandes.
• facilitando la deteccion de errores de diseño.

1. Somos la fuerza para la mejora continua, ayudando al equipo a adaptarse y optimizar para tener exito, en lugar de proporcionar una red de seguridad para detectar fallas.

• adaptarse a la liberación de software por etapas para realizar la mejor validación del modulo en especifico.

7 - Expandimos las habilidades de testing y el conocimiento en todo el equipo; Entendemos que esto reduce o elimina la necesidad de un especialista dedicado al testing.

• El tester necesita expandir su conocimiento hacia el negocio.

5 - Nosotros creemos que el cliente es el único capaz de juzgar y evaluar la calidad de nuestro producto.
El cliente es quien decide si cumple o no cumple la calidad esperada.

1. Nos preocupamos profundamente acerca de la cultura de calidad en el equipo, y asesoramos, lideramos y nutrimos el equipo para llevarlos a una cultura de calidad más ardua.

• Pasar de ser solamente testers a desarrollar una cultura de calidad que sobrepase lo esperado.

La empresa donde laboró permite y da mucha importancia a todo lo relacionado con la calidad. A medida que te voy escuchando me he identificado mucho con lo que tu mencionas y fue precisamente todos esos temas que me motivaron a capacitarme o conocer más sobre todo el tema de las pruebas y sobre todo conocer y aplicar el mundo de las Pruebas Automáticas.

6 - Nosotros usamos datos de una manera extensa y profunda para entender los casos de uso del cliente y entonces cerrar huecos entre hipótesis del producto e impacto del negocio.

• Una falta de vision general e inclusive pensamiento lateral puede hacer que la cantidad de datos no sea la optima para realizar la prueba.

Tengo una duda.
Mintras buscaba en la web encontre 7 principios de Testing de acuerdo al libro de ISTQB. Estos son diferentes a los presentados en el curso.

Cuáles deberia de aprender?

1. Las pruebas muestran la presencia de defectos
   Significa que las pruebas pueden demostrar que EXISTEN problemas, pero no que los problemas NO EXISTEN.
   El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible.
2. Las pruebas exhaustivas son imposibles

Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.

1. Pruebas tempranas.
   Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.
   Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.

2. Agrupamiento de Defectos
   Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.

3. La paradoja del "Pesticida"
   Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.

4. La prueba es dependiente del contexto
   Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.
   En general, cuanto mayor es la probabilidad y el impacto de los daños causados ​​por el software fallado, mayor es la inversión en la realización de pruebas de software.

5. La falacia de ausencia de errores
   Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.

anteriormente tome un curso de testing en otra plataforma y mencionaban los mismos principios pero la manera en como los aborda la ingeniera Blanca es sumamente clara

testing modernos aun no hacemos ni el testing agil o normal.

Muy buena clase para poder implementarlo en mi trabajo.

Expandimos las habilidades de testing y el conocimiento en todo el equipo; entendemos que esto reduce o elimina la necesidad de una especialista dedicado al testing.

Esto no implicaria que hubiese menos trabajo para un tester en un futuro?

Veo que muchos de los principios se pueden aplicar en mi trabajo.
El ejemplo más claro es el del test de datos, se presentó una ocasión en que la longitud de caracteres no era suficiente para almacenar el nombre que se requería guardar.

En algunos lugares por “falta de presupuesto y tiempo”, no es posible aplicar todo los principios, dado que estamos limitados por las reglas o normas que exigen o aceptan las empresas.

Claramente si una empresa no permite que estos principios no se ejecuten apuntan a, minimo, dos cosas: la mediocridad y que el tester no pueda trabajar cómodo y por ende se vaya a otra empresa.
Son principios que de ser ejecutados correctamente lograremos avanzar como equipo y como organización en general.

estos principios los compartiré con mi equipo de trabajo son muy claros.

El tester es la voz del cliente y de las buenas prácticas. Lo que queremos darle al consumidor final y lo que agilice el trabajo en equipo es sobre lo que debemos trabajar.

Estos principios dejan claro que testing no solo es ejecutar sw y comprobar resultados, sino un proceso que nos ayuda a evaluar la calidad del sw y reducir riesgos de fallos en producción.

Yo trabaje en una empresa que instalaba infraestructura, y que tenia muchos clientes pero poco personal. Era imposible tratar de fomentar una cultura de calidad cuando siempre había mucho trabajo y había que estar aprendiendo constantemente sobre muchos temas (redes, servidores, netoworking) siendo 2 especialistas técnicos, pero cuando no había ninguna inversión en certificaciones o capacitaciones.

Me encanta ❤️

si no hay buenas practicas que incluyen hacer pruebas desde la perspectiva del desarrollo, el tester tiene que pasar no solamente encontrar defectos si no también
de hacer recomendaciones de herramientas mejorar el proceso volverte un couch,
las empresas que mejor logran una escalabilidad, tanto en el crecimiento de sus equipo, como mantienen la calidad de sus productos, ellos desde sus inicios desde sus políticas se establecen que la calidad es numero 1, en
facebook por ejemplo lo que hacen es tener en cada una de sus areas de trabajo conceptos y mejores practicas para
que no se les olvide como es hacer un buen producto, y entonces el tester paso
de ser alguien que tenia que conocer de cuestiones muy tecnicas, a tener una mejor visión de todo el producto de toda la empresa y ademas dominar temas técnicos asociados a cada una de las areas, no solo desarrollo, si no también diseño, documentación, análisis de requerimientos,
documentación técnica que se entrega al final al usuario, entonces el rol del
tester es acompañar en todo el proceso y la política, la calidad del producto

La segmentación de las pruebas es la etapa más determinante ya que es donde se pueden definir los diferentes elementos a probar.

La estrategia y herramientas en este punto, tienen muchísima relevancia, ya que se deben utilizar acorde a la segmentación de las diferentes pruebas.

Ya sea de forma global o de manera específica.

Con respecto al testing moderno, agradezco mucho el permitirnos conocer acerca de este, personalmente no conocía los principios y me parece que es un tema interesante, de hecho considero que actualmente se requiere con urgencia aplicarlos, puesto que muchas personas basan su trabajo en ejecutar pruebas, en diligenciar formularios con los resultados obtenidos, reportar bugs en herramientas o capturar evidencias, no existe una conciencia absoluta de la importancia que tiene el trabajo que realizamos
Muchas personas se convierten en tester por la necesidad de ganar dinero, se dedican a ejecutar casos, pero no proponen mejoras para el proceso. Existen empresas donde se exige que los tester se certifiquen, pero no les permiten participar en los procesos generando ideas y adquiriendo conocimiento que permita enriquecer su labor.
El testing moderno me atrevo a decir que es una mirada amplia a la evolución tecnología, donde el conocimiento se vuelve diverso, donde las habilidades van más allá de ejecutar pruebas funcionales manuales, está el interés por adquirir habilidades, explotar herramientas , metodologías y por supuesto compartir todo lo aprendido.

Los 7 principios del testing moderno engloban aquello que en ia industria tiene las funciones del aseguramiento de la calidad que tiene facultad en cada area o departamento y cuya finalidad es abonar que el producto cumpla con las expectativas del cliente

Los principios son elementales en las pruebas de calidad del software, hay que entender que DEV y QA , no deben trabajar separados sino siempre en pro del objetivo y de la mejora del negocio es lo primordial.

Si se logra implementar estos principios.

Me gustan estos principios, creo que los voy a implementar.

Varios de los principios los aplique, pero con el que más me identifique es el cuarto. Debido a la visiónn general que tenia de los productos, muchas veces hacia el papel de analista de negocio y me volvía juez y parte.

En el último párrafo Blanca, te falta una tilde y signos de puntuación.

Quiero hacer este curso como preámbulo para hacer el curso de pruebas con Jest e implementarlo en la aplicación de react native que desarrollo en la empresa para la que trabajo. Me gusta mucho el enfoque de expandirlo a la cultura empresarial.

Considero que es muy importante tener claridad de los procesos que se debe realizar como tester en una empresa, pero cuando se tiene que realizar tantas tareas a la vez se puede perder el foco de la calidad en el desarrollo, siempre y cuando se cuente con los recursos, se podría implementar en cualquier empresa.

Sin duda, ser tester conlleva una gran responsabilidad ya que por lo visto necesita conocimiento global de las áreas que involucra el desarrollo de un proyecto.

Yo encantado de implementarlo, pero es dificil lograrlo, cuanto nuestra mentalidad dominante es hacer siempre lo menos posible.

https://platzi.com/clases/1421-pruebas-software/15096-principios-del-testing-moderno/?time=84
esta parte es muy buena

Pienso que en México es complicado llevar acabo los 7 principios ya que estos principios van basados a un organigrama de proyecto en dónde hay especialistas en cada área, aquí en México generalmente la gente que desarolla o gestiona un proyecto tiene que encargarse de la parte de la calidad. Ya que muchas empresas buscan disminuír costos de RECURSOS HUMANOS teniendo un recurso que sepa de varias cosas. Aun que si se pueden tomar estos principios como algo utópico y un estándar al que deberíamos de llegar como País. Es por eso que si no hay alguien especializado en testing es importante que todo el equipo este involucrado para hacer el mejor trabajo posible.

Sería muy bueno que se especificaran las pruebas a nivel de entregables que se tienen que hacer en cada etapa del desarollo ya que no he visto que ustedes compartan un recursro para ello. Espero en futuras clases lo haya, ya que a final de cuenta la calidad se puede estandarizar en un proceso adaptable para diferentes proyectos.

El tester juega en muchas formas un rol de facilitador para alcanzar la mejora continua.

El tester es más importante de lo que se cree

El tester representa un herramienta fundamental al momento de desarrollar un software, verificando que el programa tenga un numero muy bajo de errores.

Este tema es muy interesante e importante, rescato los siguientes puntos

• Lo importante es el negocio (cliente), define prioridades, alcance y calidad deseada
• Hay que tener una distribución que permita manejar el riesgo del software
• Se debe de contar con una extensa cantidad de datos de prueba

Esta sesión me golpea como teste xd Tengo conocimiento en casos de prueba y automatización, me falta un largo y difícil camino para llegar a ser un líder y un tutor que influya en la calidad de todas las etapas…

En realidad tengo experiencia en el mundo de pruebas y lo que más agradecen los clientes y los contratistas es que uno siga todo los principios explicados en el presente video.

Excelente Explicacion.

Como usuario de un taller de colision al manejar diferentes plataformas de compañías de seguros no esta bien que cuando se cargan los repuestos este proceso requiera demasiado tiempo ya que los nombres de las piezas varian de acuerdo a cada plataforma y si el repuesto es buscado como esta el catalogo del vehiculo en muchas ocasiones no se encuentra por que cada aseguradora maneja un nombre diferente.

muy buen tema el de principios del testing moderno, actualmente en la empresa donde estoy son muy abiertos los PO,lideres tecnicos y en general todo el equipo de desarrollo a las mejoras que se encuentran desde el equipo QA en las pruebas que se realizan sobre los entregables

El testing moderno vino revolucionar la calidad de software debido a que al llevar a cabo pruebas en cada fase del proceso la carga de trabajo y el tema económico mejora

Lean thinking: está enfocado en la creación de valor para el cliente que permite mejorar el proceso con menos costo, tiempo y de alta calidad

Yo utilizo las buenas practicas de Damn Vulnerable Web App (DVWA) al crear aplicaciones Web, es muy recomendable, ademas de que aprendes sobre seguridad informática.

yo aun me encuentro estudiando y en mi carrera esta la materia pruebas de software, lo curioso es que ya la lleve pero no recuerdo a ver visto en clase los 7 principios, así que agradezco esta información e investigare mas.

creo que cada uno de estos principios van muy de la mano con la metodología de trabajo Scrum, y la verdad en mi empresa los implementan, me parece super importante entender muy bien la necesidad del cliente y qué es en sí lo que se busca con la aplicación o desarrollo que se está haciendo, para saber que pruebas deben realizarse

Es muy importante los principios del tester me gustaria aportar todo este conocimiento en la empresa con la finalidad de entregar un buen producto y obtener la satisfacción del cliente .

Creo que el testing y el desarrollador deben estar constantemente comunicados para poder seguir un mismo hilo para poder finalizar de forma correcta el proyecto

El desarrollo y prueba de soft. involucra humanos. Por lo tanto la psicología tiene efectos importantes.

1.5.1 Psicología Humana y el Proceso de Prueba

La identificación de defectos en una prueba, como una revisión de requisitos, refinamiento de US o identificación de fallos durante la ejecución de una prueba dinámica, puede ser percibida como una CRÍTICA al producto y a su autor.

El sesgo de confirmación puede dificultar la aceptación de info q este en desacuerdo con las creencias actuales EJ; los dev, esperan q su código esté bien. tienen un sesgo de confirmación, q hace difícil aceptar q el código sea incorrecto.

Otros sesgos cognitivos pueden dificultar q las personas acepten la info producida por la P. Asimismo un rasgo humano es común culpar al portador de malas noticias. y la info de prueba a menudo tiene malas noticias

Por eso las personas perciben el proceso de pruebas como una actividad destructiva, a pesar de que contribuye al avance y calidad del producto

Para reducir estas percepciones, la info de fallos y D deber ser comunicada de manera constructiva. De esta manera se podrá reducir las tensiones entre testers, analistas, DEV, clientes y diseñadores. Esto aplica para Pruebas dinamicas y estaticas.

Los testers y jefes de P deben tener buenas competencias interpersonales para comunicar eficazmente los D, fallos ,avance , resultados de P y riesgos, y para construir relaciones positivas con sus compañeros de trabajo.

Formas de comunicarse de forma adecuada. Ejem:

• Comenzar una colaboración en lugar de batalla. recordar que el objetivo común es lograr S de mejor calidad
• Enfatizar los beneficios de la P. ej: los autores mejoran su trabajo y competencias. ahorra tiempo/dinero a la org.
• Comunicar el resultado de P. de manera neutral y centrada. sin criticar al dev. Redactar informes de defecto objetivos y fundamentados en hechos y revisar los hallazgos.
• Tratar de entender cómo se siente la otra persona y sus razones, en caso de reaccionar negativamente a la info.
• Confirmar que el interlocutor entendió lo que se dijo y viceversa.

Definir claramente el objetivo de P, tiene importantes implicaciones psicológicas. las personas tienden a alinear sus planes/comportamientos con los objetivos del equipo, dirección y otros implicados. los tester deben tener estos objetivos sin sesgo personal.

Estos 7 principios algunos en mi empresa se está llevando, otros no se llevan y otros hay que corregirlos.

Según mi experiencia, cada proyecto y cada empresa es distinta, todo depende de la cultura empresarial que se maneje, que desde arriba se controle y se diga vamos a hacer las pruebas, a veces se llega a el punto de escuchar decir a los programadores, si lo hacemos al 100% o lo hacemos al 50% igual nos van a llamar pidiendo cambios, estoy hablando de una empresa donde el usuario final es una persona que no tiene mucha idea de sistemas, y constantemente causa errores, se ve mucho en el ambito de software que usan en alcaldías, debido a que cambian constantemente los empleados y no escogen los mas idoneos para los cargos

Soy usuario de la pagina web de cierta inmobiliaria y veo los siguiente:

En ocasiones hay DEFECTOS: Al realizar las consultas del extracto o del cupón de pago de la administración, la opción no funciona correctamente tengo que reintentarlo varias veces, para mi esto seria un defecto porque no desempeña las función para las cual se desarrolló.

A veces me siento limitada, o me hacen creer que mis pruebas de datos son demasiadas alocadas y que la posibilidad no existe. Incluso que mis obsevaciones carecen de sentido. Ahora comprendo que no es asi, gracias.

El curso es nuevo para mi, me llama mucho la atención, los principios me parecen que encajan en cada una de las etapas para lograr el objetivo final, pensé que todo era color de rosas entre el Testing y el desarrollador, también que las pruebas que realiza el tester son mas profundas que las que puede hacer un desarrollador, con esto no quiero desmeritar al desarrollador, a demás puedo notar que el tester tiene que estar actualizándose a diario para conocer nuevas herramientas que ayuden al proceso tanto internamente como hacia el cliente.

Principio N°7: enseñar testing a todo el equipo y nos ahorramos el sueldo del especialista en testing.