Mostrando entradas con la etiqueta testing. Mostrar todas las entradas
Mostrando entradas con la etiqueta testing. Mostrar todas las entradas

lunes, 31 de agosto de 2015

Entendiendo qué es BDD (Behavior-Driven Development) (III). Cucumber y herramientas que entienden el lenguaje Gherkin

Como algun@ recordareis, hace unos seis meses me propuse hacer una serie completa de post sobre BDD. De hecho, escribí los dos primeros. Los que me conocen y ven como últimamente no tengo un minuto libre, que a su vez son muchos de aquellos que no daban un duro porque realmente terminara esa serie de post de BDD… acertaron, maldita sea, acertaron. Pero a medias, je, sólo a medias has acertado.
A medias porque Natalia Carretero, que va camino de convertirse en la experta killer en BDD, ha dado un paso al frente para solucionar la injusticia de dejar la serie de BDD incompleta. Ha tomado el testigo y aquí nos deja la parte III de la serie sobre BDD (y confiamos en que haya una 4 o las que hagan falta) 
Como explicaba Javier en el primer post de esta serie Entendiendo qué es BDD (Behavior-Driven Development) (I), Gherkin es de gran ayuda para los stakeholders (negocio, comerciales, etc.), para product owners y testers, proporcionando una forma sencilla de escribir test para que puedan ser entendidos por cualquiera.
En el segundo post (aquí te dejo el link),  Javier terminaba diciendo que hay herramientas capaces de entender los escenarios escritos en Gherkin, y ahí retomamos la serie de post, en las herramientas.

Las herramientas que entienden Gherkin

Pues bien, sabiendo esto, en la siguiente tabla te muestro algunas de las herramientas disponibles que entienden Gherkin, son herramientas con las que podrás utilizar BDD. La más conocida es Cucumber pero hay muchas más y disponibles para diferentes lenguajes. Véamos las más destacadas y los lenguajes en los que se suelen utilizar (os señalo los más conocidos en negrita):
JavaJBehave , JDave , Instinct , beanSpec
CCSpec
C#NSpec, NBehave
.NETNSpec , NBehave, SpecFlow
PHPPHPSpec, Behat
RubyRSpecCucumber
JavaScriptJSSpec , jspec
PhythonFreshen
Gracias a estas herramientas se pueden ejecutar pruebas automatizadas escritas en texto plano utilizando las ideas de BDD. Estas pruebas interactúan directamente con el código de la aplicación y están escritas en un lenguaje que cualquier persona puede entender, es decir, Gherkin, que representa la forma en la que se escriben estas pruebas en texto plano.
Cucumber marcó un antes y un después en la difusión de BDD y fue justo en este contexto cuando se estandarizó la sintaxis de especificación en texto plano, conocida como Gherkin. Por ello nos fijaremos en Cucumber. Pero que la tabla no os confunda, Cucumber está escrito en Ruby y a menudo las pruebas se realicen en ese lenguaje, pero también se puede utilizar con aplicaciones escritas en otros lenguajes de programación, como Java o .Net.
Sea cual sea el lenguaje en el que se realicen las pruebas, Cucumber ejecuta las pruebas tal y como os enseño a continuación:

Cómo ejecuta Cucumber una prueba

Aunque en otros post veremos un ejemplo de cómo utilizar Cucumber, en este vamos a ver cómo ejecuta Cucumber una prueba, por ser la herramienta más popular. Podemos diferenciar dos partes en una prueba:
– El caso de prueba, está en los archivos .feature (que están en la carpeta features). Son el dadocuando,entoncespero e y. Como ya vimos, tienen esta pinta:
bdd cucumber 1
Y la definición de un caso de prueba (donde se implementa la prueba, se ubican dentro de la carpeta step_definitions).
bdd cucumber 2
Cada escenario en Gherkin contiene una serie de casos de prueba escritos en un lenguaje que entienden todos. Estos también forman la documentación del sistema y necesitan la definición de los caso de pruebapara decir a Cucumber qué es lo que tiene que hacer.
Cuando Cucumber ejecuta un caso de prueba (Dado, Cuando, Entonces, Y, Pero), en un escenario, busca la definición correspondiente de dicho caso de prueba, es decir, la que coincida su texto, y la ejecuta el código que tenga en ella.
Para las imágenes de antes:
1 – Cucumber cogería primero el caso de prueba definido en una carpeta llamada features, un archivo con extensión .features que dice Dado un contexto inicial.
2 – A continuación, busca en una carpeta llamada step_definitions, la definición de caso de prueba que le corresponda. En este caso es:
bdd cucumber 3
3 – Ejecuta el código que tenga dentro
4 – Repite el mismo proceso para el resto de los casos de prueba
Y aquí termina este post. En el siguiente os diré como instalar Cucumber en diferentes sistemas operativos y un ejemplo de cómo utilizar Cucumber con Gherkin. Espero que os haya gustado mi primer post en este blog y ya sabéis, a comer mucho Pepino (Cucumber) y pepinillo (Gherkin) este verano ;) ¡Nos vemos en el siguiente!

Fuente: http://www.javiergarzas.com/2015/06/bdd-behavior-driven-development-3.html

Entendiendo qué es BDD (Behavior-Driven Development) (II). Los escenarios

Si recordáis la parte I de este post, hablamos de las historias de usuario o features (en el mundo BDD, aun con diferencias, puedes encontrar las historias de usuario bajo el término features) y de como, con el objetivo de automatizar el testing, cada historia de usuario se escribía usando un lenguaje llamado Gherkin.
Una “feature” contiene la descripción de la historia de usuario y uno o más escenarios (cada escenario vendrá a ser una prueba). Un escenario describe un ejemplo de comportamiento del sistema, son condiciones de aceptación de una historia de usuario y normalmente las proporcionan los product owner.
Si esto era una feature (historia de usuario):
Feature: Tener un Camion
As a Rockero
I want to a Camion
Because I want to be happy
Un escenario está compuesto de pasos:
  • Given, dada (condición previa para el escenario),
  • When, cuando (ejecutar una acción en la aplicación bajo prueba) y
  • Then, entonces (el resultado deseado)

Por ejemplo…

Scenario: haciendo ruido con mi camión
Given yo soy rockero y tengo un camión
When yo toco el claxon
Then suena un ruido estrepitoso que me hace feliz

Lo siguiente será definir cada paso. Es decir, y tirando de un popular ejemplo en el mundo BDD, para el escenario…

Scenario: Cutting vegetables
Given a cucumber that is 30 cm long
When I cut it in halves
Then I have two cucumbers
And both are 15 cm long

Podría escribir, utilizando expresiones regulares, por ejemplo, la siguiente definición:

#encoding: utf-8
Given /^a cucumber that is (\d+) cm long$/ do |arg1|
pending # express the regexp above with the code you wish you had end

When /^I cut it in havles$/ do
pending # express the regexp above with the code you wish you had end

Then /^I have two Cucumbers$/ do
pending # express the regexp above with the code you wish you had
end

Then /^both are (\d+) cm long$/ do |arg1|
pending # express the regexp above with the code you wish you had
end

No me adelanto más en esta segunda parte, y antes de ver con más detalle esas implementaciones, tenemos que ver antes las herramientas capaces de interpretar los escenarios, más concretamente., y como ejemplo de las mismas, vamos ver Cucumber en las siguientes partes de este post.

Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-2.html

Entendiendo qué es BDD (Behavior-Driven Development) (I)

Debe haber centenares post sobre BDD y sí… este es uno más, con las características especiales de estar en español y estar escrito y pensado para aquellos que desconocíais el tema BDD por completo y queráis en poco tiempo “saber de qué va” esto, de sacar la idea principal de por qué esto del BDD es importante y por qué cada vez se habla más de ello.
En las próximas semanas iré dejando un post sobre BDD y relacionados, este es una primera y básica introducción, el siguiente será probablemente de Cucumber, etc. Me vais a disculpar que no fije un día exacto para esta serie de post “BDD”, pero es que ando demasiado liado para poder comprometerme a un día exacto (de hecho, créeme, este post que lees, y otros restos de la serie, lo empecé en abril y lo he ido terminando a ratos)
Estaría encantado de recibir comentarios, mejoras, detalles, añadidos y demás, sé que entre los lectores del blog hay auténticos expertos en BDD, animaros y me ayudáis a difundir el conocimiento sobre el tema del BDD y de “las buenas pruebas”.
Vamos a ello…

¿Qué es eso de BDD?

Behavior-Driven Development ​​o BDD es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge.
BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario, ya sabes aquello tan usado en agilidad (sino léete el anterior post)… “Como [rol ] quiero [ característica ] para que [los beneficios].”
Y, siguiendo con lo anterior, posteriormente escribir criterios de aceptación para esas historias de usuario, haciéndolo en términos de escenarios:
Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]
Given [initial context], when [event occurs], then [ensure some outcomes].
Así, simplificadamente, el ciclo básico de BDD sería el siguiente…
1 – Escribir las historias de usuario.
2 – Escribir los escenarios.
3 – Automatizar las pruebas de aceptación.
Ya sabes, con la idea final de tener un mismo “framework” de comunicación y colaboración entre desarrolladores, QA y roles no técnicos, o de negocio, en un proyecto de software. Y para tener ese punto común entre todos esos actores, algo clave es tener un lenguaje común, y ahí es donde aparece Gherkin…

Gherkin

Las historias de usuario que comentamos antes, o features (en el mundo BDD puedes encontrar las historias de usuario bajo el nombre de features, hay quien dice que no son exactamente lo mismo, pero para nosotros por ahora sí lo son), lógicamente, las escribe negocio, es responsabilidad del product owner.
En BDD, lo que haremos será, con el objetivo de automatizar el testing, aparte de tener historias en pósit, como ha sido de toda la vida, cada historia de usuario se escribirá usando un lenguaje “de programación”, llamado Gherkin (la traducción es pepinillo), y se guardarán en un fichero, de extensión .feature (normalmente dentro de un directorio llamado “features”, para más datos).
Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda “negocio”, los usuarios, etc. Su idea es contar como se “comporta” el software sin entrar en detalles de implementación.
Es un lenguaje muy simple. Sólo tienen 5 sentencias:
Feature:
Scenario:
Given
When
Then
Estas features serían historias de usuario. Y como es típico en una historia de usuario, deben tener el “As a / I want to / Because”. Vamos con un ejemplo, la historia de usuario “Tener un Camión”:
Feature: Tener un Camion
As a Rockero
I want to a Camion
Because I want to be happy
Así que Gherkin nos sirve para documentar y para automatizar lo que luego se convertirá en test, haciéndolo con un lenguaje que puede entender negocio, o cualquier product owner, y que además puedes usar en otros idiomas más allá del inglés, hasta la fecha en 40 idiomas.
Luego necesitaremos una herramienta que entienda los .feature, por ejemplo, Cucumber (para Ruby), que cuando lo lanzas genera un informe que verifica si el software se comporta como el fichero Gherkin dice. Para ello, alguien del equipo habrá escrito código que transforma el texto de Gherkin en interacciones con el código a probar, pero antes, para ello, necesitaremos escenarios asociados a cada historia de usuario, que nos den ejemplos de cómo debe comportarse el software implementado para esa historia.
Esos escenarios serán el paso intermedio entre la historia de usuario y la implementación de una prueba automatizada. Pero como este post ya se me a alargado demasiado… los escenarios y herramientas como cucumber… lo dejo para la segunda parte.

Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-1.html

sábado, 29 de agosto de 2015

Pruebas no funcionales en Android

¿Que son las pruebas no funcionales? Para entender este tipo de pruebas es bueno tener claro que son las pruebas funcionales, estas pruebas se encargan verificar que una funcionalidad en específico, es decir un conjunto de entradas  son aplicadas a un módulo y según las salidas que este de se verifica si funciona correctamente o no. Si bien este tipo de pruebas son necesarias, no son las únicas y no muestran el comportamiento real de la aplicación bajo condiciones de producción. Por tal motivo se hace necesario realizar las pruebas no funcionales, estas se encargan de ver el comportamiento de la aplicación bajo situaciones similares a las de producción.
¿Que pruebas no funcionales existen?En una aplicación podemos evaluar los siguientes aspectos:
  • Manejo de memoria
  • Confiabilidad
  • Usabilidad
  • Mantenibilidad
  • Configurabilidad
  • Rendimiento (Estrés)
  • Seguridad
  • Portabilidad
  • Recuperación
  • Recuperación a desastres
  • Interoperabilidad
  • Compatibilidad
  • Instalabilidad
¿Como realizar pruebas no funcionales en Android?Para realizar este tipo de pruebas contamos con las siguientes herramientas:
  • Monkey:esta herramienta nos permite enviar eventos a nuestra aplicación, esta herramienta puede ser usada para realizar pruebas de estrés, ya que nos permite definir la cantidad de eventos que deseamos ejecutar, la frecuencia de estos, restricciones respecto a que paquetes realizar la prueba. Adicionalmente esta herramienta vigila los siguientes aspectos:
    • Si se bloquea la herramienta para trabajar sobre un paquete, y se intenta acceder a otro paquete, se bloqueará la acción.
    • Si la aplicación falla o lanza una excepción no controlada, la herramienta detiene la ejecución y reporta el error.
    • Si la aplicación no responde por algún error, la herramienta detiene la ejecución y reporta el error.
    Podemos ver que esta herramienta nos permite evaluar el comportamiento de la aplicación móvil (tanto en el dispositivo como en el emulador), reportando fallas en el funcionamiento de la misma, las cuales pueden ser reparadas.
  • Traceview:esta herramienta permite visualizar gráficamente los logs que generemos en nuestra aplicación, estos logs los podemos generar con funciones de rastreo o DDMS. (DDMS es una aplicación que ofrece un conjunto de funcionalidades para el debug, entre estas se encuentran métodos para perfilar la aplicación).Traceview ofrece dos formas de visualizar los datos:
    • Timeline Panel:De esta forma podemos ver el tiempo de ejecución de los métodos y diferentes hilos, como se muestra en la imagen:
      Timeline, tomado de Android developer
    • Profile Panel:Esta visualización muestra un listado de los métodos que se han ejecutado, podemos ver el tiempo de ejecución del método, el tiempo de ejecución del método y las funciones que este llame en su interior, cantidad de veces que el método es llamado. Adicionalmente para cada método se muestra el listado de métodos a los cuales este llama, y de los cuales el ha sido llamado, para diferenciar estos dos se utiliza el color purpura y amarillo como color de fondo.
      Profile Panel. Tomado de Android Developer
      Para almacenar información en el log podemos llamar a los métodos:Debug.startMethodTracing(“NombreLog”); //Iniciar el log
      Debug.stopMethodTracing(); //Detener el log
      De esta forma tenemos un control muy preciso sobre el código que deseamos evaluar.
      La información arrojada por los logs y las gráficas seria de gran ayuda en determinar el rendimiento de la aplicación ya que los tiempos nos permiten determinar cuales métodos deben ser optimizados para una más rápida ejecución.
  • Manejo de memoria: Para evaluar el consumo de memoria en nuestra aplicación podemos usar la herramienta “allocation tracker” la cual hace parte del DDMS, esta herramienta nos permitirá conectarnos a nuestra aplicación y nos mostrará el listado de objetos utilizados por la misma, el hilo, la clase y el método en el cual fueron creados.
Bibliografia:


Fuente: https://codeater.wordpress.com/2012/05/06/pruebas-no-funcionales-en-android/

martes, 4 de agosto de 2015

Mind Tools: Un catálogo de metodologías y técnicas que no te puedes perder

recetas

Esta semana vuelvo al clásico de los posts rápidos para dejarte una referencia que creo que no te puedes perder.

Se trata de la web Mind Tools, un repositorio de referencias muy completo sobre metodologías y técnicas asociadas a la gestión de equipos, toma de decisiones, gestión de proyectos, productividad personal, técnicas de comunicación… y un largo etcétera.
Mind tools metodologías
Listado de áreas cubiertas por Mind Tools (haz clic para ver a tamaño completo)
Para muestra, te dejo unos enlaces para que los sigas y te convenzas de la potencia de esta Web:
¿Qué opinas de Mind Tools? ¿Crees que te puede ser útil para abordar los retos del día a día?

Fuente: http://formandobits.com/2015/04/mind-tools-un-catalogo-de-metodologias-y-tecnicas-que-no-te-puedes-perder/

lunes, 3 de agosto de 2015

Top 100 Software Testing Blogs

Here it is at last: my first Top 100 of Software Testing Blogs. For those who would like to read more on Software Testing and QA, I created a list with 100 of the best - or at least most popular - Software Testing Blogs in the world. This should definitely give you enough reading!

Note: A more recent Software Testing top list is now available at testbuffet.com. Read this post for more details: Top 114 software testing blogs in 2014.

I ordered this list by gathering several metrics of each blog, to be more precise: the Google Pagerank, Alexa Popularity, Technorati Authority, number of comments and number of sites linking to it.(Note: Not all statistics were available for each blog. Where a statistic was missing, the blog in question simply scored 'neutral' for that statistic). You can read the algorythm I used to rank the blogs at noop.nl. Many of the results were gathered automatically using my Pagerank Checking script.

Enjoy the list and please let me know which blogs I forgot!



#SiteAuthor
1James Bach's BlogJames Bach
2Testing at the Edge of ChaosMatt Heusser
3Agile Testing Grig Gheorghiu
4Martinfowler.comMartin Fowler
5Tester Tested!Pradeep Soundararajan
6Testing BlogGoogle Testing
7Cem Kaner’s BlogCem Kaner
8Miško HeveryMiško Hevery
9DevelopSenseMichael Bolton
10Sara Ford's WeblogSara Ford
11Steve Rowe's BlogSteve Rowe
12Test ObsessedElisabeth Hendrickson
13Software Quality Insights( various )
14Exploration Through ExampleBrian Marick
15Gojko AdzicGojko Adzic
16Thinking TesterShrini Kulkarni
17Chris McMahon's BlogChris McMahon
18JW on TestJames Whittaker
19Software testing helpVijay
20Corey Goldberg Corey Goldberg
21Quality FrogBen Simo
22Testing Hotlist UpdateBret Pettichord
23AbakasCatherine Powell
24Collaborative Software TestingJonathan Kohl
25Sbarber's blogScott Barber
26Adam goucherAdam goucher
27Eric JarviEric Jarvi
28Karen N. Johnson's blogKaren N. Johnson
29Test GuideMichael Hunter
30Curious TesterParimala Shankaraiah
31Testy RedheadLanette Creamer
32Antony Marcano's blogAntony Marcano
33All Things QualityJoe Strazzere
34I. M. Testy Bj Rollinson
35Software testing zoneDebasis Pradhan
36PractiTest QA Blog Joel Montvelisky
37Practical QALinda Wilkinson
38Marlena’s BlogMarlena Compton
39Software Testing and moreEwald Roodenrijs, Andréas Prins
40patrickwilsonwelsh.comPatrick Wilson-Welsh
41Quality Assurance and Software Testing( various )
42Testing Testing 1,2,3Chan Chaiyochlarb
43Mike Kelly's blogMike Kelly
44Test this Blog Eric Jacobson
45Enjoy testing Ajay Balamurugadas
46Evil TesterAlan Richardson
47Tooth of the WeaselAlan Page
48Charlie Audritsh's blogCharlie Audritsh
49Maverick Tester Anne-Marie Charrett
50Paul Gerrard's blog Paul Gerrard
51shino.deMarkus Gaertner
52Cartoon TesterAndy Glover
53cLabs BlogkiChris Morris
54Jeff Fry on TestingJeff Fry
55Venkat's BlogVenkat Reddy Chintalapudi
56Agile Testing and Process ThoughtsJanet Gregory
57Software Testing Stuff( various )
58selenadelesie.comSelena Delesie
59Software SleuthingJosh Poley
60The Software Quality Blog Vijay Bhaskar
61Expected ResultsPhil Kirkham
62One of the wolvesTim Coulter
63Musing about Software TestingKeith Stobie
64Jon Bach's blogJonathan Bach
65Quardev( various )
66Software Testing Club Blog( various )
67TestToTesterSharath Byregowda
68Agile Testing with Lisa CrispinLisa Crispin
69Confessions of a Passionate TesterDawn Cannan
70I am filled with solutionsDustin Andrews
71Software TastingGeordie Keitt
72Rosie LandRosie Sherry
73Still LifeSteve Swanson
74Brian OsmanBrian Osman
75Dhanasekar S’s BlogDhanasekar S
76The Social Tester Rob Lambert
77QA InsightBrent Strange
78The Testing Blog( various )
79TestingmindedSteven Machtelinckx
80John McConda's blogJohn McConda
81Software TestingLen DiMaggio
82Jeroen's world of Software TestingJeroen Rosink
83TestingPerspectiveRahul Verma
84Adam White Adam White
85Purple Box TestingTrish Khoo
86Lessons Learned by a Software TesterPaul Carvalho
87Pliant AllianceTim Beck
88TestjutsuBen Kelly
89IlliterationJared Quinert
90Tester TestifiesRaj Kamal
91Santhosh Tuppad's BlogSanthosh Tuppad
92TeknologikaBruce McLeod
93Creative TesterAnuj Magazine
94Tester Troubles Ray Claridge
95Thoughts on QA and EngineeringJohn Overbaugh
96Quick Testing Tips( various )
97Cruisin QABrett Leonard
98QA Hates YouThe Director
99Tester Lost FocusMichelle Smith
100James McCaffrey's blogJames McCaffrey

Edit: Meanwhile some kind people have submitted blogs which I did not take into account when I created this list. They will be included in future updates.

Test Side Story from Zeger van Hese would have been number 70.
Quality Perspectives from Lynn McKee would have been number 107.
Unimagined Testing from Nancy Kelln would have been number 90.
Software Testing Genius from Yogindernath would have been number 66.
Rob Kuijt's Testing Blog from Rob Kuijt would have been number 51.

Fuente: http://www.testingminded.com/2010/04/top-100-software-testing-blogs.html

Test Design Techniques - Equivalence Partitioning, Boundary Value Analysis, Decision Tables, Use Case Testing and State Transition Testing

Equivalence Partitioning and Boundary Value Analysis video - This software testing tutorial explains the test design techniques and the benefits of using them (save time and find more defects). It explains equivalence partitioning and boundary value analysis test design techniques with a number of examples. So that you understand the EP and BVA techniques and remember them. Equivalence partitioning and boundary value analysis are used in both black box testing like system testing and white box testing like unit testing.

Decision Table Testing video - In this video, we understand a decision table. A decision table is a table of all possible conditions and corresponding actions. It is used to show complicated logic without forgetting any combination of conditions. Decision tables help in testing by listing all possible input conditions. First, we see a decision table example with conditions having binary values i.e. True or False values. Then we see another decision table example with conditions having multiple values. Then, we see the steps to simplify or minimize the decision table.

Use Case Testing video - In this video, we understand use cases, review a sample use case and write test cases for the example use case. A use case is a list of steps to complete a task in the system. These steps define the sequence of interactions between the actor and the system under test. The actor can be a user of the system or it can be another system. The use case lists the main scenarios (and optional exceptional scenarios). A use case may be accompanied by a use case diagram, but not always.
In use case testing, we review the use case e.g. the ATM cash withdrawal use case should only have the steps related to cash withdrawal, not the steps to view balance or deposit cash because the latter steps belong to other use cases. The use case should list all the steps in the normal workflow (scenario). Each step in the use case should be testable. The use case should list each alternate workflow. We design test cases to test the normal workflow and each alternate workflow.  We can design the test data using other test design techniques like equivalence partitioning and boundary value analysis. When we run the test cases, we should look out for any missing workflow(s), any missing step(s) in any workflow, boundary value defects etc.

State Transition Testing video - In this video, we understand state transition testing. A state is a particular condition in which the system can exist. A transition is movement from one valid state to another valid state. State transition testing is used when the system under test can be thought of being in a finite number of states. In state transition testing, we test all the valid transition between states. We can also test for invalid transitions to ensure that they are not allowed. State transition testing is explained in this video with the help of examples showing state transition diagrams, state tables and how to design test cases to test valid transitions.

Fuente: http://inderpsingh.blogspot.com/2015/07/TestDesign.html

Database Testing

Databases are an integral part of any software developed today. Whether you are a Software Tester or an owner of a web site, it is of an utmost importance to know about the underlying database.

The simplest task in dealing with databases is to write queries in order to communicate with a database. Web masters owning web sites or database administrators for complex or large software need certain level of expertise to perform complex tasks such as database monitoring, database auditing, database optimization, database models (also known as database schema), to name a few. This level of expertise calls for undergoing a comprehensive course.

For beginners, there is loads of online information about databases available on the Internet, like DatabaseGuides. It's a good idea for web masters to know about how their database works so that they can troubleshoot their own systems or know what is being done if a professional is hired.

Database Testing is an important aspect that a versatile Software Tester should be aware of. We'll discuss a few aspects of database testing here.

Why do we test database?

We all know that it's important to test the database our software uses. Your database holds confidential and valuable information which you would not like to be compromised. Testing the database provides us with a solid feedback essential for identifying defects.

What to test in database testing?

We need to consider the threats within the database (similar to White box Testing) as well as at the interface level (Similar to Black Box Testing).

Black Box testing might include, but not limited to:
Input data
Output Data (from queries, views, stored procedures)

White Box testing might include, but not limited to:
Unit tests for Stored Procedures / functions
Triggers / Views code
Referential Integrity

How to test?
When you want to test your database, you would need test databases that are replica of the original database. These are sometimes called as 'sandboxes' in agile terms. In this test database, you can experiment with data, develop new functionality, validate the changes and then integrate it with the project if satisfactory.

You'll need create database tests based on either rebuilding the existing database or starting afresh with creation of database and related schema. Identifying Test Data is an important task here. Once the tests are ready, you would execute them and check the results.

Database Testing is an elaborate topic that can't be fit in a single post. Would try and write more posts on the same.

Fuente: http://quality-assurance-software-testing.blogspot.com/