API:

Una API (Application programming interface o interfaz de programación de aplicaciones) es un conjunto de métodos y parámetros claramente definidos para permitir que diversos componentes se comuniquen entre sí de manera programática. Mediante una API es posible exponer la funcionalidad de un sistema para que terceras partes puedan acceder a ella independientemente del lenguaje de programación utilizado.

Caso de fallo:

Un caso de prueba en el que se fuerza a un escenario a los posibles fallos en lugar de los pasos usuales correctos.

Casos de prueba unitarios:

Una forma de comprobar el correcto funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o en diseño funcional una función o un procedimiento, en diseño orientado a objetos una clase. Esto sirve para asegurar que cada unidad funcione correctamente y eficientemente por separado. Además de verificar que el código hace lo que tiene que hacer, verificamos que sea correcto el nombre, los nombres y tipos de los parámetros, el tipo de lo que se devuelve, que si el estado inicial es válido, entonces el estado final es válido también.
https://es.wikipedia.org/wiki/Prueba_unitaria

Deuda técnica:

Se refiere exclusivamente a aquellos errores en la codificación que, pese a que no afectarán al funcionamiento de la misma, dificultan su mantenimiento, ampliación, despliegue o desarrollos posteriores, por ser código desarrollado con malas prácticas como la duplicidad o la ausencia de una correcta refactorización.
https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica

DevOps:

Un conjunto de prácticas para automatizar procesos que existen entre las actividades de desarrollo y las de operaciones con el fin de construir, probar, y entregar software de manera frecuente y continua. Se basa también en una cultura o paradigma de colaboración entre equipos que tradicionalmente funcionaban de manera aislada. Al igual que Agile o metodologías ágiles, sus prácticas y valores proponen gestionar la incertidumbre típica de la industria del conocimiento.

DevSecOps:

Prácticas DevOps a las cuáles se le suma la mirada y prácticas relacionadas a la seguridad por diseño.

Entregar valor:

En términos del paradigma Agile, un producto o una funcionalidad entregará valor cuando lo haga para sus usuarios.

IaaS:

Se entiende como Infraestructura como Servicio (Infrastructure as a service) la capacidad de proveer al consumidor procesamiento, almacenamiento, redes y otros recursos informáticos fundamentales donde el consumidor puede implementar y ejecutar software arbitrario, donde puede incluir sistemas operativos y aplicaciones. El consumidor no administra ni controla la infraestructura subyacente de la nube, pero tiene control sobre los sistemas operativos, el almacenamiento y otras aplicaciones implementadas; y posiblemente un control limitado de los componentes de red seleccionados (por ejemplo, firewalls host). Ejemplos: Amazon EC2, Windows Azure, Google Compute Engine u Openstack.

Integración continua:

La Integración Continua (Continuous Integration -CI-) es un conjunto de prácticas de desarrollo que orientan a los equipos a integrar el código fuente en un repositorio compartido de manera continua durante diferentes períodos del día. En cada integración el código es verificado de forma automática permitiendo a los equipos detectar preventivamente cualquier error disminuyendo el esfuerzo dedicado a la prevención y corrección de errores.

Priorización:

Determinar una escala de valoración de determinadas acciones en relación a uno o más tipos de actores, ya sean usuarios, interesados (stakeholders) u otros. Existen distintas maneras de priorizar. La más conocida es la Matriz de Eisenhower.

Programación por pares:

Técnica desarrollada por el XP programming en la que dos programadores participan en un esfuerzo combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no está haciendo actualmente. Por ejemplo, mientras que uno codifica las pruebas de unidades el otro piensa en la clase que satisfará la prueba.

Prueba de integración:

Prueba en la que unidades individuales son combinadas y probadas como un grupo. El propósito es exponer y detectar de los defectos posibles en la combinación entre las unidades integradas.

Pruebas de usabilidad:

Las pruebas de usabilidad consisten en seleccionar a un grupo de usuarios de una aplicación y solicitarles que lleven a cabo las tareas para las cuales fue diseñada, en tanto el equipo de diseño, desarrollo y otros involucrados toman nota de la interacción, particularmente de los errores y dificultades con las que se encuentren los usuarios. No es necesario que se trate de una aplicación completamente terminada, pudiendo tratarse de un prototipo.
https://es.wikipedia.org/wiki/Prueba_de_usabilidad

Prueba unitaria:

Un test o prueba unitaria puede definirse como un fragmento de programa escrito y mantenido por los desarrolladores de un determinado producto de software constituido por muestras del código fuente para las cuales se diseñan y ejecutan pruebas de esas pequeñas unidades de código. El resultado de las mismas pasará o fallará de acuerdo a la consistencia en la comparación entre el comportamiento esperado y el de la ejecución de la prueba.

Pruebas funcionales o e2e (end to end):

Estas pruebas están diseñadas para ser contrastadas con las especificaciones de requerimientos y que puedan ser validados. No evalúa el procesamiento sino sus resultados. Simula el funcionamiento usual sin tomar en cuenta ningún supuesto o resultado esperado. Cuando se conjugan varias pruebas funcionales como parte de un flujo o conjunto de requerimientos asociados las pruebas funcionales pasan a ser pruebas de punta a punta o end to end.

Refactorizar:

La refactorización es la parte del mantenimiento del código que no arregla errores ni añade funcionalidad. El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño y eliminar código muerto, para facilitar el mantenimiento en el futuro. Añadir nuevo comportamiento a un programa puede ser difícil con la estructura dada del programa, así que un desarrollador puede refactorizarlo primero para facilitar esta tarea y luego añadir el nuevo comportamiento.
https://es.wikipedia.org/wiki/Refactorizaci%C3%B3n:

REST:

En sentido amplio se trata de cualquier interfaz entre sistemas que utilice directamente HTTP para obtener datos o indicar la ejecución de operaciones sobre los datos, en cualquier formato (XML, JSON, etc) sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes, como por ejemplo SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto (RPC), pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST.
https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional:

SaaS:

Acrónimo para “Software como servicio”. Se trata de un modelo de distribución de software en el que el proveedor produce y alberga la aplicación y la disponibiliza a los usuarios a través de la Internet. hosts applications and makes them available to customers over the Internet.

Seguimiento de defectos (bug-tracking system):

Aplicación diseñada para ayudar a asegurar la calidad de software y asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software.
https://es.wikipedia.org/wiki/Sistema_de_seguimiento_de_errores

Test A/B:

Experimentos aleatorios con dos variantes, A y B, siendo una la de control y la otra la variante. Otra forma de referirse generalmente a los test A/B es con el término split test, aunque este último método se aplica cuando se realizan experimentos con más de dos variantes.
https://es.wikipedia.org/wiki/Test_A/B

Test-Driven-Development:

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.
https://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas

Tipos de usuario / personas:

Conocida como “test persona”, se trata de un personaje ficticio diseñado para representar a un usuario/a potencial de un sistema. Al identificar y considerar las necesidades, prejuicios, impedimentos, etc. de una persona pueden descubrirse escenarios y áreas de un problema que no se habían contemplado si no fuera por la construcción narrativa que involucra su desarrollo.

Versionado de código o control de versiones:

Se trata de una categoría de herramientas que sirven para que los equipos de desarrollo administren los cambios al código fuente a lo largo del tiempo a través del registro de todas las modificaciones realizadas al código en una base de datos diseñada para tales propósitos. Esto permite comparar y modificar diferentes versiones del código a través del tiempo.