Usuarios Concurrentes (Concurrent Users)

Un tema que siempre es difícil de entender o asimilar es el tema de los Usuarios Concurrentes. Buscando en la red diversos artículos que explicaran esto pude encontrar un articulo de Alberto Savoia, un referente en Performance Testing (con solo poner su nombre en google lo veran ;)) llamado “Three Web load testing blunders, and how to avoid them” el cual explica de forma muy sencilla este concepto. Voy a tomar la primer parte de este y mas adelante haré lo mismo con los demas puntos ya que son muy importantes tambien.
En este articulo resalta:

El número de usuarios concurrentes no debe considerarse como entrada para el Load Testing , sino como el resultado de una serie de factores.

Esto viene al caso de que comúnmente uno define los escenarios de Performance o de pruebas de Carga de la manera: “La aplicación debe soportar un máximo de 250 usuarios concurrentes” poniendo implícitamente la cantidad e usuarios concurrentes como parámetro de entrada para las pruebas.

Se puede observar como ese valor no puede ser entrada con un ejemplo (Similar al del articulo de Alberto):
Hay 3 usuarios distintos que no se conocen entre si (van a tener acciones diferentes y desincronizadas)  y visitan la pagina de estado de cuenta de su banco 3 días consecutivos.
1º  Día
El Usuario 1 inicia sesión a las 12:00; el Usuario 2 inicia sesión a las 12:01 y el Usuario 3 inicia sesión a las 12:02 y cada uno de sus escenarios consiste en Login-> Home Page-> Cuenta Pesos ->Cuenta Dolares. Cada uno de los usuarios se toma 10 segundos mirando cada pagina (Think Time) antes de pasar a la siguiente; Si el tiempo de respuesta de cada pagina es de5 segundos  (tiempo que tarda en cargar) las sesiones de los 3 usuarios no se solaparan por lo que no habría usuarios concurrentes ya que el Usuario 1 va a recibir y ver cada una de las paginas antes de que el Usuario 2 inicie su sesión y el Usuario 2 va poder hacer lo mismo antes de que el Usuario 3 inicie su sesión.

Fig 1. No se da concurrencia de Usuarios

2º Día
En el 2º día el tiempo de respuesta de cada pagina aumenta al doble (10 segundos) pero el tiempo que le toma a cada usuario leer la pagina sigue siendo de 10 segundos, por lo que cada sesión tendra un tiempo total de 80 segundos en lugar de los 60 segundos que antes tomaba. Este cambio en la velocidad de carga de pagina (Response Time) produce 2 usuarios concurrentes donde antes no los había, superponiendo las tareas del Usuario 1 con las del Usuario 2 y luego las del Usuario 2 con las del Usuario 3 como se ve en el gráfico.

Fig 2. Hay 2 Usuarios concurrentes debido al cambio en el tiempo de respuesta

3º Día
En el 3º día el tiempo de respuesta baja aun mas, llegando a 30 segundos el tiempo de respuesta de cada pagina, tardando 160 segundos cada sesión de usuario. Esto provoca que las sesiones del Usuario 1 y Usuario 2 se superpongan por 60 segundos generando 2 usuarios concurrentes, luego se genera 3 usuarios son currentes con la superposición de las sesiones del Usuario 1, Usuario 2 y Usuario 3 para luego quedar en 2 usuarios concurrentes.

Fig 3. La cantidad de Usuarios Concurrentes llega a 3

Como se ve en los ejemplos el número de usuarios concurrentes no es una medida de la prueba de carga, ya que la carga fue idéntica en los 3 casos: tres usuarios, entrando al sistema en lapsos de un minuto, ven cuatro páginas cada uno con 10 segundos de Think Time por página.
En conclusión:

El número de usuarios concurrentes fue el resultado de la prueba de Carga:  es una medida de la habilidad del sitio web para manejar una carga especifica. Un sitio web más lento da lugar a más usuarios concurrentes.

Cuando se trata de medir la escalabilidad de un sitio Web, resulta que el número de usuarios concurrentes  ni siquiera es útil como resultado de la prueba de carga.
Si el sitio Web es un poco lento, el número de usuarios concurrentes aumenta. Si es realmente lento, una gran cantidad de usuarios reales lo abandonan, lo que reduce el número de usuarios concurrentes. Pero, por otra parte, si un sitio Web es muy rápido las sesiones se completan más rápidamente, reduciendo también el número de usuarios concurrentes.

La conclusión es que los usuarios concurrentes es una medida peligrosamente engañosa, es un indicador que puede ser utilizada de muchas maneras pero es prácticamente garantizado que da resultados cuestionables.

La pregunta inmediata es: ¿Qué medida debería usar en su lugar?
Para describir una entrada de carga, se puede utilizar la métrica inicio de sesiones de usuario por hora ya que es constante e independiente de la performance de la aplicación.

Fuente: http://josepablosarco.wordpress.com/2009/01/13/usuarios-concurrentes-concurrent-users/

Revista Professional Tester

La revista Profesional Tester fue creada en 1999 por los verdaderos pioneros de las pruebas de software. Es ampliamente considerada como la mejor revista que haya sido publicada para la industria, que se caracteriza por la calidad y el rigor, la opinión directa, y los artículos importantes que todavía influyen en cómo se hacen las pruebas de hoy. Este contenido serio se complementa con la escritura coloquial y humorística, completando un paquete popular que los probadores todavía quieren leer, releer, compartir, guardar y descargar.

Tester Profesional fue relanzado en 2010 como una revista bimensual. La publicación sigue siendo gratuita para los suscriptores, pero ahora es de distribución electrónica, así como en la impresión. Al igual que antes la revista ofrece artículos de intercambio de conocimientos sobre métodos y técnicas de prueba, y noticias sobre la industria de pruebas, comentarios y opinión sobre temas de prueba y características regulares.

Número 1 ( Permalink )    Número 2 ( Permalink )    Número 3 ( Permalink )    Número 4 ( Permalink )   Número 5 ( Permalink )       
Número 6 ( Permalink )    Número 7 ( Permalink )    Número 8 ( Permalink )    Número 9 ( Permalink )   Número 10 ( Permalink )
Número 11 ( Permalink )  Número 12 ( Permalink )   Número 13 ( Permalink )  Número 14 ( Permalink )  Número 15 ( Permalink )
Número 16 ( Permalink )  Número 17 ( Permalink )   Número 18 ( Permalink )  Número 19 ( Permalink )  Número 20 ( Permalink )
Número 21 ( Permalink )  Número 22 ( Permalink )   Número 23 ( Permalink )  Número 24 ( Permalink )

Chistes sobre Testing - Parte 4

  Parte 1    Parte 2    Parte 3    Parte 4

The Search

Under a streetlight, on a very dark night, a software tester was looking for a set of lost keys.

A policeman came by, asked him about the object of his search, and joined him to help. After the two had searched for some time, the policeman asked, “Are you sure you lost them here?”

“Oh, no,” said the software tester. “I lost the keys somewhere else.”

“Then why are you looking for them over here?” the policeman asked.

“Because this is where the light is!” the software tester replied.

Moral: Do not be so stupid that you search for bugs only at the obvious places.

Disney Password

A person with a developer background was hired as a software tester and assigned to a Disney website project. On reviewing his test data for the login feature, it was found that he had “MickeyDonaldGoofyPluto” for the password field. Amused, his manager asked him why.

“It says the password needs to have at least four characters.” he replied.

Food Testing

• THE GAG TEST: Anything that makes you gag is spoiled.
• EGGS: When something starts pecking its way out of the shell, the egg is probably past its prime.
• DAIRY PRODUCTS: Milk is spoiled when it starts to look like yogurt. Yogurt is spoiled when it starts to look like cottage cheese. Cottage cheese is spoiled when it starts to look like regular cheese. Regular cheese is nothing but spoiled milk anyway and can’t get any more spoiled than it is already.
• MEAT: If opening the refrigerator door causes stray animals from a three-block radius to congregate outside your house, the meat is spoiled.
• BREAD: Fuzzy and hairy looking white or green growth areas are a good indication that your bread has turned into a pharmaceutical laboratory experiment.
• CANNED GOODS: Any canned goods that have become the size or shape of a softball should be disposed of.
• GENERAL RULE OF THUMB: Most food cannot be kept longer than the average life span of a hamster. Keep a hamster in or nearby your refrigerator to gauge this.

Tickle Me Toys

There is a factory that makes Tickle Me toys. The toy laughs when you tickle it under the arms.

Jane is hired at the factory and she reports for her first day promptly. The next day there is a knock at the Personnel Manager’s door. The Foreman throws open the door and begins to rant about the new employee. He complains that she is incredibly slow and the whole line is delayed, putting the entire production line behind schedule.

The Personnel Manager decides he should see this for himself, so the two men march down to the factory floor. When they get there the line is so backed up that there are Tickle Me toys all piling up. At the end of the line stands a nervous Jane surrounded by mountains of Tickle Me toys.

She has a roll of thread and a huge bag of small marbles. The two men watch in amazement as she cuts a little piece of thread, wraps it around two marbles and begins to carefully sew the little package between the toy’s legs.

The Personnel Manager bursts into laughter. After several minutes of hysterics he pulls himself together, approaches Jane and says “I’m sorry, Jane, but I think you misunderstood the instructions I gave you yesterday. Your job was to give the toys two test tickles each.”

Fuente: http://softwaretestingfundamentals.com/software-testing-jokes/ 

¿Cuál es la diferencia entre ...?

Serie entradas sobre diferencias entre conceptos de Software Testing

• ¿Cuál es la diferencia entre pruebas de humo y pruebas funcionales?
  
• ¿Cuál es la diferencia entre prueba de regresión y re-testing?
  
• ¿Cuál es la diferencia entre pruebas de caja blanca y pruebas de caja negra?

Chistes sobre Testing - Parte 3

  Parte 1    Parte 2    Parte 3    Parte 4

The Glass

• To an optimist, the glass is half full.
• To a pessimist, the glass is half empty.
• To a good tester, the glass is twice as big as it needs to be.

Testing Definition

To tell somebody that he is wrong is called criticism. To do so officially is called testing.

Sign On Testers’ Doors

Do not disturb. Already disturbed!

Words

Developer: There is no I in TEAM
Tester: We cannot spell BUGS without U

Experience Counts

There was a software tester who had an exceptional gift for finding bugs. After serving his company for many years, he happily retired. Several years later, the company contacted him regarding a bug in a multi-million-dollar application which no one in the company was able to reproduce. They tried for many days to replicate the bug but without success.

In desperation, they called on the retired software tester and after much persuasion he reluctantly took the challenge.

He came to the company and started studying the application. Within an hour, he provided the exact steps to reproduce the problem and left. The bug was then fixed.

Later, the company received a bill for $50,000 from the software tester for his service. The company was stunned with the exorbitant bill for such a short duration of service and demanded an itemized accounting of his charges.

The software tester responded with the itemization:

• Bug Report: $1
• Knowing where to look: $49,999

Sandwich

Two software testers went into a diner and ordered two drinks. Then they produced sandwiches from their briefcases and started to eat. The owner became quite concerned and marched over and told them, “You cannot eat your own sandwiches in here!”

The testers looked at each other, shrugged their shoulders and then exchanged sandwiches.

Fuente: http://softwaretestingfundamentals.com/software-testing-jokes/ 

Descripcion de puesto - Software tester

Job description

As participants in the software development process, software testers help develop the test plan and evaluate the quality of software components. Their role is to detect major software flaws (e.g. bugs, errors, failures, breakdowns, risks) in order to fix them and ensure the performance of the developed systems. 

Specifically, testers analyze the context of software systems and apply testing types and levels (component, integration, system, and acceptance tests) to various software development models. They conduct static tests (based on detection, correction and improvement). Afterwards, they write an evaluation and incident report. 

Testers have a big responsibility; they inform the testing manager of all the improvements to be made. The work of an entire team of software designers and developers depends on their analysis. They play an increasingly important role on project teams, as the quality process is becoming stricter.

Skills 

• Education: College diploma (DEC in Quebec) in computers, bachelor’s degree in
        computers, software design or any other computer application development specialty 

• Master general principles and software testing methods 

• Thorough knowledge of software development concepts 

• Knowledge of functional and structural testing design techniques

• Be familiar with the various software development models, including V-development and iterative models and be able to conduct tests as part of a lifecycle model

• International Software Testing Qualifications Board (IST QB) Foundation level certification* 

• Differentiate between the developer’s and tester’s mindset 

• Bilingualism, for Quebec professionals: excellent command of French and English, both
        spoken and written

* Information available from the Canadian Software Testing Board (CSTB)

Personal qualities

• Critical thinking skills

• Analytical skills and ability to see the big picture

• Organizational skills

• Sense of responsibility 

• Independent judgment

• Self-sufficiency, resourcefulness

• Aptitude for teamwork

Chistes sobre Testing -Parte 2

 Parte 1    Parte 2    Parte 3    Parte 4

Signs That You’re Dating A Tester

• Your love letters get returned to you marked up with red ink, highlighting your grammar and spelling mistakes.
• When you tell him that you won’t change something he has asked you to change, he’ll offer to allow you two other flaws in exchange for correcting this one.
• When you ask him how you look in a dress, he’ll actually tell you.
• When you give him the “It’s not you, it’s me” breakup line, he’ll agree with you and give the specifics.
• He won’t help you change a broken light bulb because his job is simply to report and not to fix.
• He’ll keep bringing up old problems that you’ve since resolved just to make sure that they’re truly gone.
• In the bedroom, he keeps “probing” the incorrect “inputs”.

Who Is Who

• A Project Manager is the one who thinks 9 women can deliver a baby in 1 month.
• An Onsite Coordinator is the one who thinks 1 woman can deliver 9 babies in 1 month.
• A Developer is the one who thinks it will take 18 months to deliver 1 baby.
• A Marketing Manager is the one who thinks he can deliver a baby even if no man and woman are available.
• A Client is the one who doesn’t know why he wants a baby.
• A Tester is the one who always tells his wife that this is not the right baby.

Programmer Responses

Some sample replies that you get from programmers when their programs do not work:

• “It works fine on MY computer”
• “It worked yesterday.”
• “It must be a hardware problem.”
• “What did you type in wrong to get it to crash?”
• “You must have the wrong version.”
• “Somebody must have changed my code.”
• “Why do you want to do it that way?”
• “I thought I fixed that.”

Assessment Of An Opera

A CEO of a software company was given a ticket for an opera. Since he was unable to go, he passed the invitation to the company’s Quality Assurance Manager.

The next morning, the CEO asked him how he enjoyed it, and he was handed a report, which read as follows:

For a considerable period, the oboe players had nothing to do. Their number should be reduced, and their work spread over the whole orchestra, thus avoiding peaks of inactivity. All twelve violins were playing identical notes. This seems unnecessary duplication, and the staff of this section should be drastically cut. If a large volume of sound is really required, this could be obtained through the use of an amplifier. Much effort was involved in playing the demi-semiquavers. This seems an excessive refinement, and it is recommended that all notes be rounded up to the nearest semiquaver. No useful purpose is served by repeating with horns the passage that has already been handled by the strings. If all such redundant passages were eliminated, the concert could be reduced from two hours to twenty minutes.

 Fuente: http://softwaretestingfundamentals.com/software-testing-jokes/

Ejemplo de escenario de pruebas

Example for writing of test scenario?

EX:Login page

In login page you have to give values for user name,

password and then click on ok button to login and cancel

button to close the login window

user name:Alphanumerics with 4-16characters long

password:lowercase letters with 4-8 chars long

OK :Next window

CANCEL :Close the window

Prepare Test Scenarios

Test Scenario Template

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

Test scenario1:Verify user name value

Test Scenario2:verify pass word value

Test Scenario3:verify OK button operation to login

Test Scenario4:verify cancel button operation to close the

window

Ts1:Verify user name value

a)Boundary value analysis (on Size)

min=4characters

maximum=16 characters

more than max or less than min are not allowed

b)Equivalence class partitions(on type)

A-Z or a-z or 0-9 are valid types to be entered

special symbols or blank fields are in valid

Test Scenario2:verify pass word value

SAME AS USER NAME

Test Scenario3:verify OK button operation to login

Decision table

user name ------pass word-----expected outcome after click

on "OK"

valid valid next window

valid invalid error message

invalid valid error message

blank value error message

value blank error message

Test Scenario4:verify cancel button operation to close the

Decision table

user name ------pass word-----expected outcome

blank blank close the window

value blank close the window

blank value close the window

value value close the window

Like the above example we will write test scenarios for all

the Functional Specifications.

Fuente: http://ssoftwaretesting.blogspot.mx/2010/07/example-for-writing-of-test-scenario.html

Casos de prueba para Pruebas Unitarias

¿Cuáles casos de prueba se deben realizar para las pruebas unitarias?

Estos son los casos de prueba obligatorios a realizar cuándo se están realizando Pruebas Unitarias

• Casos de prueba positivos.
  Entradas correctas, salidas correctas.
• Casos de prueba negativos.
  Datos incompletos o faltantes, manejo adecuado.
• Casos de prueba de excepción.
  Excepciones que son lanzadas y atrapadas apropiadamente.

Fuente: http://ssoftwaretesting.blogspot.mx/2010/07/what-are-three-test-cases-you-should-go.html

¿Cuál es la diferencia entre pruebas de humo y pruebas funcionales?

Smoke testing is done to make sure the application is testable, ie., its basic and critical features are working fine, here it is tested for only positive(correct) values and not for negative values. we don't take much time to do smoke testing. It is done bcos if we find the same bugs at a later point of time it will lead to lot of rework.

But in functional testing we test the functionality of all the features against the requirement thoroughly.

Fuente: http://ssoftwaretesting.blogspot.mx/2010/07/what-is-diff-between-smoke-testing-and.html

Pruebas de Integración

La prueba de integración se realiza posteriormente a las pruebas de unidad y su foco de atención es el diseño y la construcción de la arquitectura del software. 

Después de la integración viene la validación y por último la prueba del sistema, ésta última consiste en probar el software junto con los otros elementos de la empresa o entidad, como la gente, departamentos, la base de datos.

Las pruebas de integración pueden ser descendentes o ascendentes o en sandwich, pero estas tienen sentido con ese nombre en los sistemas hechos en lenguajes estructurados, en los que el diagrama de la estructura de módulos del sistema permite definir un tipo dado de integración.
 En los orientados a objeto, otra vez cobra importancia el concepto de caso de uso, pues éste guía a la prueba en cuanto a los requisitos que deben satisfacer un determinado número de clases de programación que tienen que interactuar entre sí gobernadas por alguna clase de control del caso de uso.

Pruebas de validación

Pruebas de validación

 

La validación se logra cuando el software funciona de acuerdo a las expectativas del cliente.

La validación seconsigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que negociar con el cliente un método para resolverlas.

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entrono controlado.

La prueba beta se lleva a cabo en uno o más lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no está presente. 
La prueba beta es una aplicación "en vivo" del software en un entrono que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. 
Como resultado, el equipo de desarrollo lleva a cabo modificaciones y así prepara una versión del producto para toda la base de clientes.

Pasos básicos de Testing Funcional

I was having a chat with my friend who is a beginner in testing. He was sharing his problem with me on how to initiate testing. Although there are many books and articles on theories and concepts of testing but there is no help or information available on how to start testing and how a tester should proceed with the same. I thought of penning down my experience and sharing with all about my style on how to start testing. There are no specific norms but based on my experience while working on various projects I have listed down items which I have been doing while performing functional testing.

During the project initiation, when "Business Requirement Document" or "Software Requirement Document" or "Functional Specifications" are defined at that stage, tester should be involved to understand the background of the project. This also helps tester in getting first-hand information about user needs, their pain areas and expectations from the system which is yet to be developed.

While the project is in second stage of the cycle, which is Development Stage, Test Plans should be prepared. This helps tester in analyzing the requirements from testing aspect such as Test Case preparation based on features to be tested, Test Data requirements, defining defect priority and severity norms.

The Test plan comprises of schedule and timeline for test case writing and execution, entry and exit criteria for testing, number of regression test cycles to be performed and test cases to be executed in each cycle. Test plan also defines the status reporting template and frequency for the same.

After preparation of test plans, we should not rush to writing test cases but we need to analyze the needs of the system apart from functional requirements of the system. We need to identify test scenarios, covering alternate flows, boundary values and business rules/validation needs for writing test cases.  During our testing, we need to ensure that our testing is also covering those requirements as well. One example of such requirements could be browsers to be supported by the web application. Further, we need to prioritize Test Scenarios based on user needs and business criticality. This helps in focusing the critical areas of application and helps in performing comprehensive testing.

The test cases provide details about steps to be performed during testing. Usually every test case comprises of information about steps to be performed, data to be consumed, expected and actual results. The test cases are written to perform testing for both negative and positive scenarios. While positive test scenario related test cases helps the tester to find obvious defects, similarly negative test scenario related test cases help the tester to find defects and behavior of software/application under abnormal circumstances. This helps in checking the failure conditions and how error handling is performed in the application.

To provide full coverage of testing we can maintain traceability matrix of use cases or requirements with test cases. This helps us to ensure that all the requirements are covered while writing test cases.

Once we have written test cases, we will execute the test cases as per test plan defined earlier. While executing test cases, we will compare the actual results with expected results. In case of any discrepancy between actual output and expected output, we need to log it as a defect. The priority and severity of the defect is defined and are reported to Development team.

Further, as a practice you should maintain test results for each test case for every cycle of testing performed. We need to ensure that new code drop is not causing any defect to reopen during development cycles.

After defects are reported to development team, development team will deploy code after fixing the defects. Next step will be to perform regression testing. Regression testing will be based on executing the test scenarios with high priority and related to areas where code changes have been done by development team.

During the last and final stage of testing we need to ensure that all test cases are executed and there are no defects found in the verification. You can use automation testing, specifically for the areas of application, which are stable and will undergo minimum changes. This will help in keeping maintenance effort for the automation suite to minimum and will help in reducing manual testing effort by providing testing coverage for the critical areas. My general approach is always to re-run the test cases against which defects are detected, and the test cases associated with the related areas of application. This helps in detecting defects, which could have been injected by the developer in the code while fixing the reported defect.  In case of 100% success, all the defects are closed, and testing report is submitted. However, in case any of the defects is re-opened or new defects are logged then the above-mentioned steps are executed again after the development team deploys fresh code.

These are the steps which are usually followed under normal circumstances for performing functional testing. However, in certain projects, testers are supposed to perform functional testing under following scenarios:

Incomplete requirement documentation or no business requirements defined.
Testing is initiated after the project is developed.
Time allocated for testing is too short to perform thorough testing of the software.
The approach for functional testing will be different in all the above stated cases. Let’s discuss each scenario and approach tester should follow in each case:

1. Due to lack of functional or business requirements, it is very difficult for us to write test cases or define test scenarios. It is always recommended that in such cases tester should communicate with the business users and developers to define valid test scenarios. The tester should then envision features and functionality of software being developed and create a scenario based on the same. Tester should get these test scenarios validated by Users and developers. Based on signed off scenarios Tester should create test cases. The execution cycle in this scenario will remain same as explained above.

2. The second case is relatively simple, since the software has been developed, then the test time in the test plan is even easier to arrange, more conducive to the implementation. The base for writing test cases should be mixed of functional specifications and the actual software. This helps in ensuring that developers have not misinterpreted any requirement or if the development team has missed out implementation of any requirement.

3. For third scenario, we can perform risk based assessment of the application. With the help of business users, we will define the most critical areas of the application from the business aspect. Similarly, after coordinating with Development team, we will define the most complicated areas of the application from development perspective. Our test scenarios and test cases will focus on these two aspects and cover the areas defined under both the scenarios. If you have experience in testing, then you can further save time by not writing the test cases and performing testing in accordance to test scenarios identified. The reporting hence will comprise of only the test scenarios covered, and defects found.

In case you are stuck with the projects with no requirements, tight timeline and no experience in similar testing then you need to burn overnight fuel to prepare for it.

These are the personal opinions which I have for software functional testing. Certain aspects may differ from case to case basis, for example, in case of project following agile methodology for development then the approach for Agile testing will be different than stated above. This article is for your reference only on how to initiate testing and move forward with test plans, test cases and test reports.

Fuente: http://softwareqatestings.com/introduction-to-software-testing/basic-steps-of-functional-testing.html

Métricas de Pruebas de Software

What are two types of Metrics ?
Explanation :- Metircs are used in order to track and measure the entire testing process. These test metircs are collected at each phase of the testing life cycle/SDLC and analyzed and apropriate process improvements are determined and implemented as a result of these test metrics that are constantly collected and evaluated as a parallel activity together with testing both for manual and automated testing irrespective type of application

Broadly Classified into 3 categories:

Project Related Metircs : Such as Test size, Number of Test Cases created per day, Number of Test Cases Tested per day for both Manual and Automation , Total number of Review defects (RD) ,Total number of Testing defects (TD), etc...

Process Related Metrics :- Such as Schedule variance , Effort Variance ,Review Defects.

Schedule Variance =
Actual No. of days - Planned No. of days
--------------------------------------- * 100
Planned No. of days

Data source is would be from ur project plan...

Effort Variance =

Actual Effort - Planned Effort
--------------------------------------- * 100
Planned Effort

Data source is would be from ur project plan....

Review Defects =

Total Number of Defects found during review
------------------------------------------- * 100
Size ( No of pages )

Data source is would be Review Records.

Customer Related Metircs:- :- Such as Percentage of defects leaked per release ,Percentage of automation per release per release , Application Stability Index etc.

Fuente: http://ssoftwaretesting.blogspot.mx/2010/08/what-are-two-types-of-metrics.html

¿Cuál es la diferencia entre prueba de regresión y re-testing?

This is one of the mostly commonly asked question in any software testing interview. In this article I will explain what is the difference between regression testing and retesting.

Regression Testing is the execution of all or a select group of test cases that have passed on the earlier build or release of the application under test so that you can validate, the original functions and features are still working as they were in the past.
The test cases we use are derived from the functional specification, the user manuals, user tutorials, and defect reports in relation to corrected problems.

First regression test should be done using functional test cases to make sure no new defect has been introduced. In addition, we repeat some of the tests using a performance tool, to see how a new version handles, with regards to time and memory usage.

In most of the organization, the regression testing is incremental. So as we add new functionality, or correct a defect, we add test cases, which are included in subsequent rounds of regression testing.

In addition to new software releases at our end, we repeat the tests when MS introduces a new service pack, and to check ongoing compatibility for supported legacy operating systems.

As you can probably see from the above, automation is the key for regression testing. If you haven't gone down the automation route yet, regression testing is a good time to consider it. Manual regression testing tends to get more expensive with each new release.

Some of the possible failure of a regression test could be due to new functionality, changes in other applications or hardware that interfaces to your app. or even changes in the environment, like updated browser, security updates, or maybe a change in the screen controls.

Retesting is the execution of one or a set of test cases, which previously failed due to a suspected defect in the software which now is documented as being remedied.
However, the fix may introduce fault elsewhere in the software. The way to detect these "unexpected side effects" of fixes is to do regression testing as mentioned above.

So on the conclusion, in retesting we need to check the defects that have been logged by the tester and fixed by the developer. We need to test if that particular bug has been fixed but in regression testing, we need to check if that has been fixed or not and also make sure that change in code by the developer to fix that particular bug has not left any impact on any other phase of application. So regression testing is a kind of testing the whole scenario after fixation of every bug.

Fuente: http://softwareqatestings.com/introduction-to-software-testing/what-is-the-difference-between-regression-testing-vs-retest.html

Técnica de Particion Equivalente - Pruebas de Caja Negra

Una partición equivalente es una técnica de prueba de Caja Negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
El diseño de estos casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.

Regularmente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.

Si una entrada es booleana, hay 2 clases: si o no.

Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.

Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor número de atributos de cada clase de equivalencia a la vez.

Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:

• Primero se deben identificar las clases de equivalencia lo cual se hace tomandocada condición de entrada y aplicándole las directrices antes expuestas.

Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condición de entrada especifica un rango, entonces se confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición de entrada especifica la cantidad de valores, identificar una clase de equivalencia válida y dos inválidas.
Si una condición de entrada especifica un conjunto de valores de entrada y existen razones para creer que el programa trata en forma diferente a cada uno de ellos, identificar una clase válida para cada uno de ellos y una clase inválida.
Si una condición de entrada especifica una situación de tipo “debe ser”, identificar una clase válida y una inválida.
Si existe una razón para creer que el programa no trata de forma idéntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.

• Luego de tener las clases válidas e inválidas definidas, se procede a definir los casos de pruebas, pero para ello antes se debe haber asignado un identificador único a cada clase de equivalencia.

• Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:

1. Escribir un nuevo caso de cubra tantas clases de equivalencia válidas no cubiertas como sea posible hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba.
2. Escribir un nuevo caso de prueba que cubra una y solo una clase de equivalencia inválida hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de pruebas.

Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el programa está llevando a cabo una prueba.

Aplicando el diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número de errores antes de que comiencen las “pruebas del cliente”. 

Como ejemplo, consideremos los datos contenidos en una aplicación de automatización bancaria. Este software acepta datos en la siguiente forma:
Código de área: En blanco ó un número de 3 dígitos
Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Sufijo: Número de 4 dígitos
Contraseña: Vvalor alfanumérico de 6 dígitos
Ordenes: "Comprobar", "Depositar","Pagar factura", etc.

Las condiciones de entrada relacionadas con cada elemento de la aplicación bancaria se pueden especificar como:
Código de área: Condición de entrada lógica - el código de área puede estar o no presente
Condición de entrada rango - valores definidos entre 200 y 999
Prefijo: Condición de entrada rango - valor especificado > 200
Sufijo: Condición de entrada valor- longitud de 4 dígitos
Contraseña: Condición de entrada lógica - la palabra clave puede estar o no presente
Condición de entrada valor - cadena de seis caracteres
Orden: Condición de entrada conjunto, contenida en las órdenes listadas anteriormente.

Los casos de prueba se seleccionan de manera que se ejercite el mayor número de atributos de cada clase de equivalencia a la vez.