🔥 ¿Qué es el Smoke Test y Por Qué es tan Relevante? 🔥

Un "Smoke Test" es una prueba rápida para verificar que un software pueda iniciarse correctamente después de cambios importantes en el código, sin detectar fallos críticos.



💬 En otras palabras sirve para probar la "Funcionalidad Principal del Sistema"

🔥 ¿Cuando se Realiza? 🔥

💬 Despues de cada #Deploy

🔥 ¿Para qué sirve? 🔥

💬 Para revisar que siempre funcione el "Flujo Principal del Sistema"
💬 Para revisar si el Deploy fue Exitoso
💬 Para revisar si una Feature grande funciona correctamente

🔑 Claves para un Smoke Test efectivo 🔑

* Foco en lo esencial: Concéntrate en las funciones clave y la estabilidad básica del software.

 * Automatización: Automatizar el proceso del Smoke Test garantiza rapidez y consistencia en las pruebas.

 * Integración continua: Integra el Smoke Test en tu flujo de trabajo para una calidad constante en cada iteración.

Hola chicos, hoy les traigo un super resumen de preguntas para entrevistas o solo para que tengan agendadas (Interview Questions Overview)



Saludos

Si estas Empezando como QA y queres saber más de APi´s, aca te dejo un resúmen en orden para que te sea amigable y fácil de entender.




1 - El término API es una abreviatura de Application Programming Interfaces, (interfaz de programación de aplicaciones).

2 - La API se utiliza para permitir la comunicación entre dos aplicaciones a través de un conjunto de reglas.

3 - Sirve para poder facilitarle el trabajo a los desarrolladores y ahorrar tiempo y dinero.

4 - Las API se manejan con EndPoint (URLs de una API) y cada EndPoint puede tener varios métodos. Los métodos son todas las formas que tenemos de poder interactura con ese EndPoint.

Entre los métodos más comunes encontramos a los siguientes:

    POST: crear un recurso nuevo.
    PUT: modificar un recurso existente.
    GET: consultar información de un recurso.
    DELETE: eliminar un recurso determinado.
    PATCH: modificar solamente un atributo de un recurso.

5 - Las Herramientas que se utilizan para gestionar peticiones a las APIs pueden ser:

11 de Agosto del 2023

Hoy les traigo un post corto de algunas de la preguntas más comunes que se hacen al corregir un Bug (Error)



¿Cuáles son los detalles necesarios?
Si ve la mayoría de los errores registrados en un sistema, a menudo se escriben rápidamente con muy poca atención a los detalles, en la mayoría de los casos, probablemente con un título de una sola línea.

Esto puede generar mucha frustración para la persona que lo mira a continuación porque no conoce algunos de los detalles importantes y luego tiene que ponerse su sombrero de Sherlock Holmes y buscar respuestas y esto a menudo es mucho de ida y vuelta entre Desarrollo/Prueba/PM para averiguar el área donde está presente el problema

Algunas de las preguntas comunes que hace una persona cuando intenta corregir un error en una aplicación típica para consumidores/negocios para sistemas web/móviles/backend son en su mayoría del tipo.

Igual que verlo en clase.

Dejo marcado el error de Swagger, del metodo GET en (/pet/{petId}) que no responde por si lo intentan hacer y solo van a obener un resultado de "doggie", por mas que cambien el Id de la mascota

Si estas iniciando como QA acá te dejo un resumen de SQL y su sintaxis más usada, al final del Aporte te dejo varios links con paginas llena de tutoriales para que indagues más en este Lenguaje.


SQL es un lenguaje de programación diseñado para almacenar, manipular y recuperar datos almacenados en bases de datos relacionales. La primera vez que SQL apareció, fue en 1974, cuando un grupo de IBM desarrolló el primer prototipo de una base de datos relacional. Relational Software (luego se convirtió en Oracle) lanzó la primera base de datos relacional comercial.
Existen estándares para SQL, sin embargo, el SQL que puede utilizarse en cada uno de las principales RDBMS actuales viene en distintas formas. Esto se debe a dos razones:

•   El estándar SQL es bastante complejo, y no es práctico implementar el estándar completo.

•   Cada proveedor de base de datos necesita una forma de diferenciar su producto de otros.





A continuación muestro la sintaxis SQL para cada uno de los comandos SQL en esta guía de referencia:

Select
SELECT "nom de colonne" FROM "nombre_tabla";

Distinct
SELECT DISTINCT "nombre_columna"
FROM "nombre_tabla";

Where
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "condition";

And/Or
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "condición simple"
{[AND|OR] "condición simple"}+;

In
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" IN ('valor1', 'valor2', ...);

Between
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" BETWEEN 'valor1' AND 'valor2';

Like
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" LIKE {patrón};

Order By
SELECT "nombre_columna"
FROM "nombre_tabla"
[WHERE "condición"]
ORDER BY "nombre_columna" [ASC, DESC];

Count
SELECT COUNT("nombre_columna")
FROM "nombre_tabla";

Group By
SELECT "nombre_columna 1", SUM("nombre_columna 2")
FROM "nombre_tabla"
GROUP BY "nombre_columna 1";

Having
SELECT "nombre_columna 1", SUM("nombre_columna 2")
FROM "nombre_tabla"
GROUP BY "nombre_columna 1"
HAVING (condición de función aritmética);

Create Table
CREATE TABLE "nombre_tabla"
("columna 1" "tipo_de_datos_para_columna_1",
"columna 2" "tipo_de_datos_para_columna_2",
... );

Drop Table
DROP TABLE "nombre_tabla";

Truncate Table
TRUNCATE TABLE "nombre_tabla";

Insert Into
INSERT INTO "nombre_tabla" ("colonne 1", "colonne 2", ...)
VALUES ("valor 1", "valor 2", ...);

Update
UPDATE "nombre_tabla"
SET "colonne 1" = [nuevo valor]
WHERE "condición";

Delete From
DELETE FROM "nombre_tabla"
WHERE "condición";



Si te interesó y quieres ver más en detalle, podes hacerlo en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta, este sitio muestra una guía de referencia SQL enumera los comandos SQL normalmente utilizados, y se divide en las siguientes secciones:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Las instrucciones SQL básicas para almacenamiento, recuperación y manipulación de datos en una base de datos relacional.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Cómo se utilizan las instrucciones SQL para administrar las tablas dentro de una base de datos.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Comandos SQL avanzados.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta








Mr. Bones

Hola Hola comunidad, hoy vamos a ver una introduccion simpificada de las pruebas funcionales y su consideraciones ante un marco de trabajo Ágile (scrum o Kanban)

Enfoques de pruebas funcionales y consideraciones ágiles
La prueba de funcionalidad es el examen de la respuesta de un sistema codificado al uso esperado. Tenga en cuenta que no habla de apariencia cosmética, rendimiento, seguridad o cumplimiento de ningún tipo.



La prueba funcional es un proceso de verificación de que un sistema funciona como se espera cuando sus características son ejercidas por otro sistema o directamente por un usuario. Esto significa que se presta muy bien a las definiciones de casos de prueba y casos de uso que pueden proporcionar una base estable y repetible para evaluar el progreso del desarrollo del sistema.
Toda la gama del proceso de desarrollo está bajo el control de la verificación de la funcionalidad.

Las pruebas unitarias deben comenzar desde el principio para garantizar que cada bloque de código realice la manipulación prevista de las entradas en las salidas deseadas para el siguiente módulo.
Las pruebas de integración aseguran que los módulos de la unidad se conectan entre sí como se esperaba y transmiten datos y comandos a través del sistema según las especificaciones para las que fue construido.
Las comprobaciones de cordura verifican que las modificaciones y correcciones aplicadas al cuerpo del código no tengan efectos secundarios inesperados en, aparentemente, partes no relacionadas del sistema.
Las pruebas de regresión verifican que las adiciones de características posteriores y las correcciones de errores no deshagan los esfuerzos anteriores ni interactúen con ellos para causar problemas completamente nuevos.
La aceptación de la usabilidad es la operación real del sistema en el contexto en el que fue diseñado para ser utilizado y es la puerta de entrada a la implementación.
Todos los anteriores son variedades de pruebas funcionales y todos contribuyen a la creación de un sistema de software que está listo para implementarse para el uso previsto.

Enfoques de pruebas funcionales

Tres enfoques se utilizan comúnmente para implementar pruebas funcionales.

Pruebas de caja negra
La prueba de caja negra toma una serie de entradas y busca la generación de salidas específicas. La idea detrás del nombre es que el contenido del código bajo prueba es desconocido para el caso de prueba y, por definición, para el probador que solo se preocupa por la verificación de funciones.

Pruebas de caja blanca
Las pruebas de caja blanca están en el otro extremo del espectro. Se basan en saber exactamente qué está pasando con el código bajo prueba y las pruebas se ejecutan principalmente para verificar la solidez del código en lugar de su funcionalidad absoluta.
Las pruebas de caja blanca se realizan al comienzo del proceso de desarrollo con pruebas unitarias y en las primeras partes de la fase de integración. El trabajo de prueba de caja negra es típico de las últimas fases donde la respuesta a escenarios operativos específicos es importante.

Pruebas de caja gris
El tercer tipo de prueba es una mezcla de caja blanca y negra. Esto sucede a medida que el desarrollo avanza hacia una zona de cruce hacia el final de la integración y el comienzo de la usabilidad.

Obviamente, las pruebas de caja negra se prestan a casos de prueba estrechamente definidos y resultados de prueba rigurosamente definidos. Estas son pruebas que pueden realizar los técnicos de prueba que son capaces de seguir cuidadosamente las instrucciones del plan de prueba y documentar meticulosamente los resultados.

Las pruebas de caja blanca las realizan mejor los ingenieros de software que entienden cómo se escribe el código y las permutaciones de cómo se espera que funcione.




El paso del SDLC en cascada al desarrollo Agile y de allí a la Integración Continua y luego a Dev/Ops ha impulsado con fuerza el paradigma de la calidad del software. Con el cambio a Agile en particular, el tiempo de prueba se consideró un lujo y, por lo tanto, algo prescindible. El retroceso en esto ha sido brutal.

Las aplicaciones lanzadas sin suficientes pruebas fueron atacadas por las reseñas de los clientes en Internet que hace que las malas noticias viajen como un avión supersónico. Una consecuencia lógica de esta situación ha sido el impulso hacia la automatización de pruebas y tiene mucho sentido en los entornos de desarrollo de alta velocidad de la actualidad. Desafortunadamente, esto ha llevado a una expectativa infundada de que todas las pruebas deben automatizarse y que curarán todos los males del desarrollo.

Automatización de pruebas funcionales
La automatización de pruebas funciona mejor cuando hay una prueba que está bien definida y debe realizarse muchas veces o requiere una configuración de sistema avanzada muy compleja. Las pruebas que varían de una versión a otra, requieren la cognición humana (piense en la validación de la interfaz de usuario intuitiva) o necesitan una variación ad hoc, como en las pruebas exploratorias, no son buenas candidatas para la automatización. Los scripts de prueba escritos para pruebas inadecuadas incurrirán en costos de mantenimiento de scripts que resultarán en su abandono final debido a fallas debido a errores de diseño de prueba.

Documentación de prueba funcional
La documentación de prueba es oro. Por mucho que la presión por el desarrollo rápido y los intervalos de lanzamiento cortos empujen la calidad a tomar atajos, la documentación es demasiado valiosa para ignorarla. La automatización de pruebas, cuando corresponda, ayudará a documentar los procesos de prueba, al igual que la finalización cuidadosa de los informes de defectos que documentan las pruebas de regresión.

Y reconozca que se necesita una combinación de talentos en todo el desarrollo de software. Agile exige la integración de la calidad y el desarrollo con la gestión de productos. Utilice esta motivación para hacer que los equipos sean cada vez más granulares y sembrarlos con ingenieros de prueba. Poner la calidad y el desarrollo en asientos adyacentes poliniza las dos disciplinas en beneficio de ambas.






Me despido y cualquier cosa me escriben.




Mr Bones

Hola Underc0ders, hoy vamos a ver algunas preguntas que nos pueden hacer en las entrevistas sobre SQL

Las paso en Español y en Ingles para el que necesite practicar.





¿Cuál es la diferencia entre un "Stored Procedure" (Procedimiento almacenado) y una "Function" (Función)?

Un procedimiento puede tener parámetros de entrada y salida, pero una función solo puede tener parámetros de entrada.
Dentro de un procedimiento, podemos usar sentencias DML (INSERT/UPDATE/DELETE), pero dentro de una función no podemos usar sentencias DML.
No podemos utilizar un procedimiento almacenado en una declaración SELECT, pero sí podemos usar una función en una declaración SELECT.
Podemos usar un bloque Try-Catch en un procedimiento almacenado, pero no podemos usarlo en una función.
Podemos administrar transacciones en un procedimiento, pero no en una función.
No podemos unir procedimientos almacenados, pero sí podemos unir funciones.
Los procedimientos almacenados no se pueden utilizar en ninguna parte de las declaraciones SQL en las secciones WHERE/HAVING/SELECT, pero sí podemos usar una función en cualquier lugar.
Un procedimiento puede devolver 0 o n valores (máximo 1024), pero una función solo puede devolver 1 valor que es obligatorio.
No se puede llamar a un procedimiento desde una función, pero sí podemos llamar a una función desde un procedimiento.

¿Cuál es la diferencia entre un "Clustered Index" (Índice agrupado) y un "Non-Clustered Index" (Índice no agrupado)?

Un índice agrupado almacena físicamente los datos de la tabla en orden de los valores clave, y los datos se reorganizan cada vez que se inserta un nuevo valor o se actualiza un valor en la columna en la que está definido. Por otro lado, un índice no agrupado crea una lista separada de valores clave (o crea una tabla de punteros) que apunta a la ubicación de los datos en las páginas de datos.
Un índice agrupado no requiere un almacenamiento separado del almacenamiento de la tabla. Obliga a que las filas se almacenen ordenadas según la clave del índice, mientras que un índice no agrupado requiere un almacenamiento separado del almacenamiento de la tabla para almacenar la información del índice.
Una tabla con un índice agrupado se llama tabla agrupada. Sus filas se almacenan en una estructura de árbol B mientras que una tabla sin índices agrupados se llama tabla no agrupada y sus filas se almacenan en una estructura heap sin ordenar.
El índice predeterminado se crea como parte de la columna de clave primaria como un índice agrupado.
En un índice agrupado, el nodo hoja contiene los datos reales, mientras que en un índice no agrupado, el nodo hoja contiene el puntero a las filas de datos de la tabla.
Un índice agrupado siempre tiene un Id de índice de 1, mientras que los índices no agrupados tienen Ids de índice > 1.
Una tabla puede tener solo 1 índice agrupado, mientras que antes de SQL Server 2008 solo se podían crear 249 índices no agrupados. Con SQL Server 2008 y versiones posteriores, se pueden crear 999 índices no agrupados.
Una restricción de clave primaria crea un índice agrupado de forma predeterminada, mientras que una restricción de clave única crea un índice no agrupado de forma predeterminada.

¿Cuál es la diferencia entre los comandos "DELETE" y "TRUNCATE"?

El comando DELETE se utiliza para eliminar filas de una tabla basándose en una condición WHERE, mientras que TRUNCATE elimina todas las filas de una tabla.
Por lo tanto, podemos usar una cláusula WHERE con DELETE para filtrar y eliminar registros específicos, pero no podemos usar una cláusula WHERE con TRUNCATE.
DELETE se ejecuta utilizando un bloqueo de fila, es decir, cada fila en la tabla se bloquea para su eliminación, mientras que TRUNCATE se ejecuta utilizando un bloqueo de tabla, es decir, toda la tabla se bloquea para la eliminación de todos los registros.
DELETE es un comando DML (Lenguaje de Manipulación de Datos), mientras que TRUNCATE es un comando DDL (Lenguaje de Definición de Datos).
DELETE conserva la identidad del valor de la columna, mientras que en TRUNCATE, la columna de identidad se restablece a su valor inicial (seed) si la tabla contiene alguna columna de identidad.
Para usar DELETE se necesita permiso DELETE en la tabla, mientras que para usar TRUNCATE en una tabla se necesita al menos permiso ALTER en la tabla.
DELETE utiliza más espacio de transacción que la instrucción TRUNCATE, mientras que TRUNCATE utiliza menos espacio de transacción que DELETE.
DELETE se puede utilizar con vistas indexadas, mientras que TRUNCATE no se puede utilizar con vistas indexadas.
La declaración DELETE elimina filas una por una y registra una entrada en el registro de transacciones por cada fila eliminada, mientras que TRUNCATE TABLE elimina los datos desasignando las páginas de datos utilizadas para almacenar los datos de la tabla y registra solo las desasignaciones de páginas en el registro de transacciones.
DELETE activa un disparador (trigger) porque la operación se registra individualmente, mientras que TRUNCATE TABLE no puede activar un disparador porque la operación no registra eliminaciones individuales de filas.

¿Cuál es la diferencia entre la cláusula "WHERE" y la cláusula "HAVING"?

La cláusula WHERE se puede usar con las declaraciones SELECT, UPDATE y DELETE, pero la cláusula HAVING solo se puede usar con una declaración SELECT.
No podemos usar una función de agregado en la cláusula WHERE a menos que esté en una subconsulta contenida en una cláusula HAVING, mientras que sí podemos usar una función de agregado en la cláusula HAVING. Podemos usar el nombre de una columna en la cláusula HAVING, pero la columna debe estar contenida en la cláusula GROUP BY.
La cláusula WHERE se utiliza antes de la cláusula GROUP BY, mientras que una cláusula HAVING se utiliza para imponer una condición en la función GROUP y se utiliza después de la cláusula GROUP BY en la consulta.
Una cláusula WHERE se aplica a cada fila, mientras que una cláusula HAVING se aplica a filas resumidas (resumidas con GROUP BY).
En la cláusula WHERE, se recuperan los datos que coinciden con la condición desde la memoria, mientras que en HAVING, primero se recuperan todos los datos completos y luego se separan según la condición.

¿Cuál es la diferencia entre una "Primary Key" (Clave primaria) y una "Unique Key" (Clave única)?

Solo podemos tener una clave primaria en una tabla, mientras que podemos tener más de una clave única en una tabla.
La clave primaria no puede tener un valor NULL, mientras que una clave única puede tener solo un valor NULL.
De forma predeterminada, una clave primaria es un índice agrupado, mientras que de forma predeterminada, una clave única es un índice único no agrupado.
Una clave primaria admite un valor de incremento automático (Auto Increment), mientras que una clave única no admite un valor de incremento automático.

¿Cuál es la diferencia entre una "Local Temporary Table" (Tabla temporal local) y una "Global Temporary Table" (Tabla temporal global)?

Una tabla temporal local se crea al darle un prefijo de "#", mientras que una tabla temporal global se crea al darle un prefijo de "##".
Una tabla temporal local no se puede compartir entre múltiples usuarios, mientras que una tabla temporal global puede compartirse entre múltiples usuarios.
Una tabla temporal local solo está disponible para la conexión de base de datos actual para el usuario actual y se borra cuando se cierra la conexión, mientras que una tabla temporal global está disponible para cualquier conexión una vez creada y se borra cuando se cierra la última conexión.

¿Qué son las claves super, primaria, candidata y foránea?

Una clave super es un conjunto de atributos de un esquema de relación en el que todos los atributos del esquema dependen funcionalmente. No pueden haber dos filas con el mismo valor de atributos de clave super.
Una clave candidata es una clave super minimal, es decir, no puede haber un subconjunto propio de los atributos de la clave candidata que sea una clave super.
Una clave primaria es una de las claves candidatas. Se selecciona una de las claves candidatas como la más importante y se convierte en la clave primaria. No puede haber más de una clave primaria en una tabla.
Una clave foránea es un campo (o una colección de campos) en una tabla que identifica de manera única una fila de otra tabla.

¿Cuál es la diferencia entre la clave primaria y las restricciones únicas?

La clave primaria no puede tener valores NULL, mientras que las restricciones únicas pueden tener valores NULL.
Solo puede haber una clave primaria en una tabla, pero puede haber múltiples restricciones únicas.

¿Qué es la normalización de bases de datos?

La normalización de bases de datos es un proceso para analizar los esquemas de relación dados en función de sus dependencias funcionales y claves primarias para lograr las siguientes propiedades deseables:
Minimizar la redundancia.
Minimizar las anomalías de inserción, eliminación y actualización.
Los esquemas de relaciones que no cumplen con estas propiedades se descomponen en esquemas de relaciones más pequeños que puedan cumplir con las propiedades deseables.

¿Qué es SQL?

SQL (Structured Query Language) es un lenguaje de programación diseñado para insertar y modificar datos en un sistema de gestión de bases de datos relacionales (RDBMS).

¿Cuáles son las diferencias entre DDL, DML y DCL en SQL?

DDL (Data Definition Language) corresponde a las consultas que definen la estructura de una base de datos, como CREATE, ALTER, DROP y RENAME.
DML (Data Manipulation Language) corresponde a las consultas que manipulan los datos en la base de datos, como SELECT, INSERT y UPDATE.
DCL (Data Control Language) corresponde a las consultas que controlan los permisos de acceso y la seguridad de la base de datos, como GRANT y REVOKE.

¿Cuál es la diferencia entre la cláusula HAVING y la cláusula WHERE?

HAVING se utiliza para especificar una condición para un grupo o una función de agregado utilizada en una instrucción SELECT. WHERE se utiliza para seleccionar antes de agrupar.
La cláusula HAVING puede contener funciones de agregado, mientras que la cláusula WHERE no puede contener funciones de agregado. Se pueden usar columnas en la cláusula HAVING, pero esas columnas deben estar contenidas en la cláusula GROUP BY.
La cláusula WHERE se aplica a cada fila, mientras que la cláusula HAVING se aplica a filas resumidas (resumidas con GROUP BY).

¿Qué es una "Join" (Unión)?

Un Join en SQL se utiliza para combinar datos de dos o más tablas basándose en un campo común entre ellas. Por ejemplo, podemos unir dos tablas para mostrar los nombres de los estudiantes inscritos en diferentes cursos.

¿Qué es una "Identity" (Identidad)?

La "Identity" (Identidad) o "AutoNumber" es una columna que genera automáticamente valores numéricos. Se puede establecer un valor de inicio e incremento, pero la mayoría de los DBA (Administradores de bases de datos) los dejan en 1. Una columna GUID también genera números, pero el valor de esta no se puede controlar. Las columnas Identity/GUID no necesitan ser indexadas.

¿Qué es una vista en SQL? ¿Cómo se crea una?

Una vista es una tabla virtual basada en el conjunto de resultados de una instrucción SQL. Podemos crear una vista utilizando la sintaxis CREATE VIEW.
Ejemplo:

sql
Copy code
CREATE VIEW nombre_vista AS
SELECT nombre_columnas
FROM nombre_tabla
WHERE condicion;

¿Cuáles son los usos de las vistas?

Las vistas pueden representar un subconjunto de los datos contenidos en una tabla, lo que permite limitar el grado de exposición de las tablas subyacentes al mundo exterior: un usuario dado puede tener permiso para consultar la vista, pero se le deniega el acceso al resto de la tabla base.
Las vistas pueden combinar y simplificar múltiples tablas en una sola tabla virtual.
Las vistas pueden actuar como tablas agregadas, donde el motor de la base de datos agrega datos (suma, promedio, etc.) y presenta los resultados calculados como parte de los datos.
Las vistas pueden ocultar la complejidad de los datos; por ejemplo, una vista podría aparecer como Sales2000 o Sales2001, particionando de manera transparente la tabla subyacente real.

¿Qué es un "Trigger" (Disparador)?

Un Trigger es un código que se asocia con operaciones de inserción, actualización o eliminación. El código se ejecuta automáticamente cada vez que se ejecuta la consulta asociada en una tabla. Los triggers pueden ser útiles para mantener la integridad en la base de datos.

¿Qué es un "Stored Procedure" (Procedimiento almacenado)?

Un Stored Procedure es como una función que contiene un conjunto de operaciones compiladas juntas. Contiene un conjunto de operaciones que se utilizan comúnmente en una aplicación para realizar algunas tareas comunes de la base de datos.

¿Cuál es la diferencia entre un Trigger y un Stored Procedure?

A diferencia de los Stored Procedures, los Triggers no se pueden llamar directamente. Solo pueden asociarse con consultas.

¿Qué es una "transacción"? ¿Cuáles son las propiedades ACID?

Una Transacción de base de datos es un conjunto de operaciones de base de datos que deben tratarse como un todo, lo que significa que todas las operaciones se ejecutan o ninguna se ejecuta.
Las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) son un conjunto de propiedades que garantizan que las transacciones de base de datos se procesen de manera confiable.







Mr. Bones

Hola Underc0ders, hoy traigo un tema resumido de los tipos de pruebas de interrupción que suelen estar tanto en páginas y dispositivos móviles


App o Páginas Web



Los "tests tipo crash" (también conocidos como pruebas de bloqueo o pruebas de choque) son un tipo de pruebas que se realizan para evaluar cómo responde una aplicación o software ante situaciones inesperadas o condiciones extremas que puedan llevar al bloqueo o cierre inesperado del programa.

El objetivo principal de estas pruebas es detectar y corregir posibles fallos graves o "crashes" que puedan surgir durante la ejecución de la aplicación. Estos fallos pueden deberse a diversos factores, como errores de programación, problemas de memoria, conflictos de recursos o situaciones imprevistas.

Algunos escenarios comunes que se prueban mediante tests tipo crash son:

Pruebas de excepciones: Se generan situaciones que pueden generar excepciones no controladas en el software, como divisiones por cero, acceso a memoria no válida, etc.

Pruebas de estrés: Se somete la aplicación a cargas extremas o condiciones de uso inusualmente intensas para verificar si puede manejar la presión y no bloquearse.

Pruebas de memoria: Se evalúa cómo se comporta el software ante situaciones de asignación excesiva de memoria o fugas de memoria.

Pruebas de interrupciones: Se simulan eventos externos, como llamadas telefónicas o mensajes, para ver cómo la aplicación responde y recupera su estado correctamente después de tales interrupciones.

Pruebas de rendimiento: Se evalúa el comportamiento del software bajo condiciones de baja conectividad o ancho de banda limitado.

Pruebas de condiciones extremas: Se llevan a cabo pruebas bajo situaciones poco comunes pero posibles, como un espacio de almacenamiento casi lleno o una batería baja.


Mobile


En cuanto a los test mobile, las pruebas crash, son un tipo de prueba que evalúa cómo una aplicación o sistema responde ante eventos externos que pueden interrumpir su funcionamiento normal. Estos eventos pueden ser llamadas telefónicas, notificaciones, mensajes entrantes, cambios de red, cambios en la conectividad, entre otros.
El objetivo principal de estas pruebas es verificar que la aplicación sea capaz de manejar adecuadamente estas interrupciones y recuperarse correctamente después de que el evento haya finalizado. Estos escenarios son críticos en dispositivos móviles, donde las aplicaciones pueden ser interrumpidas por diversas actividades externas mientras están en uso.

Algunos ejemplos resumidos de pruebas de interrupción incluyen:

Prueba de llamadas telefónicas: Se verifica cómo la aplicación maneja una llamada telefónica entrante o saliente mientras se encuentra en uso, y si puede recuperar correctamente su estado después de finalizar la llamada.

Prueba de mensajes entrantes: Se evalúa cómo la aplicación reacciona cuando se recibe un mensaje o notificación mientras está en funcionamiento, y si puede recuperar su estado sin problemas después de revisar el mensaje.

Prueba de cambio de red: Se comprueba cómo la aplicación responde si se cambia el tipo de red (por ejemplo, de Wi-Fi a datos móviles) mientras está en uso.

Prueba de pérdida de conectividad: Se verifica cómo la aplicación maneja la pérdida temporal de conectividad a Internet o de la señal de red y cómo se recupera cuando la conexión se restablece.

Prueba de suspensión y recuperación: Se evalúa cómo la aplicación responde cuando el dispositivo entra en estado de suspensión (pantalla apagada) y cómo se recupera una vez que el dispositivo se vuelve a activar.



Si te interesó este tipo de interrupciones, podes ver mas información en el post que te dejo el enlace:



Saludos




  Mr. Bones

En este aporte, traigo una versión extendidas de todos los test posibles que encontre para móviles, dame like si te gustó y tus comentarios para seguir aprendiendo con esta comunidad.


En el anterior post se había hablado de que los test de interrupción son un tipo de prueba que evalúa cómo una aplicación o sistema responde ante eventos externos que pueden interrumpir su funcionamiento normal.
Y que las pruebas para verificar que la aplicación sea capaz de manejar adecuadamente estas interrupciones y recuperarse correctamente después de que el evento haya finalizado
En este posteo vamos a ampliarlas para que conozcas más del tema:



Las pruebas de interrupción de llamadas telefónicas se centran en verificar cómo una aplicación móvil responde y se recupera ante eventos relacionados con llamadas telefónicas entrantes o salientes mientras la aplicación está en uso. Estas pruebas son esenciales para garantizar que la aplicación pueda manejar adecuadamente las interrupciones de las llamadas y que el usuario no experimente problemas o pérdida de datos cuando reciba o realice una llamada mientras utiliza la aplicación.

Los aspectos que se evalúan en estas pruebas incluyen:

Recepción de llamadas entrantes: Se verifica si la aplicación puede detectar correctamente una llamada entrante y cómo maneja esta interrupción. La aplicación debe pausar o suspender sus actividades de manera adecuada para que el usuario pueda atender la llamada.

Respuesta a llamadas salientes: Se evalúa cómo la aplicación responde si el usuario inicia una llamada desde dentro de la aplicación. La aplicación debe ser capaz de realizar la llamada sin problemas y permitir al usuario retomar sus actividades después de finalizar la llamada.

Recuperación del estado: Es importante comprobar si la aplicación es capaz de recuperar su estado y volver a funcionar correctamente una vez que la llamada se haya completado o rechazado. La aplicación no debe presentar errores o pérdida de datos después de una interrupción por llamada.

Gestión de eventos de llamadas: Se verifica cómo la aplicación maneja eventos específicos relacionados con las llamadas, como la duración de la llamada, el estado de la llamada (conectada, en espera, finalizada), y si muestra información relevante al usuario durante la llamada.

Integración con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para gestionar las llamadas entrantes y salientes de manera apropiada.

Es esencial realizar estas pruebas en una variedad de escenarios, como con diferentes operadores de telefonía móvil, condiciones de señal débil o fuerte, y en diferentes modelos de dispositivos para garantizar la compatibilidad y el rendimiento óptimo en diversas situaciones del mundo real.


Las pruebas de mensajes entrantes se centran en verificar cómo una aplicación móvil responde ante la recepción de mensajes, notificaciones o eventos similares mientras está en uso. Estos mensajes pueden incluir SMS, mensajes de aplicaciones de mensajería instantánea, notificaciones push, correos electrónicos, entre otros.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda manejar adecuadamente las interrupciones causadas por la llegada de mensajes, y que el usuario no experimente problemas o pérdida de datos cuando se recibe un mensaje mientras se utiliza la aplicación.
En estas pruebas incluyen:

Recepción de mensajes: Se verifica si la aplicación detecta correctamente la llegada de mensajes o notificaciones mientras está en uso y cómo maneja esta interrupción.

Respuesta a mensajes: Se evalúa cómo la aplicación reacciona si el usuario responde a un mensaje directamente desde la aplicación, como en aplicaciones de mensajería instantánea.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de recuperar su estado y volver a funcionar correctamente después de que se reciba un mensaje o notificación.

Visualización de mensajes: Se verifica cómo la aplicación muestra los mensajes entrantes al usuario, ya sea mediante notificaciones emergentes, bandejas de entrada u otros métodos.

Integración con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para recibir y procesar mensajes, y si se integra correctamente con las notificaciones del sistema.

Gestión de eventos de mensajes: Se verifica cómo la aplicación maneja eventos relacionados con los mensajes, como la eliminación de mensajes, la marca como leído, etc.

Es importante realizar estas pruebas en una variedad de escenarios y dispositivos móviles para garantizar que la aplicación pueda manejar diferentes tipos de mensajes y notificaciones sin afectar negativamente la funcionalidad y la experiencia del usuario.


Las pruebas de cambio de red se enfocan en verificar cómo una aplicación móvil responde cuando ocurren cambios en el tipo de red o conectividad mientras está en uso. Estos cambios de red pueden incluir la transición entre redes Wi-Fi y datos móviles (3G, 4G, 5G), o cambios en la intensidad de la señal.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda adaptarse sin problemas a diferentes tipos de red y condiciones de conectividad, para garantizar una experiencia de usuario óptima incluso cuando el dispositivo se mueve entre diferentes entornos de red.
En estas pruebas incluyen:

Transición de red: Se verifica cómo la aplicación maneja el cambio entre redes, como pasar de Wi-Fi a datos móviles o viceversa, y cómo afecta esto a las operaciones que esté realizando el usuario en ese momento.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de recuperar su estado y continuar funcionando correctamente después de un cambio de red, sin pérdida de datos o funcionalidad.

Estabilidad y rendimiento: Se evalúa cómo la aplicación responde a cambios en la intensidad de la señal o a conexiones de red débiles, y si sigue siendo estable y eficiente en su funcionamiento.

Integración con funciones del sistema operativo: Se verifica cómo la aplicación interactúa con el sistema operativo para adaptarse a los cambios de red y cómo se comunica con el sistema para obtener información sobre la conectividad.

Gestión de eventos de red: Se evalúa cómo la aplicación maneja eventos específicos relacionados con la conectividad, como la pérdida temporal de conexión o la restauración de la misma.

Es fundamental realizar estas pruebas en diferentes condiciones y ubicaciones para garantizar que la aplicación pueda ajustarse correctamente a los cambios de red y que el usuario no experimente problemas de conexión o rendimiento al utilizar la aplicación en diferentes entornos.



Las pruebas de pérdida de conectividad, también conocidas como pruebas de desconexión, se centran en verificar cómo una aplicación móvil responde cuando se pierde temporalmente la conectividad a Internet o cuando la señal de red es débil o inestable. Estas pruebas son importantes para evaluar cómo la aplicación maneja situaciones donde no hay acceso a Internet o la conexión es intermitente, lo que puede ocurrir debido a áreas con mala cobertura o problemas en la red.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda funcionar adecuadamente en condiciones de baja o nula conectividad y que el usuario no experimente problemas graves o pérdida de datos debido a la falta de conexión.
En estas pruebas incluyen:

Comportamiento en modo desconectado: Se verifica cómo la aplicación se comporta cuando la conectividad a Internet está ausente, si proporciona mensajes claros al usuario y si es capaz de realizar ciertas funciones en modo sin conexión.

Gestión de datos sin conexión: Se evalúa cómo la aplicación almacena y maneja datos localmente cuando no hay conexión a Internet y cómo sincroniza estos datos cuando la conexión se restaura.

Visualización de información: Se verifica si la aplicación muestra de manera adecuada la información disponible en modo sin conexión y si evita que el usuario realice acciones que requieran conexión.

Recuperación de la conexión: Es esencial comprobar si la aplicación puede detectar automáticamente la restauración de la conexión y si puede reanudar sus operaciones normalmente una vez que la conexión se reestablece.

Estabilidad y rendimiento: Se evalúa cómo la aplicación se comporta cuando la señal de red es débil o inestable, y si sigue siendo estable y eficiente en su funcionamiento.

Es fundamental realizar estas pruebas en diferentes ubicaciones y condiciones para garantizar que la aplicación pueda manejar adecuadamente la pérdida temporal de conectividad y proporcionar una experiencia de usuario consistente y confiable, incluso en áreas con problemas de conectividad.


Las pruebas de suspensión y recuperación, también conocidas como pruebas de estado en espera o pruebas de hibernación, se centran en verificar cómo una aplicación móvil responde cuando el dispositivo entra en un estado de suspensión o inactividad y cómo se recupera una vez que el dispositivo se vuelve a activar.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda manejar correctamente los cambios en el estado del dispositivo y que pueda recuperar su estado y continuar funcionando de manera adecuada cuando el dispositivo salga del estado de suspensión.
En estas pruebas incluyen:

Suspensión del dispositivo: Se verifica cómo la aplicación responde cuando el dispositivo entra en un estado de suspensión, donde la pantalla se apaga y la mayoría de las actividades se detienen.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de guardar su estado de manera adecuada antes de la suspensión y si puede recuperar ese estado correctamente después de la reactivación.

Comportamiento en segundo plano: Se evalúa cómo la aplicación se comporta cuando se encuentra en segundo plano durante la suspensión y cómo responde cuando vuelve a estar en primer plano después de la reactivación.

Proceso de inicio y carga: Se verifica cómo la aplicación se inicia y carga después de salir del estado de suspensión, y si lo hace de manera rápida y eficiente.

Compatibilidad con diferentes sistemas operativos: Se asegura que la aplicación maneje la suspensión y recuperación correctamente en diferentes versiones del sistema operativo móvil.

Pruebas de interacción con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para manejar eventos de suspensión y reactivación.

Es fundamental realizar estas pruebas en diferentes dispositivos y sistemas operativos para garantizar que la aplicación pueda manejar adecuadamente la suspensión y recuperación, y que ofrezca una experiencia de usuario fluida y sin problemas cuando el dispositivo entra y sale del estado de suspensión.



Las pruebas de interrupciones para aplicaciones móviles se enfocan en verificar cómo el software responde a situaciones inesperadas. Estas pruebas incluyen verificar cómo se manejan las llamadas telefónicas entrantes y salientes, cómo se reacciona ante mensajes y notificaciones, cómo se adapta a cambios de red y cómo se comporta al entrar y salir del estado de suspensión. El objetivo es garantizar que la aplicación sea robusta y brinde una experiencia fluida al usuario, sin errores ni pérdida de datos, incluso ante interrupciones externas.




  Mr. Bones

Hola comunidad, hoy les comparto algunas preguntas y respuestas para una entrevista de pruebas movile.

A medida que la tecnología mundial se vuelve cada vez más móvil, las pruebas de aplicaciones y sitios web diseñados para varios dispositivos móviles se vuelven cada vez más demandadas. Si va a realizar una entrevista para un proyecto móvil, no se deje sorprender por todos los nuevos desarrollos. En su lugar, actualice y estructure su conocimiento revisando esta lista de preguntas y respuestas comunes de la entrevista de prueba móvil, ¡y prepárese para participar!



1. ¿Cuál es la principal diferencia entre las pruebas móviles y web?
Las pruebas web requieren acceder al sitio a través de un navegador de Internet. Las pruebas móviles pueden significar pruebas web móviles (que son pruebas de aplicaciones web en navegadores en dispositivos móviles) o pruebas de aplicaciones móviles (lo que implica ejecutar una aplicación dedicada instalada en un dispositivo).

2. ¿Cuáles son los tipos de aplicación móvil?
Las aplicaciones móviles pertenecen a uno de tres tipos:
•   Aplicación web
•   Aplicación nativa
•   Aplicación Híbrida

3. ¿Puede nombrar las versiones más recientes de iOS y Android?
Su respuesta debe ser la versión más reciente, así que revísela antes de su entrevista si no está seguro.

4. ¿Cuáles son los desafíos más importantes en las pruebas de aplicaciones móviles?
Las aplicaciones móviles deben ser capaces de:
•   se ejecuta en una variedad de dispositivos, plataformas y tamaños de pantalla con diferentes versiones del sistema operativo
•   trabajar en diferentes tipos de redes (2G/Edge, 3G, 4G, Wifi, etc.)
•   lidiar con la duración de la batería y el consumo de energía;
•   manejar interrupciones tales como llamadas entrantes o mensajes.
 
5. Enumere los enfoques para las pruebas móviles en diferentes dispositivos
•   Priorizar la lista de dispositivos/resoluciones compatibles y centrarse en los más importantes
•   Uso de emuladores, simuladores
•   Uso de servicios de prueba colaborativos
•   Uso de servicios de prueba de aplicaciones basados en la nube
•   Pruebas beta del mundo real

6. ¿Cuáles son las limitaciones del uso de emuladores como medio de prueba de aplicaciones móviles?
Aunque pueden replicar el trabajo del hardware, los emuladores no pueden garantizar que el resultado sea idéntico al de un dispositivo real.
Además, los emuladores no pueden recrear las siguientes condiciones.
•   Interrupciones o Crash (llamada entrante, SMS, etc.)
•   Diversas configuraciones/características de hardware y software específicas de un dispositivo/SO
•   Los colores, el brillo y el contraste genuinos de la pantalla en ambientes oscuros y claros
•   Interacciones con otros sistemas o componentes (que forman parte de las pruebas de interoperabilidad)

7. Nombre algunas herramientas populares de prueba de automatización móvil
Hay una serie de herramientas populares de automatización de pruebas móviles, y es común que le pregunten sobre aquellas con las que ha tenido experiencia.
Algunas de las herramientas más populares:
•   Appium (Android e iOS)
•   Selendroid (solo Android)
•   Robotium (solo Android)
•   MonkeyRunner (solo Android)


8. ¿Cuáles son los tipos de pruebas más importantes para las pruebas de aplicaciones móviles?
•   Instalación/Desinstalación
•   Compatibilidad
•   UI, UX, capacidad de respuesta
•   Actuación
•   Seguridad
•   Interrupción
•   internacionalización
•   Estabilidad
•   interoperabilidad
•   usabilidad

9. Describa cualquier error interesante que haya encontrado recientemente.
Describa cualquier error no trivial que requirió un esfuerzo adicional para localizar. Puede ser un error que requirió un análisis profundo para encontrar la causa raíz o algún problema de seguridad, defecto relacionado con la memoria o reproducido en una configuración específica de dispositivo/SO.

10. ¿Cómo probaría la capacidad de recuperación?
La capacidad de recuperación o las pruebas de recuperación verifican que la aplicación puede recuperarse después de un bloqueo o falla. Todos los datos importantes deben estar seguros, sin que se pierda nada durante tales bloqueos. Puede requerir mucho esfuerzo y recursos realizar pruebas de recuperación exhaustivas. Estos ejemplos comunes son bastante fáciles de realizar para reproducir:
•   la pérdida de red durante alguna acción crítica para una aplicación que requiere conexión a Internet
•   carga de batería baja, reinicio del dispositivo debido a la carga baja
•   interrupción repentina o cierre de la aplicación mientras los procesos o acciones críticos aún se están ejecutando en la aplicación

Hemos visto algunas de las preguntas más comunes relacionadas con las pruebas mobile. Si conoces mas puedes agregarlas en los comentarios. Todos los éxitos para esa entrevista!!!

Hola underc0ders, hoy expongo el tema de....el pensamiento de un QA???

¿Qué pensamiento se esconde detrás del QA eficaz y eficiente? ¿Y cuáles son los detalles de la mentalidad de prueba ágil? Investiguemos juntos.



Entre todos los factores involucrados en las buenas prácticas, la psicología de los test ocupa un lugar importante, ya que puede afectar la forma en que abordamos los test, sin que seamos conscientes de que estamos haciendo ciertas llamadas de valor. Por ejemplo, se ha observado que los desarrolladores son menos efectivos al probar su propio código (o incluso el de sus compañeros de equipo) como testers y futuros QA dedicados. Hay varias razones por las que esto puede suceder:

•   Es difícil encontrar defectos en algo creado por uno mismo.
•   Puede ser un desafío pensar en lo que podría salir mal cuando se concentra en lo que debería hacer el sistema.
•   En general, los desarrolladores tienden a tener una mente orientada a la solución, mientras que los evaluadores deben estar orientados a los problemas, es decir, buscar 'cómo romper' las cosas en lugar de 'cómo construirlas'.
•   Por lo general, los evaluadores no necesitan saber en profundidad cómo funciona el sistema que se está probando. En su lugar, deben ponerse el sombrero del usuario final y pensar en posibles escenarios desde el punto de vista del usuario. En estos términos, el conocimiento de los desarrolladores sobre la forma en que funciona el sistema puede evitar que vean escenarios alternativos que podrían causar algún comportamiento inesperado.



Esto significa que para ser un tester efectivo, debe concentrarse en las formas de romper el software. En cierto sentido, su intención debería ser probar que 'no funciona', pero ese enfoque por sí solo puede no ser todo lo que se necesita para el éxito.


Al mismo tiempo, necesita algunas habilidades especiales para poder comunicar los problemas que ha encontrado. Simplemente ser un 'chico malo' que rompe todo no es eficiente en una perspectiva a largo plazo. Recuerde que los desarrolladores están emocionalmente apegados a los resultados de su trabajo, por lo que es natural que puedan ser sensibles a sus bien intencionadas críticas.
Aquí es donde algunas de las habilidades explicadas en nuestra publicación sobre Comunicación Constructiva pueden ser útiles para usar. Los puntos principales se enumeran a continuación:

•   Hable de un problema, no de una persona;
•   Sea específico, no general;
•   Operar con hechos, no con juicios;
•   Enfócate en el futuro, no en el pasado.
•   Comunicar desde la posición del objetivo común.

Usar un tono constructivo y amigable es fácil y natural cuando te das cuenta del objetivo común por el que se esfuerzan los evaluadores y los desarrolladores. De hecho, la razón por la que los desarrolladores pueden sentirse heridos por las críticas a su código es que luchan por la calidad antes de llegar a la etapa de prueba, que es exactamente lo que tú también estás buscando. En un entorno amigable, los desarrolladores pueden sentirse agradecidos por la oportunidad de aprender sobre sus propios errores y por recibir sus comentarios. Respetarán a los testers y futuros QA que colaboran con ellos, lo que les ayudará a aprender a usar el sombrero de tester cuando sea necesario, ampliando su experiencia. Así nace un verdadero equipo.


El trabajo de un tester de software significa no solo encontrar errores, sino también prevenirlos. Eso incluye el análisis de requisitos, la optimización de procesos y la implementación de un enfoque de prueba continuo. En este sentido, la mentalidad de un tester significa preocuparse por la calidad durante todas las etapas del ciclo de vida del desarrollo del software. En el desarrollo ágil, la calidad es responsabilidad de todo el equipo, por lo que el enfoque principal de los test ágiles se desplaza hacia la iniciativa y el control de las actividades que previenen la ocurrencia de defectos.


Para ser un tester exitoso, debe ser crítico con el software, amable con los desarrolladores y tener una excelente comunicación. En otras palabras, un verdadero tester de software no solo sabe cómo descifrar el software, sino también cómo construir relaciones amistosas y productivas y elaborar el proceso que previene los defectos.


Saludos

Mr Bones

Siempre es importante tener documento para realizar los test, en caso de no tenerlo hay que crear los casos de aceptación junto con el cliente. Otra posibilidad es hacerlos con el PO y validarlos con el cliente para que no se generen errores de lógica.

Para el que quiere ver mas info, en el video de qarmy, dinno lo explica con creaciones de casos de pruebas (Test Case) -->

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Hola underc0ders, ahora les comparto las Pruebas de instalación en Pruebas de software

Prerrequisito: Pruebas de software

Prueba de instalación:


La prueba de los procedimientos para lograr un sistema de software instalado que se pueda utilizar se conoce como prueba de instalación. En esta instalación, se incluyen pruebas de verificación de actualizaciones completas o parciales y otras características, procesos de instalación/desinstalación. La prueba de instalación garantiza que la aplicación de software se haya instalado correctamente con todas sus características inherentes o no. También se denomina prueba de implementación, principalmente se realiza en la fase final.

¿Cuáles son las características de las pruebas de instalación?

Pruebas basadas en actividades
Ejecutado durante las pruebas de aceptación operativas
Realizado por ingenieros de pruebas de software junto con el administrador de configuración
Ayuda a ofrecer una experiencia de usuario óptima
Ayuda en la identificación y detección de errores durante la instalación
Las pruebas de instalación se ejecutan durante la última etapa de STLC
Hay desafíos que a veces afectan el proceso de prueba de instalación y muchas veces simplemente se vuelven caóticos.

Numerosas condiciones de validación
El producto debe probarse en diferentes configuraciones.
Como el proceso de instalación del software se valida por muchas razones, los requisitos también varían en las diferentes plataformas y, para reducir el consumo de tiempo, se utilizan los flujos de trabajo automatizados.



Trabajando en las pruebas de instalación:

La prueba de instalación se obtiene de los desarrolladores. El desarrollo de la empresa proporciona el acceso para instalar paquetes, así como el manual. Entonces, a partir de estas cosas, los probadores básicamente obtienen una idea de los componentes comprobables y no comprobables. Si hay alguna dificultad durante el proceso, se informa al equipo de desarrolladores. El principal objetivo de la condición es hacer el manual más fácil y simple para obtener el mejor resultado.

Los objetivos de las pruebas de instalación:

El objetivo principal es garantizar que no haya bloqueos que impidan que los usuarios finales utilicen el software y minimicen su eficiencia. El error y los errores son obtenidos por esto. Se asegura de que no se enfrente ningún problema con respecto a las diferentes plataformas.

Ayuda a verificar la distribución adecuada del siguiente software a la ubicación particular.

Tipos de tipos de asistencia:

Instalación silenciosa
instalación asistida
Instalación desatendida
Instalación de red
instalación limpia
Instalación automatizada

Ventajas de las pruebas de instalación:


La primera gran ventaja es que verifica los diseños de aplicaciones y software en un nivel básico de rendimiento de prueba.
Es una parte muy crucial de STLC que ayuda a mantener el estándar de acuerdo con eso.
Es un método muy rápido y práctico para comprobar la versión del software.
Los mejores resultados de salida de las pruebas de instalación ayudan al desarrollador a mejorar la aplicación o el software.

Contras de las pruebas de instalación:

A veces hay una falla causada por algunos factores externos, así como errores en el código, por lo que es un proceso lento y agotador.
El proceso de ejecución de casos de prueba requiere mucho tiempo, especialmente durante las pruebas de instalación.
El resultado o los resultados dependen completamente del caso de prueba impulsado.

Conclusión:

Las pruebas de instalación son uno de los aspectos críticos de las pruebas de software que se omiten y provocan un mal funcionamiento del software. En general, hay una gran cantidad de pruebas de instalación que a menudo conducen a varios desafíos. Una buena prueba de instalación no genera problemas y, por lo tanto, la instalación del software se lleva a cabo y la instalación sin problemas genera en los clientes la confianza para seguir usando el software.


Saludos y que sigas aprendiendo


Mr Bones

Verificación
¿Estamos construyendo el producto correctamente?

*Verificar los productos intermedios como documentos de requisitos, documentos de diseño, diagramas ER, plan de pruebas y matriz de trazabilidad.
*Punto de vista del desarrollador.
*Verificación sin ejecutar el código del software.
*Técnicas utilizadas: Revisión informal, Inspección, Recorrido, Revisión técnica y por pares.





Validación
¿Estamos construyendo el producto correctamente?

*Validar el producto final, como el software desarrollado, el servicio o el sistema.
*Punto de vista del cliente
*Validado mediante la ejecución del código del software.
*Técnicas utilizadas: Pruebas funcionales, pruebas del sistema, pruebas de humo, pruebas de regresión y muchas más.

----------------------------------------------------

In English

Verification
Are we building the product rigtht?

*Verify the intermediary products lik requirement documents, design documents, ER diagrams, test plan and traceability matrix.
*Developer point of view.
*Verified without executing the softarw code.
*Techniques used: informal Review, Inspection, Walkthrough, Technical and peer review


Validation
Are we building the product rigtht?

*Validate the Final end product like developed software or service or system.
*Customer point of view
*Validated by executing the software code.
*techniques used: Functional testing, System testing, Smoke testing, Regression testing and many more




Saludos

Mr. Bones

Comparto link de un examen ejemplo:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Por si quieren chequear antes de rendir.

Chicos felicito a todos los impicados al tema, al laburo realizado, la documentación y el repositorio, todo este trabajo lleva tiempo y se nota que lo han hecho con la mejor onda. A seguir creciendo y aprovechando lo que esta comunidad nos da, y a la gente que trabaja todos los dias que no se da a conocer pero estan anonimos en el tema.

Saludos y Gracias

ahí sale para empezar y hay indicaciones

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta