diff --git a/docs_source_files/content/introduction/on_test_automation.es.md b/docs_source_files/content/introduction/on_test_automation.es.md index 01195de22812..6e9494f85fe1 100644 --- a/docs_source_files/content/introduction/on_test_automation.es.md +++ b/docs_source_files/content/introduction/on_test_automation.es.md @@ -1,434 +1,434 @@ --- -title: "On test automation" +title: "Sobre automatización de pruebas" weight: 2 --- -{{% notice info %}} - Page being translated from -English to Spanish. Do you speak Spanish? Help us to translate -it by sending us pull requests! -{{% /notice %}} - -First, start by asking yourself whether or not you really need to use a browser. -Odds are that, at some point, if you are working on a complex web application, -you will need to open a browser and actually test it. - -Functional end-user tests such as Selenium tests are expensive to run, however. -Furthermore, they typically require substantial infrastructure -to be in place to be run effectively. -It is a good rule to always ask yourself if what you want to test -can be done using more lightweight test approaches such as unit tests -or with a lower-level approach. - -Once you have made the determination that you are in the web browser testing business, -and you have your Selenium environment ready to begin writing tests, -you will generally perform some combination of three steps: - -* Set up the data -* Perform a discrete set of actions -* Evaluate the results - -You will want to keep these steps as short as possible; -one or two operations should be enough most of the time. -Browser automation has the reputation of being “flaky”, -but in reality, that is because users frequently demand too much of it. -In later chapters, we will return to techniques you can use -to mitigate apparent intermittent problems in tests, -in particular on how to [overcome race conditions]({{< ref "/webdriver/waits.es.md" >}}) -between the browser and WebDriver. - -By keeping your tests short -and using the web browser only when you have absolutely no alternative, -you can have many tests with minimal flake. - -A distinct advantage of Selenium tests -is their inherent ability to test all components of the application, -from backend to frontend, from a user's perspective. -So in other words, whilst functional tests may be expensive to run, -they also encompass large business-critical portions at one time. - - -### Testing requirements - -As mentioned before, Selenium tests can be expensive to run. -To what extent depends on the browser you are running the tests against, -but historically browsers' behaviour has varied so much that it has often -been a stated goal to cross-test against multiple browsers. - -Selenium allows you to run the same instructions against multiple browsers -on multiple operating systems, -but the enumeration of all the possible browsers, -their different versions, and the many operating systems they run on -will quickly become a non-trivial undertaking. - - -### Let’s start with an example - -Larry has written a web site which allows users to order their -custom unicorns. - -The general workflow (what we will call the “happy path”) is something -like this: - -* Create an account -* Configure the unicorn -* Add it to the shopping cart -* Check out and pay -* Give feedback about the unicorn - - -It would be tempting to write one grand Selenium script -to perform all these operations–many will try. -**Resist the temptation!** -Doing so will result in a test that -a) takes a long time, -b) will be subject to some common issues around page rendering timing issues, and -c) is such that if it fails, -it will not give you a concise, “glanceable” method for diagnosing what went wrong. - -The preferred strategy for testing this scenario would be -to break it down to a series of independent, speedy tests, -each of which has one “reason” to exist. - -Let us pretend you want to test the second step: -Configuring your unicorn. -It will perform the following actions: - -* Create an account -* Configure a unicorn - -Note that we are skipping the rest of these steps, -we will test the rest of the workflow in other small, discrete test cases -after we are done with this one. - -To start, you need to create an account. -Here you have some choices to make: - -* Do you want to use an existing account? -* Do you want to create a new account? -* Are there any special properties of such a user that need to be - taken into account before configuration begins? - -Regardless of how you answer this question, -the solution is to make it part of the "set up the data" portion of the test. -If Larry has exposed an API that enables you (or anyone) -to create and update user accounts, -be sure to use that to answer this question. -If possible, you want to launch the browser only after you have a user "in hand", -whose credentials you can just log in with. - -If each test for each workflow begins with the creation of a user account, -many seconds will be added to the execution of each test. -Calling an API and talking to a database are quick, -“headless” operations that don't require the expensive process of -opening a browser, navigating to the right pages, -clicking and waiting for the forms to be submitted, etc. - -Ideally, you can address this set-up phase in one line of code, -which will execute before any browser is launched: +Primero, pregúntate si realmente necesitas o no usar un navegador. Lo +más probable es que, en algún momento, si estás trabajando en una +aplicación web compleja, necesitarás abrir un navegador y realmente +probarlo. + +Sin embargo, las pruebas funcionales de usuario final, como las +pruebas de Selenium son caras de ejecutar. Además, normalmente +requieren que una infraestructura considerable este disponible para +estas ejecutarse de manera efectiva. Es una buena regla preguntarse siempre +si lo que se quiere probar se puede hacer usando enfoques de prueba +más livianos como las pruebas unitarias o con un enfoque de bajo +nivel. + +Una vez que hayas tomado la determinación de que estás en el negocio +de hacer pruebas en el navegador, y que tengas tu ambiente de +Selenium listo para empezar a escribir pruebas, generalmente +realizaras alguna combinación de estos tres pasos: + +* Preparar los datos +* Realizar un conjunto discreto de acciones +* Evaluar los resultados + +Querrás mantener estos pasos tan cortos como sea posible; una o dos +operaciones deberían ser suficientes la mayor parte del tiempo. La +automatización del navegador tiene la reputación de ser "frágil", +pero en realidad, esto se debe a que los usuarios suelen exigirle +demasiado. En capítulos posteriores, volveremos a las técnicas que +puedes utilizar para mitigar problemas aparentemente intermitentes en +las pruebas, en particular como +[superar race conditions]({{< ref "/webdriver/waits.es.md" >}}) entre el navegador y WebDriver. + +Manteniendo tus pruebas cortas y usando el navegador web solo cuando +no tienes absolutamente ninguna alternativa, +Puedes tener muchas pruebas con fragilidades muy mínimas. + +Una clara ventaja de las pruebas de Selenium es su capacidad +inherente para probar todos los componentes de la aplicación, desde +el backend hasta el frontend, desde la perspectiva del usuario. En +otras palabras, aunque las pruebas funcionales pueden ser caras de +ejecutar, también abarcan a la vez grandes porciones críticas para el +negocio. + + +### Requisitos de pruebas + +Como se mencionó anteriormente, las pruebas de Selenium pueden ser +costosas de ejecutar. Hasta qué punto, dependerá del navegador en el +que estás ejecutando las pruebas, pero históricamente el +comportamiento de los navegadores ha variado tanto que a menudo ha +sido un objetivo claro realizar pruebas cruzadas contra múltiples +navegadores. + +Selenium te permite ejecutar las mismas instrucciones en múltiples +navegadores en múltiples sistemas operativos, pero la enumeración de +todos los navegadores posibles, sus diferentes versiones y los muchos +sistemas operativos en los que se ejecutan se convertirá rápidamente +en una misión no trivial. + + +### Iniciemos con un ejemplo + +Larry ha escrito un sitio web que le permite a los usuarios ordenar +unicornios personalizados. + +El flujo de trabajo principal (que llamaremos el "camino feliz") es +algo como esto: + +* Crea una cuenta +* Configura el unicornio +* Agrégalo al carrito de compras +* Envialo a caja y realiza el pago +* Dar feedback sobre el unicornio + +Sería tentador escribir un gran script de Selenium para realizar +todas estas operaciones, muchos lo intentarán. **¡Resiste la +tentación!** Hacerlo dará como resultado una prueba que a) toma mucho +tiempo, b) estará sujeta a algunos problemas comunes relacionados con +los problemas de tiempo de representación de la página, y c) es tal +que si falla, no te dará un método conciso y "fácil de ver" para +diagnosticar lo que salió mal. + +La estrategia preferida para probar este escenario sería dividirlo en +una serie de pruebas rápidas e independientes, cada una de las cuales +tenga una "razón" para existir. + +Supongamos que deseas probar el segundo paso: Configurando tu +unicornio. Realizará las siguientes acciones: + +* Crea una cuenta +* Configura el unicornio + +Ten en cuenta que nos estamos saltando el resto de los pasos, +probaremos el resto del flujo en otros casos de prueba pequeños y +discretos, después de que hayamos terminado con este. + +Para comenzar, debes crear una cuenta. Aquí tienes que tomar algunas +decisiones: + +* ¿Quieres usar una cuenta existente? +* ¿Quieres crear una nueva cuenta? +* ¿Hay alguna propiedad especial de dicho usuario que deba ser +  tomado en cuenta antes de que comience la configuración? + +Independientemente de cómo respondas esta pregunta, la solución es +hacer que forme parte del paso de "preparar los datos" de la prueba. Si +Larry ha expuesto una API que te permite a ti (o cualquier persona) crear +y actualizar cuentas de usuario, asegúrate de usar eso para responder +esta pregunta. Si es posible, debes iniciar el navegador solo después +de tener un usuario "en la mano", cuyas credenciales pueden iniciar +sesión. + +Si cada prueba para cada flujo de trabajo comienza con la creación de +una cuenta de usuario, se agregarán muchos segundos a la ejecución de +cada prueba. Llamar a una API y hablar con una base de datos son +operaciones "sin cabeza" rápidas, que no requieren el costoso proceso +de abrir un navegador, navegar a las páginas correctas, hacer clic y +esperar que se envíen los formularios, etc. + +Idealmente, puedes abordar esta fase de configuración en una sola +línea de código, que se ejecutará antes de que se inicie cualquier +navegador: {{< code-tab >}} {{< code-panel language="java" >}} -// Create a user who has read-only permissions--they can configure a unicorn, -// but they do not have payment information set up, nor do they have -// administrative privileges. At the time the user is created, its email -// address and password are randomly generated--you don't even need to -// know them. -User user = UserFactory.createCommonUser(); //This method is defined elsewhere. - -// Log in as this user. -// Logging in on this site takes you to your personal "My Account" page, so the -// AccountPage object is returned by the loginAs method, allowing you to then -// perform actions from the AccountPage. +// Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +// pero no tienen configurada la información de pago, ni tienen +// privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +// la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +// conocerlos. +User user = UserFactory.createCommonUser(); //Este método se define en otro lugar. + +// Inicia sesión como este usuario. +// Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +// el método loginAs devuelve el objeto AccountPage, lo que le permite +// realizar acciones de AccountPage. AccountPage accountPage = loginAs(user.getEmail(), user.getPassword()); {{< / code-panel >}} {{< code-panel language="python" >}} -# Create a user who has read-only permissions--they can configure a unicorn, -# but they do not have payment information set up, nor do they have -# administrative privileges. At the time the user is created, its email -# address and password are randomly generated--you don't even need to -# know them. -user = user_factory.create_common_user() #This method is defined elsewhere. - -# Log in as this user. -# Logging in on this site takes you to your personal "My Account" page, so the -# AccountPage object is returned by the loginAs method, allowing you to then -# perform actions from the AccountPage. +# Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +# pero no tienen configurada la información de pago, ni tienen +# privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +# la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +# conocerlos. +user = user_factory.create_common_user() #Este método se define en otro lugar. + +# Inicia sesión como este usuario. +# Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +# el método loginAs devuelve el objeto AccountPage, lo que le permite +# realizar acciones de AccountPage account_page = login_as(user.get_email(), user.get_password()) {{< / code-panel >}} {{< code-panel language="csharp" >}} -// Create a user who has read-only permissions--they can configure a unicorn, -// but they do not have payment information set up, nor do they have -// administrative privileges. At the time the user is created, its email -// address and password are randomly generated--you don't even need to -// know them. -User user = UserFactory.CreateCommonUser(); //This method is defined elsewhere. - -// Log in as this user. -// Logging in on this site takes you to your personal "My Account" page, so the -// AccountPage object is returned by the loginAs method, allowing you to then -// perform actions from the AccountPage. +// Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +// pero no tienen configurada la información de pago, ni tienen +// privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +// la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +// conocerlos. +User user = UserFactory.CreateCommonUser(); //Este método se define en otro lugar. + +// Inicia sesión como este usuario. +// Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +// el método loginAs devuelve el objeto AccountPage, lo que le permite +// realizar acciones de AccountPage. AccountPage accountPage = LoginAs(user.Email, user.Password); {{< / code-panel >}} {{< code-panel language="ruby" >}} -# Create a user who has read-only permissions--they can configure a unicorn, -# but they do not have payment information set up, nor do they have -# administrative privileges. At the time the user is created, its email -# address and password are randomly generated--you don't even need to -# know them. -user = UserFactory.create_common_user #This method is defined elsewhere. - -# Log in as this user. -# Logging in on this site takes you to your personal "My Account" page, so the -# AccountPage object is returned by the loginAs method, allowing you to then -# perform actions from the AccountPage. +# Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +# pero no tienen configurada la información de pago, ni tienen +# privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +# la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +# conocerlos. +user = UserFactory.create_common_user #Este método se define en otro lugar. + +# Inicia sesión como este usuario. +# Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +# el método loginAs devuelve el objeto AccountPage, lo que le permite +# realizar acciones de AccountPage account_page = login_as(user.email, user.password) {{< / code-panel >}} {{< code-panel language="javascript" >}} -// Create a user who has read-only permissions--they can configure a unicorn, -// but they do not have payment information set up, nor do they have -// administrative privileges. At the time the user is created, its email -// address and password are randomly generated--you don't even need to -// know them. -var user = userFactory.createCommonUser(); //This method is defined elsewhere. - -// Log in as this user. -// Logging in on this site takes you to your personal "My Account" page, so the -// AccountPage object is returned by the loginAs method, allowing you to then -// perform actions from the AccountPage. +// Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +// pero no tienen configurada la información de pago, ni tienen +// privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +// la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +// conocerlos. +var user = userFactory.createCommonUser(); //Este método se define en otro lugar. + +// Inicia sesión como este usuario. +// Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +// el método loginAs devuelve el objeto AccountPage, lo que le permite +// realizar acciones de AccountPage. var accountPage = loginAs(user.email, user.password); {{< / code-panel >}} {{< code-panel language="kotlin" >}} -// Create a user who has read-only permissions--they can configure a unicorn, -// but they do not have payment information set up, nor do they have -// administrative privileges. At the time the user is created, its email -// address and password are randomly generated--you don't even need to -// know them. -val user = UserFactory.createCommonUser() //This method is defined elsewhere. - -// Log in as this user. -// Logging in on this site takes you to your personal "My Account" page, so the -// AccountPage object is returned by the loginAs method, allowing you to then -// perform actions from the AccountPage. +// Crea un usuario que tenga permisos de solo lectura--ellos pueden configurar un unicornio, +// pero no tienen configurada la información de pago, ni tienen +// privilegios administrativos. En el momento en que se crea el usuario, su correo electrónico +// la dirección y la contraseña se generan aleatoriamente--ni siquiera necesitas +// conocerlos. +val user = UserFactory.createCommonUser() //Este método se define en otro lugar. + +// Inicia sesión como este usuario. +// Iniciar sesión en este sitio te lleva a tu página personal "Mi cuenta", por lo que +// el método loginAs devuelve el objeto AccountPage, lo que le permite +// realizar acciones de AccountPage. val accountPage = loginAs(user.getEmail(), user.getPassword()) {{< / code-panel >}} {{< / code-tab >}} -As you can imagine, the `UserFactory` can be extended -to provide methods such as `createAdminUser()`, and `createUserWithPayment()`. -The point is, these two lines of code do not distract you from the ultimate purpose of this test: -configuring a unicorn. - -The intricacies of the [Page Object model]({{< ref "/guidelines_and_recommendations/page_object_models.es.md" >}}) -will be discussed in later chapters, but we will introduce the concept here: - -Your tests should be composed of actions, -performed from the user's point of view, -within the context of pages in the site. -These pages are stored as objects, -which will contain specific information about how the web page is composed -and how actions are performed– -very little of which should concern you as a tester. - -What kind of unicorn do you want? -You might want pink, but not necessarily. -Purple has been quite popular lately. -Does she need sunglasses? Star tattoos? -These choices, while difficult, are your primary concern as a tester– -you need to ensure that your order fulfillment center -sends out the right unicorn to the right person, -and that starts with these choices. - -Notice that nowhere in that paragraph do we talk about buttons, -fields, drop-downs, radio buttons, or web forms. -**Neither should your tests!** -You want to write your code like the user trying to solve their problem. -Here is one way of doing this (continuing from the previous example): +Como puedes imaginar, la `UserFactory` puede ampliarse para +proporcionar métodos como `createAdminUser()` y `createUserWithPayment()`. +El punto es, que estas dos líneas de código +no te distraigan del propósito final de esta prueba: configurar un +unicornio. + +Las complejidades del +[Modelo Page Object]({{< ref "/guidelines_and_recommendations/page_object_models.es.md" >}}) +serán discutidas en capítulos posteriores, pero introduciremos el concepto aquí: + +Tus pruebas deben estar compuestas de acciones, realizadas desde el +punto de vista del usuario, dentro del contexto de las páginas en el +sitio web. Estas páginas se almacenan como objetos, que contendrán +información específica sobre cómo está compuesta la página web y cómo +se realizan las acciones– muy poco de lo que cual debería preocuparte +como probador. + +¿Qué tipo de unicornio quieres? Es posible que desees rosa, pero no +necesariamente. El morado es muy popular últimamente. ¿Ella necesita +gafas de sol? ¿Tatuajes de estrellas? Estas elecciones, aunque +difíciles, son tu principal preocupación como probador: debes +asegurarte de que tu centro de distribución de pedidos envíe el +unicornio correcto a la persona correcta, y eso comienza con estas +elecciones. + +Observa que en ninguna parte de este párrafo hablamos de botones, +campos, menús desplegables, botones de opción o formularios web. +**¡Tampoco deberían tus pruebas!** Debes escribir tu código como el +usuario que intenta resolver su problema. Aquí hay una forma de +hacerlo (continuando con el ejemplo anterior): {{< code-tab >}} {{< code-panel language="java" >}} -// The Unicorn is a top-level Object--it has attributes, which are set here. -// This only stores the values; it does not fill out any web forms or interact -// with the browser in any way. +// El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +// Esto solo almacena los valores; no llena ningún formulario web ni interactúa +// con el navegador de ninguna manera. Unicorn sparkles = new Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS); -// Since we are already "on" the account page, we have to use it to get to the -// actual place where you configure unicorns. Calling the "Add Unicorn" method -// takes us there. +// Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +// lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +// nos llevará allí. AddUnicornPage addUnicornPage = accountPage.addUnicorn(); -// Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -// its createUnicorn() method. This method will take Sparkles' attributes, -// fill out the form, and click submit. +// Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +// su método createUnicorn(). Este método tomará los atributos de Sparkles, +// completara el formulario y hará clic en enviar. UnicornConfirmationPage unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles); {{< / code-panel >}} {{< code-panel language="python" >}} -# The Unicorn is a top-level Object--it has attributes, which are set here. -# This only stores the values; it does not fill out any web forms or interact -# with the browser in any way. +# El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +# Esto solo almacena los valores; no llena ningún formulario web ni interactúa +# con el navegador de ninguna manera. sparkles = Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS) -# Since we're already "on" the account page, we have to use it to get to the -# actual place where you configure unicorns. Calling the "Add Unicorn" method -# takes us there. +# Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +# lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +# nos llevará allí. add_unicorn_page = account_page.add_unicorn() -# Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -# its createUnicorn() method. This method will take Sparkles' attributes, -# fill out the form, and click submit. +# Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +# su método createUnicorn(). Este método tomará los atributos de Sparkles +# completara el formulario y hará clic en enviar. unicorn_confirmation_page = add_unicorn_page.create_unicorn(sparkles) {{< / code-panel >}} {{< code-panel language="csharp" >}} -// The Unicorn is a top-level Object--it has attributes, which are set here. -// This only stores the values; it does not fill out any web forms or interact -// with the browser in any way. +// El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +// Esto solo almacena los valores; no llena ningún formulario web ni interactúa +// con el navegador de ninguna manera. Unicorn sparkles = new Unicorn("Sparkles", UnicornColors.Purple, UnicornAccessories.Sunglasses, UnicornAdornments.StarTattoos); -// Since we are already "on" the account page, we have to use it to get to the -// actual place where you configure unicorns. Calling the "Add Unicorn" method -// takes us there. +// Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +// lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +// nos llevará allí. AddUnicornPage addUnicornPage = accountPage.AddUnicorn(); -// Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -// its createUnicorn() method. This method will take Sparkles' attributes, -// fill out the form, and click submit. +// Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +// su método createUnicorn(). Este método tomará los atributos de Sparkles, +// completara el formulario y hará clic en enviar. UnicornConfirmationPage unicornConfirmationPage = addUnicornPage.CreateUnicorn(sparkles); {{< / code-panel >}} {{< code-panel language="ruby" >}} -# The Unicorn is a top-level Object--it has attributes, which are set here. -# This only stores the values; it does not fill out any web forms or interact -# with the browser in any way. +# El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +# Esto solo almacena los valores; no llena ningún formulario web ni interactúa +# con el navegador de ninguna manera. +sparkles = Unicorn("Sparkles", Unicor sparkles = Unicorn.new('Sparkles', UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS) -# Since we're already "on" the account page, we have to use it to get to the -# actual place where you configure unicorns. Calling the "Add Unicorn" method -# takes us there. +# Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +# lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +# nos llevará allí. add_unicorn_page = account_page.add_unicorn -# Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -# its createUnicorn() method. This method will take Sparkles' attributes, -# fill out the form, and click submit. +# Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +# su método createUnicorn(). Este método tomará los atributos de Sparkles +# completara el formulario y hará clic en enviar. unicorn_confirmation_page = add_unicorn_page.create_unicorn(sparkles) {{< / code-panel >}} {{< code-panel language="javascript" >}} -// The Unicorn is a top-level Object--it has attributes, which are set here. -// This only stores the values; it does not fill out any web forms or interact -// with the browser in any way. +// El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +// Esto solo almacena los valores; no llena ningún formulario web ni interactúa +// con el navegador de ninguna manera. var sparkles = new Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS); -// Since we are already "on" the account page, we have to use it to get to the -// actual place where you configure unicorns. Calling the "Add Unicorn" method -// takes us there. - +// Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +// lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +// nos llevará allí. var addUnicornPage = accountPage.addUnicorn(); -// Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -// its createUnicorn() method. This method will take Sparkles' attributes, -// fill out the form, and click submit. +// Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +// su método createUnicorn(). Este método tomará los atributos de Sparkles, +// completara el formulario y hará clic en enviar.. var unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles); {{< / code-panel >}} {{< code-panel language="kotlin" >}} -// The Unicorn is a top-level Object--it has attributes, which are set here. -// This only stores the values; it does not fill out any web forms or interact -// with the browser in any way. +// El Unicornio es un Objeto de nivel superior--tiene atributos, que se establecen aquí. +// Esto solo almacena los valores; no llena ningún formulario web ni interactúa +// con el navegador de ninguna manera. val sparkles = Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS) -// Since we are already "on" the account page, we have to use it to get to the -// actual place where you configure unicorns. Calling the "Add Unicorn" method -// takes us there. +// Dado que ya estamos "en" la página de la cuenta, tenemos que usarla para acceder al +// lugar especifico donde configuras unicornios. Llamar al método "Agregar unicornio" +// nos llevará allí.. val addUnicornPage = accountPage.addUnicorn() -// Now that we're on the AddUnicornPage, we will pass the "sparkles" object to -// its createUnicorn() method. This method will take Sparkles' attributes, -// fill out the form, and click submit. +// Ahora que estamos en la página AddUnicornPage, pasaremos el objeto "sparkles" a +// su método createUnicorn(). Este método tomará los atributos de Sparkles, +// completara el formulario y hará clic en enviar. unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles) {{< / code-panel >}} {{< / code-tab >}} -Now that you have configured your unicorn, -you need to move on to step 3: making sure it actually worked. +Ahora que has configurado tu unicornio, +debes avanzar al paso 3: asegurarte de que realmente funcionó. {{< code-tab >}} {{< code-panel language="java" >}} -// The exists() method from UnicornConfirmationPage will take the Sparkles -// object--a specification of the attributes you want to see, and compare -// them with the fields on the page. -Assert.assertTrue("Sparkles should have been created, with all attributes intact", unicornConfirmationPage.exists(sparkles)); +// El método exist() de UnicornConfirmationPage tomará el objeto +// Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +// con los campos en la página. +Assert.assertTrue("Sparkles debe haberse creado, con todos los atributos intactos", unicornConfirmationPage.exists(sparkles)); {{< / code-panel >}} {{< code-panel language="python" >}} -# The exists() method from UnicornConfirmationPage will take the Sparkles -# object--a specification of the attributes you want to see, and compare -# them with the fields on the page. -assert unicorn_confirmation_page.exists(sparkles), "Sparkles should have been created, with all attributes intact" +# El método exist() de UnicornConfirmationPage tomará el objeto +# Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +# con los campos en la página. +assert unicorn_confirmation_page.exists(sparkles), "Sparkles debe haberse creado, con todos los atributos intactos" {{< / code-panel >}} {{< code-panel language="csharp" >}} -// The exists() method from UnicornConfirmationPage will take the Sparkles -// object--a specification of the attributes you want to see, and compare -// them with the fields on the page. -Assert.True(unicornConfirmationPage.Exists(sparkles), "Sparkles should have been created, with all attributes intact"); +// El método exist() de UnicornConfirmationPage tomará el objeto +// Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +// con los campos en la página. +Assert.True(unicornConfirmationPage.Exists(sparkles), "Sparkles debe haberse creado, con todos los atributos intactos"); {{< / code-panel >}} {{< code-panel language="ruby" >}} -# The exists() method from UnicornConfirmationPage will take the Sparkles -# object--a specification of the attributes you want to see, and compare -# them with the fields on the page. -expect(unicorn_confirmation_page.exists?(sparkles)).to be, 'Sparkles should have been created, with all attributes intact' +# El método exist() de UnicornConfirmationPage tomará el objeto +# Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +# con los campos en la página. +expect(unicorn_confirmation_page.exists?(sparkles)).to be, 'Sparkles debe haberse creado, con todos los atributos intactos' {{< / code-panel >}} {{< code-panel language="javascript" >}} -// The exists() method from UnicornConfirmationPage will take the Sparkles -// object--a specification of the attributes you want to see, and compare -// them with the fields on the page. -assert(unicornConfirmationPage.exists(sparkles), "Sparkles should have been created, with all attributes intact"); +// El método exist() de UnicornConfirmationPage tomará el objeto +// Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +// con los campos en la página. +assert(unicornConfirmationPage.exists(sparkles), "Sparkles debe haberse creado, con todos los atributos intactos"); {{< / code-panel >}} {{< code-panel language="kotlin" >}} -// The exists() method from UnicornConfirmationPage will take the Sparkles -// object--a specification of the attributes you want to see, and compare -// them with the fields on the page. -assertTrue("Sparkles should have been created, with all attributes intact", unicornConfirmationPage.exists(sparkles)) +// El método exist() de UnicornConfirmationPage tomará el objeto +// Sparkles--una especificación de los atributos que deseas ver, y los va a comparar +// con los campos en la página. +assertTrue("Sparkles debe haberse creado, con todos los atributos intactos", unicornConfirmationPage.exists(sparkles)) {{< / code-panel >}} {{< / code-tab >}} -Note that the tester still has not done anything but talk about unicorns in this code– -no buttons, no locators, no browser controls. -This method of _modelling_ the application -allows you to keep these test-level commands in place and unchanging, -even if Larry decides next week that he no longer likes Ruby-on-Rails -and decides to re-implement the entire site -in the latest Haskell bindings with a Fortran front-end. - -Your page objects will require some small maintenance in order to -conform to the site redesign, -but these tests will remain the same. -Taking this basic design, -you will want to keep going through your workflows with the fewest browser-facing steps possible. -Your next workflow will involve adding a unicorn to the shopping cart. -You will probably want many iterations of this test in order to make sure the cart is keeping its state properly: -Is there more than one unicorn in the cart before you start? -How many can fit in the shopping cart? -If you create more than one with the same name and/or features, will it break? -Will it only keep the existing one or will it add another? - -Each time you move through the workflow, -you want to try to avoid having to create an account, -login as the user, and configure the unicorn. -Ideally, you will be able to create an account -and pre-configure a unicorn via the API or database. -Then all you have to do is log in as the user, locate Sparkles, -and add her to the cart. - - -### To automate or not to automate? - -Is automation always advantageous? When should one decide to automate test -cases? - -It is not always advantageous to automate test cases. There are times when -manual testing may be more appropriate. For instance, if the application’s user -interface will change considerably in the near future, then any automation -might need to be rewritten anyway. Also, sometimes there simply is not enough -time to build test automation. For the short term, manual testing may be more -effective. If an application has a very tight deadline, there is currently no -test automation available, and it’s imperative that the testing gets done within -that time frame, then manual testing is the best solution. +Ten en cuenta que el probador aún no ha hecho nada más que hablar de +unicornios en este código-- nada de botones, nada de localizadores, +nada de controles del navegador. Este método de _modelar_ la +aplicación te permite mantener estos comandos de nivel-de-prueba en +su lugar y sin cambios, incluso si Larry decide la próxima semana que +ya no le gusta Ruby-on-Rails y decide volver a implementar todo el +sitio en las últimas ataduras de Haskell con un front-end de Fortran. + +Los objetos de tu página requerirán un pequeño mantenimiento para +poder cumplir con el rediseño del sitio, pero estas pruebas seguirán +siendo iguales. Tomando este diseño básico, querrás continuar con tus +flujos de trabajo con la menor cantidad posible de pasos orientados +al navegador. Tu próximo flujo de trabajo implicará agregar un +unicornio al carrito de compras. Probablemente querrás muchas +iteraciones de esta prueba para asegurarte de que el carrito mantiene +su estado correctamente: ¿Hay más de un unicornio en el carrito antes +de comenzar? ¿Cuántos pueden caber en el carrito de compras? Si crea +más de uno con el mismo nombre y/o características, ¿se romperá? +¿Conservará solo el existente o agregará otro? + +Cada vez que te mueves por el flujo de trabajo, deseas evitar tener +que crear una cuenta, iniciar sesión como usuario y configurar el +unicornio. Idealmente, podrás crear una cuenta y preconfigurar un +unicornio a través de la API o de la base de datos. Luego, todo lo +que tienes que hacer es iniciar sesión como usuario, ubicar Sparkles, +y agrégarla al carrito. + + +### ¿Automatizar o no automatizar? + +Es la automatización siempre ventajosa? Cuando uno debería decidir +automatizar casos de prueba? + +No siempre es ventajoso automatizar casos de prueba. Hay veces que +las pruebas manuales pueden ser mas apropiadas. Por ejemplo, si la +interface de usuario de la aplicación va a cambiar considerablemente +en el futuro, entonces no habria que reescribir ninguna +automatizacion. Tambien, algunas veces simplemente no hay tiempo +suficiente para construir la automatización de las pruebas. A corto +plazo, las pruebas manuales pueden ser mas efectivas. Si una +aplicación tiene una fecha limite muy ajustada, actualmente no hay +ningún tipo de automatización de pruebas, y es imperativo que las +pruebas se realicen dentro de la fecha limite, entonces las pruebas es la +mejor solución. \ No newline at end of file diff --git a/docs_source_files/content/introduction/types_of_testing.de.md b/docs_source_files/content/introduction/types_of_testing.de.md index 14f3cfaf65ed..446077040d74 100644 --- a/docs_source_files/content/introduction/types_of_testing.de.md +++ b/docs_source_files/content/introduction/types_of_testing.de.md @@ -8,10 +8,14 @@ weight: 3 auf Deutsch übersetzt. Sprichst Du Deutsch? Hilf uns die Seite zu übersetzen indem Du uns einen Pull Reqeust schickst! {{% /notice %}} -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. + +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. For web applications, the automation of this testing can be done directly with Selenium by simulating user expected behaviour. @@ -21,8 +25,13 @@ Note: Acceptance testing is a subtype of **_functional testing_**, which some people might also refer to. ### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. This generally includes: the tests work without errors (404, exceptions...), in a usable way (correct redirections), diff --git a/docs_source_files/content/introduction/types_of_testing.en.md b/docs_source_files/content/introduction/types_of_testing.en.md index 173b22d78070..e4b8cf2138b6 100644 --- a/docs_source_files/content/introduction/types_of_testing.en.md +++ b/docs_source_files/content/introduction/types_of_testing.en.md @@ -2,10 +2,14 @@ title: "Types of testing" weight: 3 --- -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. + +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. For web applications, the automation of this testing can be done directly with Selenium by simulating user expected behaviour. @@ -15,8 +19,13 @@ Note: Acceptance testing is a subtype of **_functional testing_**, which some people might also refer to. ### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. This generally includes: the tests work without errors (404, exceptions...), in a usable way (correct redirections), diff --git a/docs_source_files/content/introduction/types_of_testing.es.md b/docs_source_files/content/introduction/types_of_testing.es.md index 1f2b377d8c63..9aea41858c6a 100644 --- a/docs_source_files/content/introduction/types_of_testing.es.md +++ b/docs_source_files/content/introduction/types_of_testing.es.md @@ -1,122 +1,126 @@ --- -title: "Types of testing" +title: "Tipos de pruebas" weight: 3 --- -{{% notice info %}} - Page being translated from -English to Spanish. Do you speak Spanish? Help us to translate -it by sending us pull requests! -{{% /notice %}} - -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. - -For web applications, the automation of this testing can be done -directly with Selenium by simulating user expected behaviour. -This simulation could be done by record/playback or through the -different supported languages as explained in this documentation. -Note: Acceptance testing is a subtype of **_functional testing_**, -which some people might also refer to. - -### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. - -This generally includes: the tests work without errors -(404, exceptions...), in a usable way (correct redirections), -in an accessible way and matching its specifications -(see **_acceptance testing_** above). - -For web applications, the automation of this testing can be -done directly with Selenium by simulating expected returns. -This simulation could be done by record/playback or through -the different supported languages as explained in this documentation. - -### Performance testing -As its name indicates, performance tests are done -to measure how well an application is performing. - -There are two main sub-types for performance testing: - -#### Load testing -Load testing is done to verify how well the -application works under different defined loads -(usually a particular number of users connected at once). - -#### Stress testing -Stress testing is done to verify how well the -application works under stress (or above the maximum supported load). - -Generally, performance tests are done by executing some -Selenium written tests simulating different users -hitting a particular function on the web app and -retrieving some meaningful measurements. - -This is generally done by other tools that retrieve the metrics. -One such tool is **_JMeter_**. - -For a web application, details to measure include -throughput, latency, data loss, individual component loading times... - -Note 1: All browsers have a performance tab in their -developers' tools section (accessible by pressing F12) - -Note 2: is a subtype of **_non-functional testing_** -as this is generally measured per system and not per function/feature. - -### Regression testing -This testing is generally done after a change, fix or feature addition. - -To ensure that the change has not broken any of the existing -functionality, some already executed tests are executed again. - -The set of re-executed tests can be full or partial -and can include several different types, depending -on the application and development team. - -### Test driven development (TDD) -Rather than a test type _per se_, TDD is an iterative -development methodology in which tests drive the design of a feature. - -Each cycle starts by creating a set of unit tests that -the feature should eventually pass (they should fail their first time executed). - -After this, development takes place to make the tests pass. -The tests are executed again, starting another cycle -and this process continues until all tests are passing. - -This aims to speed up the development of an application -based on the fact that defects are less costly the earlier they are found. - -### Behavior-driven development (BDD) -BDD is also an iterative development methodology -based on the above TDD, in which the goal is to involve -all the parties in the development of an application. - -Each cycle starts by creating some specifications -(which should fail). Then create the failing unit -tests (which should also fail) and then do the development. - -This cycle is repeated until all types of tests are passing. - -In order to do so, a specification language is -used. It should be understandable by all parties and -simple, standard and explicit. -Most tools use **_Gherkin_** as this language. - -The goal is to be able to detect even more errors -than TDD, by targeting potential acceptance errors -too and make communication between parties smoother. - -A set of tools are currently available -to write the specifications and match them with code functions, -such as **_Cucumber_** or **_SpecFlow._** - -A set of tools are built on top of Selenium to make this process -even faster by directly transforming the BDD specifications into -executable code. -Some of these are **_JBehave, Capybara and Robot Framework_**. - +### Pruebas de aceptación +Este tipo de prueba se realiza para determinar si una funcionalidad +o un sistema cumple con las expectativas y requerimientos del cliente. +Este tipo de pruebas generalmente implican la cooperación o retroalimentación del cliente, +siendo una actividad de validación que responde la pregunta: +>¿Estamos construyendo el producto **_correcto_**?. + +Para aplicaciones web, la automatización de esta prueba se puede +hacer directamente con Selenium simulando el comportamiento esperado +del usuario. Esta simulación podría hacerse mediante grabación/ +reproducción o mediante los diferentes lenguajes soportados como se explica +en esta documentación. Nota: Las pruebas de aceptación son un subtipo +de **_pruebas funcionales_**, a lo que algunas personas también +podrían referirse. + +### Pruebas funcionales +Este tipo de prueba se realiza para determinar si una +funcionalidad o sistema funciona correctamente y sin problemas. +Se comprueba el sistema en diferentes niveles para garantizar que +todos los escenarios están cubiertos y que el sistema hace _lo que_ +se supone que debe de hacer. Es una actividad de verificación que +responde la pregunta: +>¿Estamos construyendo el producto **_correctamente?_**. + +Para aplicaciones web, la automatización de esta prueba puede ser +hecha directamente con Selenium simulando los retornos esperados. +Esta simulación podría hacerse mediante grabación/reproducción o +mediante los diferentes lenguajes soportados como se explica en esta +documentación. + +### Pruebas de rendimiento +Como su nombre indica, se realizan pruebas +de rendimiento para medir qué tan bien está funcionando una +aplicación. + +Hay dos subtipos principales para las pruebas de rendimiento: + +#### Pruebas de carga +La prueba de carga se realiza para verificar qué +tan bien la aplicación funciona bajo diferentes cargas definidas ( +generalmente un número particular de usuarios conectados a la vez). + +#### Pruebas de estrés +Se realizan pruebas de estrés para verificar +qué tan bien la aplicación funciona bajo estrés (o por encima de la +carga máxima soportada). + +En general, las pruebas de rendimiento se realizan ejecutando algunas +pruebas de Selenium que simulan diferentes usuarios golpeando +una función particular en la aplicación web y obteniendo algunas +medidas significativas. + +En general, esto lo hacen otras herramientas que obtienen las +métricas. Una de esas herramientas es **_JMeter_**. + +Para una aplicación web, los detalles a medir incluyen rendimiento, +latencia, pérdida de datos, tiempos de carga de componentes +individuales... + +Nota 1: Todos los navegadores tienen una pestaña de rendimiento en su +sección de herramientas para desarrolladores (accesible presionando +F12) + +Nota 2: es un subtipo de **_pruebas no funcionales_** ya que esto +generalmente se mide por sistema y no por función/funcionalidad. + +### Pruebas de regresión +Esta prueba generalmente se realiza después +de un cambio, corrección o adición de funcionalidad. + +Para garantizar que el cambio no ha roto ninguna de las funcionalidades +existentes, algunas pruebas ya ejecutadas se ejecutan nuevamente. +El conjunto de pruebas ejecutadas nuevamente puede ser total o +parcial, y puede incluir varios tipos diferentes, dependiendo del +equipo de desarrollo y la aplicación. + +### Desarrollo guiado por pruebas (TDD) +En lugar de un tipo de prueba _per se_, TDD es una +metodología iterativa de desarrollo en la que las pruebas guían el +diseño de una funcionalidad. + +Cada ciclo comienza creando un conjunto de pruebas unitarias que la +funcionalidad debería pasar finalmente (deberían fallar la primera +vez que se ejecuta). + +Después de esto, se lleva a cabo el desarrollo para pasar las +pruebas. Las pruebas se ejecutan nuevamente, comenzando otro ciclo y +este proceso continúa hasta que todas las pruebas pasen. + +El objetivo es acelerar el desarrollo de una aplicación basado en el +hecho de que los defectos son menos costosos cuanto más antes se +encuentran. + +### Desarrollo guiado por comportamiento (BDD) +BDD es también una metodología de desarrollo iterativo basado en +el TDD anterior, en el que el objetivo es involucrar todas las +partes en el desarrollo de una aplicación. + +Cada ciclo comienza creando algunas especificaciones (que deberían +fallar). Luego creando las pruebas unitarias fallidas (que también deberían +fallar) y luego hacer el desarrollo. + +Este ciclo se repite hasta que pasan todos los tipos de pruebas. + +Para realizar esto, se usa un lenguaje de especificación. Debe ser +simple y entendible por todas las partes, estándar y explícito. La +mayoría de las herramientas usan **_Gherkin_** como este +lenguaje. + +El objetivo es poder detectar aún más errores que TDD, apuntando +también a posibles errores de aceptación y a facilitar la comunicación +entre las partes. + +Actualmente hay un conjunto de herramientas disponibles para +escribir las especificaciones y relacionarlas con funciones de +código, como **Cucumber** o **_SpecFlow._** + +Un conjunto de herramientas se han construido encima de Selenium para realizar +este proceso aún más rápido al transformar directamente las +especificaciones de BDD en código ejecutable. Algunas de estas son + **_JBehave, Capybara y Robot Framework_**. \ No newline at end of file diff --git a/docs_source_files/content/introduction/types_of_testing.fr.md b/docs_source_files/content/introduction/types_of_testing.fr.md index 86f102f4ef3c..53b29e4f2881 100644 --- a/docs_source_files/content/introduction/types_of_testing.fr.md +++ b/docs_source_files/content/introduction/types_of_testing.fr.md @@ -3,27 +3,39 @@ title: "Types de test" weight: 3 --- -## Test d'acceptation -Ce type de test est effectué pour déterminer si un produit -fonction correspond à ses besoins. -Cela implique généralement les commentaires ou les spécifications du client. - -Pour les applications web, l'automatisation de ces tests peut se faire -directement avec Selenium en simulant le comportement attendu de l'utilisateur. -Cette simulation peut être effectuée par enregistrement / lecture ou par -différentes langues prises en charge comme expliqué dans cette documentation. -Remarque: les tests d'acceptation sont un sous-type de **_tests fonctionnels_**, -auquel certaines personnes pourraient également se référer. +{{% notice info %}} + Page being translated from +English to French. Do you speak French? Help us to translate +it by sending us pull requests! +{{% /notice %}} +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. + +For web applications, the automation of this testing can be done +directly with Selenium by simulating user expected behaviour. +This simulation could be done by record/playback or through the +different supported languages as explained in this documentation. +Note: Acceptance testing is a subtype of **_functional testing_**, +which some people might also refer to. -### Test fonctionel - -Ce type de test est effectué pour déterminer si un produit est -la fonctionnalité fonctionne bien, sans problèmes. +### Functional testing +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. -Cela comprend généralement: les tests fonctionnent sans erreur -(404, exceptions ...), de manière utilisable (redirection droite), -de manière accessible et correspondant à ses spécifications -(voir **_test d'acceptation_** ci-dessus). +This generally includes: the tests work without errors +(404, exceptions...), in a usable way (correct redirections), +in an accessible way and matching its specifications +(see **_acceptance testing_** above). Pour les applications Web, l'automatisation de ces tests peut être fait directement avec Selenium en simulant les rendements attendus. diff --git a/docs_source_files/content/introduction/types_of_testing.ja.md b/docs_source_files/content/introduction/types_of_testing.ja.md index 6008ec889494..11306634960d 100644 --- a/docs_source_files/content/introduction/types_of_testing.ja.md +++ b/docs_source_files/content/introduction/types_of_testing.ja.md @@ -3,19 +3,40 @@ title: "テストの種類" weight: 3 --- - -## 受入テスト -このタイプのテストは、製品の機能が要件に一致するかどうかを判断するために行われます。 -これには通常、顧客のフィードバックまたは仕様が含まれます。 - -Webアプリケーションの場合、ユーザーの予想される動作をシミュレートすることで、このテストの自動化をSeleniumで直接実行できます。 -このシミュレーションは、このドキュメントで説明されているように、記録/再生によって、またはサポートされているさまざまな言語によって実行できます。 -注：受入テストは **機能テスト** のサブタイプであり、一部の人はこれも参照する場合があります。 - -### 機能テスト -このタイプのテストは、製品の機能が問題なく正常に機能するかどうかを判断するために行われます。 - -これには通常、エラーなし（404、例外…）、使用可能な方法（正しいリダイレクト）、アクセス可能な方法、およびその仕様に一致するテスト（上記の **受入テスト** を参照）が含まれます。 +{{% notice info %}} + Page being translated from +English to Japanese. Do you speak Japanese? Help us to translate +it by sending us pull requests! +{{% /notice %}} + +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. + +For web applications, the automation of this testing can be done +directly with Selenium by simulating user expected behaviour. +This simulation could be done by record/playback or through the +different supported languages as explained in this documentation. +Note: Acceptance testing is a subtype of **_functional testing_**, +which some people might also refer to. + +### Functional testing +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. + +This generally includes: the tests work without errors +(404, exceptions...), in a usable way (correct redirections), +in an accessible way and matching its specifications +(see **_acceptance testing_** above). Webアプリケーションの場合、期待されるリターンをシミュレートすることにより、このテストの自動化をSeleniumで直接実行できます。 このシミュレーションは、このドキュメントで説明されているように、記録/再生またはサポートされているさまざまな言語で実行できます。 diff --git a/docs_source_files/content/introduction/types_of_testing.ko.md b/docs_source_files/content/introduction/types_of_testing.ko.md index d7b0cd52d67d..827bf2f98791 100644 --- a/docs_source_files/content/introduction/types_of_testing.ko.md +++ b/docs_source_files/content/introduction/types_of_testing.ko.md @@ -9,10 +9,13 @@ English to Korean. Do you speak Korean? Help us to translate it by sending us pull requests! {{% /notice %}} -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. For web applications, the automation of this testing can be done directly with Selenium by simulating user expected behaviour. @@ -22,8 +25,13 @@ Note: Acceptance testing is a subtype of **_functional testing_**, which some people might also refer to. ### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. This generally includes: the tests work without errors (404, exceptions...), in a usable way (correct redirections), diff --git a/docs_source_files/content/introduction/types_of_testing.nl.md b/docs_source_files/content/introduction/types_of_testing.nl.md index 909af7aa48ac..c8bb6807f3b9 100644 --- a/docs_source_files/content/introduction/types_of_testing.nl.md +++ b/docs_source_files/content/introduction/types_of_testing.nl.md @@ -9,25 +9,33 @@ English to Dutch. Do you speak Dutch? Help us to translate it by sending us pull requests! {{% /notice %}} -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. For web applications, the automation of this testing can be done -directly with Selenium by simulating user expected behavior. +directly with Selenium by simulating user expected behaviour. This simulation could be done by record/playback or through the different supported languages as explained in this documentation. Note: Acceptance testing is a subtype of **_functional testing_**, which some people might also refer to. ### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. -This generally include: the tests work without errors -(404, exceptions...), in an usable way (right redirections), -in an accessible way and matching its specifications +This generally includes: the tests work without errors +(404, exceptions...), in a usable way (correct redirections), +in an accessible way and matching its specifications (see **_acceptance testing_** above). For web applications, the automation of this testing can be diff --git a/docs_source_files/content/introduction/types_of_testing.zh-cn.md b/docs_source_files/content/introduction/types_of_testing.zh-cn.md index 4a6eca435acd..754bb42f1342 100644 --- a/docs_source_files/content/introduction/types_of_testing.zh-cn.md +++ b/docs_source_files/content/introduction/types_of_testing.zh-cn.md @@ -8,25 +8,33 @@ weight: 3 您熟悉英语与简体中文吗？帮助我们翻译它，通过 pull requests 给我们！ {{% /notice %}} -## Acceptance testing -This type of test is done to determine if a product's -feature matches its requirements. -This generally involves the customer's feedback or specification. +### Acceptance testing +This type of testing is done to determine if a feature or system +meets the customer expectations and requirements. +This type of testing generally involves the customer's +cooperation or feedback, being a validation activity that +answers the question: +>Are we building the **_right_** product?. For web applications, the automation of this testing can be done -directly with Selenium by simulating user expected behavior. +directly with Selenium by simulating user expected behaviour. This simulation could be done by record/playback or through the different supported languages as explained in this documentation. Note: Acceptance testing is a subtype of **_functional testing_**, which some people might also refer to. - + ### Functional testing -This type of test is done to determine if a product's -feature functions properly, without issues. - -This generally include: the tests work without errors -(404, exceptions...), in an usable way (right redirections), -in an accessible way and matching its specifications +This type of testing is done to determine if a +feature or system functions properly without issues. It checks +the system at different levels to ensure that all scenarios +are covered and that the system does _what's_ +supposed to do. It's a verification activity that +answers the question: +>Are we building the product **_right?_**. + +This generally includes: the tests work without errors +(404, exceptions...), in a usable way (correct redirections), +in an accessible way and matching its specifications (see **_acceptance testing_** above). For web applications, the automation of this testing can be