QA (Qualitty Assusrance) y Testing

Un tema recurrente en los distintos ambientes/áreas de las empresas (en el área de testing también)  y hasta en la red es confundir estos dos términos y hablar de los mismos de manera indiferente interpretando a ambos como si fueran sinónimos, lo cual es incorrecto.

Definición (Según ANSI/IEEE)

Testing:
Es el proceso de ejecución de un sistema con la intención de encontrar defectos, incluyendo la planificación de las pruebas previo a la ejecución de los casos de prueba.

Testing  = “Control de Calidad”

Control de Calidad:
Es el conjunto de actividades destinadas a evaluar el trabajo para el desarrollo de un producto.

Control de Calidad  =  “Medición de la calidad de un producto”

Quality Assurance:
Es el conjunto de actividades encaminadas a lograr que el desarrollo y / o proceso de mantenimiento es adecuado para garantizar que el sistema cumplirá con sus objetivos.

QA      =    “Medición de la calidad de los procesos utilizados para crear un producto de calidad”

La diferencia clave es recordar que:

Las tareas de QA están interesadas en el proceso de desarrollo del producto, mientras que testing y el control de calidad están interesados en el desarrollo del producto en si mismo.

Profundizando los conceptos

Testing es una función del Control de Calidad. Pero, ¿Qué es el Control de Calidad? El Control de Calidad incluye cualquier actividad que examina los productos para determinar si cumplen con sus especificaciones. No sólo testing es una actividad del Control de Calidad, también lo son los tutoriales, comentarios, o inspecciones de los productos de trabajo como los requisitos, diseños, códigos y documentos. El objetivo del Control de Calidad es:

La detección de fallas mediante la inspección y la experimentación del producto

Pero entonces, ¿Cuando realizamos actividades de QA? QA incluye cualquier actividad que se centra en garantizar que los niveles necesarios de calidad se han logrado como la identificación de problemas, así se pueden tomar medidas en el futuro para evitar esos mismos problemas. Se incluye la ingeniería de los procesos que son utilizados por el equipo (analistas, desarrolladores, Testers) para que los productos de alta calidad se puedan construir de manera eficiente. El objetivo de QA es:

Prevención de fallas mediante la inspección y prueba del proceso

¿Como lleva a cabo en QC la inspección y experimentación del producto?
A medida que se generan los artefactos, estos pueden ser objeto de inspección (por ej, sobre la marcha como en la programación en parejas) y/o probado (por ej, con las pruebas unitarias). El término “Control de Calidad” proviene de industrias más maduras que descartan un producto o corrigen sus defectos (si es posible) si no cumple con ciertas pruebas, en el caso del Software, en realidad no es “Control”, porque lo único que hace es proporcionar información,  la información que luego facilita la toma de decisiones (go or no go). En algunas industrias, estas decisiones son más fáciles de determinar a partir de los resultados de las pruebas, pero todos sabemos que esto no es siempre es tan claro con el software.
¿Como lleva a cabo en QA la inspección y prueba del proceso?
Es posible inspeccionar el proceso mediante una auditoría de que está haciendo la gente y asegurarse de que están dentro de las directrices, marcos o siguiendo los procesos estipulados. También, asegurándose de que, cuando se realizan acciones, los beneficios y los riesgos se han tenido en cuenta. Un ejemplo de prueba del proceso es plantar errores para verificar que tan eficientes son los procesos de testing en detectar el mismo.

http://josepablosarco.wordpress.com/2010/04/13/testing-vs-qa/

Learning To Learn (About Testing)

It is not every day that I find myself playing billards with some of the best thinkers in software testing.
Still, there I was, in Westlake, Ohio, at the Marriott Residence Inn, the day before the conference. We had a pool table, and five people - David Hoppe, Justin Rohrman, Peter Schrijver, and Erik Davis.
The next day we were set to discuss skills in software testing, so we set down to play a game or two.
Except, of course, my brain doesn't work like that -- I immediately began to think about skills in pool.
Growing Your Billiard Skills
First we spent an hour or so "just paying pool." Rack the balls, hit them with the cue ball, and on we go.
Most of us had never studied the game seriously. We could generally make the trivial shot, where you "just" want the ball to go straight. Periodicaly, though, we found ourselves trying to make a complex shot -- hitting he cue ball at just the right point so that when it hit the ball, the ball in play would move at a different angle.
This is, well, hard. We got it wrong a lot.
After an hour of playing, I noticed something: We weren't getting any better.
Each complex shot was very different than the shots before, which left us with no point of reference, no muscle memory to improve.
Building Muscle Memory
In traditional sports, the way to learn is to do the same activity over and over again. Serving in Volleyball, making shots in basketball, or hitting the ball in billiards - you set up the same complex shot, and do it over and over again until it is repeatable -- and you know why. Then, in the heat of the game, your body says "oh, this is kind of like that other thing I did a million times" and you don't think but react.
I'm oversimplifying a bit here; this is a blog post, not a book. The point is that repeat performance (practice) builds skill in most human domains.
Even in programming we have the idea of the Kata, of doing the same exercise again and again, discovering different ways to write the code, until it becomes familiar.
"Test Katas", on the other hand, make a lot less sense. You find where the bug is the first time, and on the second run through, finding it is going to be really easy. We talk about simulating a real project, where you get multiple "Builds" to test, to create a more realistic (and practice-able) kata -- but i haven't seen one yet, and I read about testing, well ... a lot.
In fact, if you go to a typical test conference, it is possible to go entire days without seeing any sort of realistic exercise, as simple as "here's a UI - how would you test it?"
Depending on the angle you look at the seem more obsessed with new and shiny, with automating the process, or measuring it, or talking about sidebar issues (hiring, firing, project management) than in the doing of the testing. The examples we do have tend to be trivial: "A triangle has three inputs ..." When they aren't trivial, we tend to focus on the technque ("equivilance class partitioning!") more than the skills.
The implication seems to be that coming up with test ideas is easy -- and as far as confirmatory testing, that may be true. Take a spec, turn it sideways, and every "the system shall ..." turns into a test idea.
That's also a weak and shallow form of testing.
Creating exercises that teach real skill is hard. Kaner, Hoffman, and Padmanahban where working on their Domain Testing Workbook for something close to a decade. At four-hundred and sixty-three letter-sized pages, the book is intimidating to even the most serious student of testing.
I am convinced that skill development is what we need.
Katas in testing are what we need.
We don't need lectures; we need thoughtful practice that ties in to our everyday work.
I've done a little bit of this; Parkcalc, a test exercise I developed, now yeidls 892 hits on google, and the Miagido School has its own web page too.
Still, as 2013 winds down, I can't help but think that we've got a long way to go.
Right now, as of December 16, 2013, I am in a position where I can choose my shot for next year, and have a little time to focus on it. My biggest interest is skills in testing, real skills in testing. As the editor of Stickyminds.com, I will be looking to publish articles that talk about it, but I'll be writing more than a few myself, speaking about it in public and private. The assignments I'll be looking for will be those that allow me to practice skills while studying and documenting them.

http://www.stickyminds.com/blog/matt-heusser/learning-learn-about-testing

Some interesting Software testing interview questions

1. In an application currently in production, one module of code is being modified. Is it necessary to re-test the whole application or is it enough to just test functionality associated with that module?
Vijay: Well, the answer is both. You will have to test the functionality of that module as well as the other modules. But you can differentiate on the stress to be given on the module to be tested.
I think this scenario will explain the answer to your question well.
If Module A is modified, Module B is depending on module A, and Module C is a general module independent of module A.
So in this case you will test the module A in depth to all test cases. Then your next stress will be on module B. Wait now what about module C? You will have to test this module as well but may be with less stress because module C is not depend on module A but may be depend on module B.
Again if you are a white box tester you probably know which modules will get affected and which modules should be tested. But as a black box tester you will need to do regression testing as well.
2. What is the most challenging situation you had during testing?
Vijay: A good question! When I switched my job some years back I was being asked the same question.
Well a good answer to this question is depends on each ones experience. If you came across any such a situation and found any interesting Bug that was difficult to find out or analyzed any project risk accurately before occurring then this could be the answer to this question.
Keep in mind that when answering such a question, be realistic and don’t overstress the situation.
3. What are you going to do if there is no Functional Spec or any documents related to the system and developer who wrote the code does not work in the company anymore, but you have system and need to test?
Vijay: A typical situation in Indian companies! Right? Due to high attrition rate
In this case fist you will need to do the exploratory testing of the product. In this testing you will come to know the system and its basic workflow. In exploratory testing you can also find some ‘blocker’ bugs that cause system to be crash.

If you are a white box tester then next step you can do is to see the different module code. By this you will know the test cases for different modules and relation of modules.

http://www.softwaretestinghelp.com/some-interesting-software-testing-interview-questions/

Good Idea! Now What?

Summary:

A good idea is a valuable asset, and a lot of good ideas can be like a treasure trove. But what do you do with those ideas? Here, Esther Derby describes an idea maker who isn't very good at following through and then suggests four important things to remember to keep your own ideas from withering on the vine.

Ron was full of ideas. Good ones, too—or at least he thought so. He had ideas about how team members should organize their work, how to report status, how to speed up the build, and a way to save money on white board markers, to name a few.
But, Ron's teammates hadn't picked up on his wonderful ideas. In fact, to Ron's eyes, they had rejected them out of hand. So, he persisted, arguing why his ideas were a better way.
Eventually, another developer agreed to try Ron's idea for speeding up the build and asked Ron to work on it with him. Ron refused. "I don't want to get saddled with the extra work," he huffed. "That's like punishing me for having good ideas." The other developer quickly lost interest.
Many ideas wither, not because they are bad ideas, but because of clumsy presentation. Few people are as inept as Ron; but most nascent ideas stand a better chance if you remember these four things:
1. It's not about you.
Most of the time, people pursue a new idea because they can see how it will help them. Don't just tell them why you think your idea is a good one. See the world from their point of view, and frame the idea in terms of what matters to them. If your manager cares only about cost, then talking about quality, speed, reuse, or elegance won't convince him to try your idea. Connect your idea with what's important to the people you are hoping to influence.
2. It is about who you know.
Bringing your ideas to fruition is a social process. You will need the aid and interest of others to make your idea reality.
Take stock of your network. Who can help you move the idea forward? Who has influence with people who might champion the idea? What do the people who hold formal and informal power care about? Can your idea help them advance their goals?
3. Action creates attraction.
Rather than pushing your ideas on people, try pulling them in—work by attraction. If you think a team task board would help everyone do better, show them; don't just tell them. Demonstrate the benefits by creating your own task board and making your progress visible. The time to tell is when someone shows curiosity, not before.
There's another benefit of showing: You might learn something useful about the how the organization will respond to your idea. Suppose you make your own kanban board and start limiting your own work in process. If your manager increases his scrutiny of your work or berates you for not working hard enough, you've obtained valuable information—information that will help you move your idea forward (or choose not to move it forward and look for a new manager, instead).
4. Timing is everything.
Your idea might be good but not viable in this organization at this particular time. An experiment—such as the personal kanban board—can reveal what else needs to change for your idea to succeed.
Sometimes people and groups aren't ready for an idea. They may not have the prerequisite knowledge to appreciate it, or they may be working from a different mental model in which there's no place for your idea to fit. In this case, you need to prepare the ground with conversations (sometimes many) before planting the seed of your idea.

When you are brand new to a group, you may see many opportunities for improvement. But, ideas from an outsider can feel like implied criticism. After all, how could an outsider understand the tribulations the team is facing? Show you understand by offering an idea to solve something the group views as a problem, not something you see as a problem. Once the team sees that you can solve their problems, they'll be more likely to listen to your other ideas.
Sometimes a great idea comes a few seconds too late. When a team has too many ideas, they may feel overwhelmed. Or, as team members chase each shiny, new idea, those ideas may not stick. When the team is close to a decision and a new idea enters the mix, the team goes back into analysis, examining the new idea.
You may have an even better idea, but sometimes it's best to hold that for the next round and get on with implementing "good enough."
Ron continued to generate ideas—ideas that usually involved more work for other people, and no ownership on his part. His teammates continued to ignore his ideas until one day someone told him to just shut up. So, if you want to stay out of the Ron trap, remember these four points—it's not about you, it is about who you know, action creates attraction, and timing is everything. I can't guarantee that all your excellent ideas will come to fruition, but many will. And you'll been seen as someone who knows how to make things happen.

http://www.stickyminds.com/article/good-idea-now-what

Software testing interview questions Test manager

Q Customer has reported severe defects in Daily balance report. The customer
is unhappy that the problem is not fixed even after a week. What action you
as a PM will take to restore confidence of customer and ensure that this will
not happen in suture?
Answer:
Conflict resolution – Get on your customer wavelength. Get the facts and ask
questions, get detail info and take notes listen carefully. Establish and initiate an
action program(admit error if it is there, negotiate satisfactory solution, state the
solution and get agreement, take action and follow up with customer). Finally
establish proper daily problem review process to prevent such problems in future.
Q. It’s observed that the testers in your organization are performing tests on the
deliverable even after significant defects have been found. This has resulted
in unnecessary testing of little value because re-testing needs to be done
after defects have been rectified. You are the test manager and going to
update the test plan with recommendations on when to stop testing. List the
recommendations you are going to make.
Answer:
Following steps need to be taken .
a) Acceptance criteria should tighten
b) Test cases should be re-evaluated (preferably peer review)
c) If possible more test cases should be added. With boundary value and
equivalence class partition cases.
d) More test cases with invalid condition should be added
e) Stop criteria needs to be modified
Q. You are newly appointed as a test lead in an organization which uses manual
testing. Your boss wants you to put forth three testing tools and their features
to create awareness about the testing tools in the top management. Suggest
any three testing tools for your test Environment and why do you suggest
them?
Answer:The third question is very important one. You can write about test Director, Win
runner/Load runner, McCable or any other coverage tool. Test director is useful to
track defect. WR or LR to do functionality/Load testing, Coverage tool to check the
code coverage thereby helping in White box testing.

Q. You are working on a project, where the requirements change dynamically.
The data in the project comes from various ends (from various Platforms) and
are inter-dependent. You see this as a big risk in the project. How would you
plan accordingly?
Answer:
Give a Plan which takes care of the risk and is identified in the Risk Areas. Say that
the testing scope would concentrate more on Data driven tests etc.

http://www.softwaretestinghelp.com/software-testing-interview-questions-test-manager-part-i/

Compartiendo conocimientos en el equipo

Sumario -> El siguiente artículo ha sido escrito por uno de los miembros de este blog: Diego Alves, quien trabaja como ‘Analista de teste de software’ en São Paulo – Brazil, exponiendo aquí las experiencias que va viviendo como tester dentro de un grupo ágil con un lenguaje muy amigable y entendible.

Detalle -> Cuando empecé a trabajar con pruebas de software, una cosa que siempre me dejó confundido, es la cantidad de ramificaciones que permite la profesión. Esto es algo bueno, pero también es una pesadilla para un novato en QA.

Por lo general, nos especializamos en una o algunas técnicas, como por ejemplo: automatización, seguridad, pruebas de desempeño y otros.

No conozco personas con alto conocimiento en todas las técnicas. Pero, es muy importante por lo menos conocer y entender los conceptos (básicos) que se aplican, qué herramientas se pueden utilizar y en qué momento se utiliza en la batería de pruebas.

La gran dificultad es, cómo aprender los conceptos básicos de todo, como familiarizarse con situaciones nunca antes vistas.

Sé que hay muchos blogs en Internet, con tutoriales, teorías, herramientas y otros. Pero, ¿Quién no quisiera tener a alguien que lo guíe, que lo ayude a responder algunas preguntas, alguien que uno conozca, que sepa dónde pueden estar los problemas y nos pueda ayudar?

En la equipo que estoy actualmente, hay compañeros con un alto nivel de conocimientos en muchas áreas diferentes, pensando en tomar ventaja de esto, cada 15 días, un miembro del equipo realiza una capacitación que puede ser sobre cualquier tema.

Hemos recibido capacitación en el análisis de riesgos, TDD, pruebas exploratorias y pruebas de desempeño.

En el caso de la formación en pruebas exploratorias, había un pequeño dojo entre los miembros del equipo, dirigido por Sarah Pimentel. Fue muy productivo, tanto para los nuevos miembros del equipo, como para aquellos que tienen una gran cantidad de tiempo en esta área.

Pero, la propuesta va más allá de sólo hablar de técnicas de pruebas, también queremos, hacer capacitaciones en los productos propios desarrollados en la empresa, en otras palabras, los que saben muchas reglas de negocio y el funcionamiento de un producto en particular, harían un entrenamiento enseñando cómo utilizar la herramienta, mostrando los puntos principales, qué funciones son las más utilizadas, cuál es la mayor fuente del problema, y así sucesivamente.

También pensamos en formaciones vinculadas con metodología ágil. La primera fue la formación en “retrospectivas”, una ceremonia muy importante para el equipo, fue impresionante como puede ser que haya una herramienta tan útil para diversas situaciones y cuán adaptativa puede ser.

Es exactamente acerca de este entrenamiento, dirigido otra vez por Sarah, que tengo la intención de escribir, y traer una idea de lo que es ‘Retrospectiva’ y los diversos métodos para lograrla.

Esta forma de compartir el conocimiento dentro del equipo, es muy efectiva, motiva a todos a estudiar más cosas, para ser capaz de seguir avanzando, todos aprenden continuamente y siempre son puntos de referencia para responder preguntas y mostrar nuevas herramientas.

http://testingbaires.com/compartiendo-conocimientos-en-el-equipo-2/

Some tricky question answers

1. Define the following along with examples
a. Boundary Value testing
b. Equivalence testing
c. Error Guessing
d. Desk checking
e. Control Flow analysis
Answer:
1-a) Boundary value Analysis: -
A process of selecting test cases/data by
identifying the boundaries that separate valid and invalid conditions. Tests are
constructed to test the inside and outside edges of these boundaries, in addition to
the actual boundary points. or A selection technique in which test data are chosen to
lie along “boundaries” of the input domain [or output range] classes, data structures,
procedure parameters, etc. Choices often include maximum, minimum, and trivial
values or parameters.
E.g. – Input data 1 to 10 (boundary value)
Test input data 0, 1, 2 to 9, 10, 11
1-b) Equivalence testing: -
The input domain of the system is partitioned into classes
of representative values, so that the no of test cases can be limited to one-per-class,
which represents the minimum no. of test cases that must be executed.
E.g.- valid data range: 1-10
Test set:-2; 5; 14
1-c) Error guessing: -
Test data selection technique. The selection criterion is to pick
values that seem likely to cause errors Error guessing is based mostly upon
experience, with some assistance from other techniques such as boundary value
analysis. Based on experience, the test designer guesses the types of errors that
could occur in a particular type of software and designs test cases to uncover them.
E.g. – For example, if any type of resource is allocated dynamically, a good place to
look for errors is in the de-allocation of resources. Are all resources correctly deallocated,
or are some lost as the software executes?
1-d) Desk checking: -
Desk checking is conducted by the developer of the system or
program. The process involves reviewing the complete product to ensure that it is
structurally sound and that the standards and requirements have been met. This is
the most traditional means for analyzing a system or program.

1-e) Control Flow Analysis: -
It is based upon graphical representation of the
program process. In control flow analysis; the program graphs has nodes which
represent a statement or segment possibly ending in an unresolved branch. The
graph illustrates the flow of program control from one segment to another as
illustrated through branches .the objective of control flow analysis is to determine
the potential problems in logic branches that might result in a loop condition or
improper processing .

http://www.softwaretestinghelp.com/some-tricky-question-answers/

Top 20 practical software testing tips you should read before testing any application.

I wish all testers read these software testing good practices. Read all points carefully and try to implement them in your day-to-day testing activities. This is what I expect from this article. If you don’t understand any testing practice, ask for more clarification in comments below. After all you will learn all these testing practices by experience. But then why not to learn all these things before making any mistake?
Here are some of the best testing practices I learned by experience:
1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.
2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.
3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.
4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.
5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.
6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.
7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.
8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.
9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.
10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.
11) Go beyond requirement testing. Test application for what it is not supposed to do.
12) While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.
13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.
14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.
15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.
16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.
17) Testing teams should share best testing practices, experience with other teams in their organization.
18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.
19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.
20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.
Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.

http://www.softwaretestinghelp.com/practical-software-testing-tips-to-test-any-application/

Combinación de testing sobre casos de prueba y testing exploratorio

Hay que ir más allá de los casos de prueba o de las fuentes que se tengan para poder realizar este tipo de testing: casos de uso, requisitos, historias de usuario, etc… porque resulta muy complicado que la documentación disponible cubra todas las casuísticas que se han desarrollado (aún cubriéndolas, que hayan descendido al nivel de detalle necesario en todos los casos) y porque una cosa son las especificaciones y otra los componentes software que se han desarrollado y su engranaje.
Lo ideal es la combinación de ambos tipos de testing (basado en casos de prueba y exploratorio) porque el testing exploratorio salvo que se tenga colaboración del equipo de proyecto o lo recursos del proyecto permitan conocer bien el negocio, no podrá corroborar de manera adecuada el funcionamiento del sistema.
El testing exploratorio básicamente consiste en realizar el testing con los recursos disponibles y en donde la habilidad, conocimientos y experiencia del tester o del equipo de testing resultan fundamentales para hacer un trabajo de calidad. Desde este punto de vista también cabría dentro de este testing la aplicación de los casos de prueba basado en documentación existente en el proyecto: “esta es la documentación que hay, tu te lo guisas y tu te lo comes”, si bien me gusta hacer una diferenciación entre un caso y otro ya que en uno hay una intención de hacer una documentación que pueda ser de utilidad para las pruebas (aunque no sea ese su propósito principal) y en el caso del testing exploratorio se basaría más en ir recopilando piezas (documentales, prototipos, consultas al equipo de desarrollo, etc…) y en el trabajo en profundidad con el producto.

http://jummp.wordpress.com/2012/10/30/combinacion-de-testing-sobre-casos-de-prueba-y-testing-exploratorio/?relatedposts_exclude=7928

Experiencia y Productividad de un Tester

Tester, Productividad, Experiencia

El siguiente debate se ha publicado en el grupo de discusión LinkedIn, TESTING & QA, con el objeto de discutir si existe relación entre los años de experiencia que puede llegar a tener un tester y su productividad.

• Existe relación entre cantidad de años y calidad de productos elaborados y forma de probar?
• Cuánto influye el conocimiento no técnico de un Tester en la productividad del testing?
• Buenos Testers pueden llegar a ser Grandes Testers, y malos Testers siempre serán malos Testers?
• Hay que deshacerse de los miembros improductivos ya que no tienen arreglo?
• Hay que tomar jóvenes testers porque son ‘más baratos’ y ‘maleables’?

Experiencia no se requiere!
Cuántas veces hemos visto en anuncios de ofertas laborales esta frase, cierto?
Entonces, es importante o nó contar con experiencia para ser Tester?
Se puede pretender que en poco tiempo el tester que ingresó haga buen testing?
Están confeccionando en su empresa por tipo de Tester, a modo de tener una base de conocimientos y sacar estadísticas, reportes de:
- tiempo insumido por análisis de requerimiento
- tiempo insumido por elaboración de orden de magnitud
- tiempo insumido por elaboración de estimación
- tiempo insumido por elaboración de plan de pruebas
- tiempo insumido por preparación de ambiente de pruebas
- tiempo insumido por diseño de casos de prueba
- tiempo insumido por ejecución de pruebas manuales
- tiempo insumido por ejecución de pruebas automatizadas
Estos son algunos de los items más generales a ser considerados…
Hay un estudio similar pero que aplica a desarrolladores (variaciones en la productividad programación individual), hecho a finales de 1960 por Sackman, Erikson, y Grant (1968). Este estudio se ha repetido al menos 8 veces desde aquella fecha y los resultados no han cambiado (base=programadores profesionales con una media de 7 años de experiencia):

• la relación entre el tiempo inicial de codificación era aproximadamente 20 a 1
• la relación de tiempos de depuración más de 25 a 1
• programa de velocidad de ejecución aproximadamente 10 a 1
• programa de tamaño de 5 a 1

No encontraron ninguna relación entre el número de un programador de años de experiencia y la calidad del código o la productividad.
Hubo fallas en el estudio, sin embargo, incluso teniendo en cuenta los defectos, sus datos todavía muestran más de un orden de magnitud de diferencia entre los mejores programadores y los peores, y esa diferencia no se relaciona con la experiencia.
Por otra parte, la tecnología es más sofisticada hoy en día y se podría pensar que sabemos mucho más sobre el desarrollo y prueba de software ya que después de todo hoy:
- tenemos mejores lenguajes de programación
- contamos con la tecnología más sofisticada
- tenemos una mejor investigación sobre patrones de software eficaces
- contamos con mejores metodologías de trabajo
- contamos con mas herramientas para la gestión del trabajo
Resulta que si bien todas estas cosas son ciertas, todavía existe una orden de magnitud por la diferencia entre el técnico y los años de experiencia.
Por lo tanto, hay otro factor que interviene en afectar estas variables, probablemente pueda llegar a ser la capacidad de planificar y tomar buenas decisiones.
Se podría aumentar la productividad del tester si se mejora en planificación y estimación del testing?
Algunos comentarios de miembros del grupo:
Eduardo Cervantes • Depende como se formo la persona. No necesariamente muchos años en el campo significa “experimentado”.
Javier Alejandro Santillán • Serían éstas métricas que mencionas, las que definirían la productividad de un tester?
tiempo insumido por análisis de requerimiento
tiempo insumido por elaboración de orden de magnitud
tiempo insumido por elaboración de estimación
tiempo insumido por elaboración de plan de pruebas
tiempo insumido por preparación de ambiente de pruebas
tiempo insumido por diseño de casos de prueba
tiempo insumido por ejecución de pruebas manuales
tiempo insumido por ejecución de pruebas automatizadas
Están seguros de querer colectar éste tipo de información y que ello sería útil de alguna manera?

http://testingbaires.com/debate-experiencia-y-productividad-de-un-tester/

Black Box Testing: Types and techniques of BBT

Software Testing Profesional.
I have covered what is White box Testing in previous article. Here I will concentrate on Black box testing. BBT advantages, disadvantages and and How Black box testing is performed i.e the black box testing techniques.
Black box testing treats the system as a “black-box”, so it doesn’t explicitly use Knowledge of the internal structure or code. Or in other words the Test engineer need not know the internal working of the “Black box” or application.
Main focus in black box testing is on functionality of the system as a whole. The term ‘behavioral testing’ is also used for black box testing and white box testing is also sometimes called ‘structural testing’. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn’t strictly forbidden, but it’s still discouraged.
Each testing method has its own advantages and disadvantages. There are some bugs that cannot be found using only black box or only white box. Majority of the applicationa are tested by black box testing method. We need to cover majority of test cases so that most of the bugs will get discovered by blackbox testing.
Black box testing occurs throughout the software development and Testing life cycle i.e in Unit, Integration, System, Acceptance and regression testing stages.
Tools used for Black Box testing:
Black box testing tools are mainly record and playback tools. These tools are used for regression testing that to check whether new build has created any bug in previous working application functionality. These record and playback tools records test cases in the form of some scripts like TSL, VB script, Java script, Perl.
Advantages of Black Box Testing
- Tester can be non-technical.
- Used to verify contradictions in actual system and the specifications.
- Test cases can be designed as soon as the functional specifications are complete
Disadvantages of Black Box Testing
- The test inputs needs to be from large sample space.
- It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
- Chances of having unidentified paths during this testing
Methods of Black box Testing:
Graph Based Testing Methods:
Each and every application is build up of some objects. All such objects are identified and graph is prepared. From this object graph each object relationship is identified and test cases written accordingly to discover the errors.
Error Guessing:
This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover all the application paths.
Boundary Value Analysis:
Many systems have tendency to fail on boundary. So testing boundry values of application is important. Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values.

Extends equivalence partitioning
Test both sides of each boundary
Look at output boundaries for test cases too
Test min, min-1, max, max+1, typical values
BVA techniques:
1. Number of variables
For n variables: BVA yields 4n + 1 test cases.
2. Kinds of ranges
Generalizing ranges depends on the nature or type of variables
Advantages of Boundary Value Analysis
1. Robustness Testing – Boundary Value Analysis plus values that go beyond the limits
2. Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1
3. Forces attention to exception handling
Limitations of Boundary Value Analysis
Boundary value testing is efficient only for variables of fixed values i.e boundary.
Equivalence Partitioning:
Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.
How is this partitioning performed while testing:
1. If an input condition specifies a range, one valid and one two invalid classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid class is defined.
Comparison Testing:
Different independent versions of same software are used to compare to each other for testing in this method.
Reference- http://www.softrel.org/stgb.html
http://www.softwaretestinghelp.com/black-box-testing/

Desarrollo de software. Ciclo de vida RUP (Rational Unified Process)

RUP es un marco de desarrollo, te indica una forma de enfocar un proyecto de desarrollo de software y después en función de la naturaleza del mismo haces las adaptaciones oportunas (sin salirte de las fronteras que te marca la metodología porque de lo contrario estaríamos hablando de algo que no sería RUP).
RUP sigue principios de ingeniería del software para la obtención de sistemas de información de calidad y de esta forma proporcionar una alternativa que permita evitar que los productos que se obtengan caigan en los aspectos que caracterizan a la crisis del software (todavía muy presente en nuestros días).
RUP sigue una estrategia de ciclo de vida iterativo e incremental, pero de una forma un tanto peculiar, como vamos a ver a continuación.
El ciclo de vida RUP se divide en 4 fases: Iniciación, Elaboración, Construcción y Transición.
En cada fase se realizan una o más iteraciones (con el objeto de ir perfeccionando los objetivos, mediante el feedback del usuario) y hasta que no finaliza una fase no se comienza con la siguiente. Por regla general, la fase en la que se realizan más iteraciones es la Contrucción.
En cada fase se refinan los objetivos de las fases anteriores en el proceso de conseguir el objetivo o objetivos de la fase, por ejemplo, en la fase de construcción se pueden modificar, añadir o eliminar requisitos, casos de uso, etc… lo que tiene un impacto en lo obtenido en fases anteriores, acercándonos cada vez más a un sistema que satisfaga las necesidades de los usuarios.
En cada fase y en cada iteración se realiza un ciclo de vida en cascada con las siguientes etapas: Análisis, Diseño, Construcción (las tareas de programación que se realizan, sobre todo las fases de Construcción y Transición son perfectamente compatibles con la utilización de técnicas de integración continua y análisis estático de código), Pruebas/Integración/Implantación. El alcance del ciclo de vida depende en la fase en la que nos encontremos, es decir, aunque se realice un ciclo de vida en cascada en la fase de Iniciación, lo más probable es que no se llegue a construir nada o se llegue a algún a hacer algún prototipo de muy alto nivel.
Los objetivos que se persiguen en cada fase son los siguientes:
- Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.
- Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.
- Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.
- Transición: Refinamiento de los objetivos de las fases anteriores e implantación del sistema de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).
Por tanto, como se comentó anteriormente, en cada etapa y en cada iteración se perfeccionan los productos previos que hayan requerido algún cambio, todo eso mientras se intentan conseguir los objetivos concretos de la fase. De esta forma el ciclo de vida RUP sigue un modelo adaptativo de desarrollo de software.
De esta forma, el reparto de esfuerzos entre actividades varían de una fase a otra.

Fuente del gráfico: Wikipedia.
Una característica importante del RUP es que todo el proceso está guiado por los casos de uso, algo que resulta lógico cuando hablamos de modelos incrementales, ya que están orientados al usuario y como tal es importante tener siempre presente el esquema de interacción usuarios/sistema, los cuales vienen definidos por los casos de uso y sus escenarios.
RUP pretende la obtención de productos de muy alta calidad (extendiéndose esta no solo al cumplimiento de las expectativas del usuario, sino a la obtención de productos con una deuda técnica aceptable), si bien sus características: varias fases, múltiples iteraciones por fases, pueden provocar que el proceso de desarrollo sea costoso y que no se adapte a proyectos de pequeña escala, aunque el hecho de que siga un esquema incremental permitiría dar flexibilidad en el caso de que fuera necesario.
Personalmente prefiero la aplicación de ciclos de vida iterativos incrementales de una forma más directa, sin aplicar múltiples iteraciones para liberar una nueva versión del producto, si bien el ciclo de vida RUP es muy potente y sigue la misma estrategia, es decir, aproximarse al proceso real de desarrollo de software en el cual el producto va creciendo conforme los usuarios van comprendiendo cómo queda el sistema.
Pero, ¿se puede considerar ágil RUP?, en este otro artículo, indico los motivos por los que no considero ágil a esta metodología.

http://jummp.wordpress.com/2011/04/06/desarrollo-de-software-ciclo-de-vida-rup-rational-unified-process/

Desarrollo de software. Cuando el usuario no está implicado

Se pueden enumerar decenas y decenas de posibles situaciones que se pueden producir en un proyecto y que se podrían considerar riesgos, pero hay una que casi podríamos considerarla unánimemente cómo el principal factor de riesgo en un proyecto y es la falta de implicación del área usuaria.
Sin ellos no hay visión de las expectativas de producto por más que el equipo de proyecto cuente con personas con visión y experiencia sobre el negocio, porque una cosa es el proceso de negocio que se quiere informatizar y otra es cómo le gustaría al usuario verla ejecutada. Es posible que se acierte sin el usuario pero es más mucho más probable que se falle.
¿Y por qué el usuario no se implica?
- Se ha designado un responsable funcional o product owner que no quiere asumir sus responsabilidades o el trabajo que implica el mismo y la dirección del área usuaria no hace nada por arreglar esta situación.
- Puede darse el caso de que quiera hacer ese trabajo pero no se le han dado instrucciones precisas sobre qué tareas de las que tiene que atender son más prioritarias, por lo que tenderá a hacer las propias de su trabajo ordinario.
- También puede producirse el hecho de que sean sus propios jefes los que les obliguen a atender otras prioridades.
- Al área usuaria o al departamento TIC se les vendió un proyecto que pretendía cubrir una necesidad no existente y como tal, llegado el momento, se prefiere atender otras necesidades o trabajos más urgentes.
- El área usuaria apostó por el desarrollo ya que era una apuesta personal por parte de la dirección del área afectada y en un momento dado se produce un relevo en la misma que considera que existen otras prioridades.
- El área usuario y/o el responsable funcional se desaniman al no desarrollarse el proyecto según sus expectativas. Esto no quiere decir que se estén haciendo las cosas mal (que es posible) sino que no se han sabido gestionar sus expectativas,.
Causas puede haber muchas, pero el camino siempre debería ser el mismo en el caso de que se produzca esta situación y es que si no se consigue enderezar, lo mejor para todos es que se llegue a un acuerdo para dar por finalizado el proyecto y resolver el contrato (cuando proceda).

http://jummp.wordpress.com/2013/12/24/desarrollo-de-software-cuando-el-usuario-no-esta-implicado/

White box testing: Need, Skill required and Limitations

What is White Box Testing?
White box testing (WBT) is also called Structural or Glass box testing.
White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.
White Box Testing is coverage of the specification in the code.
Code coverage:
Segment coverage:
Ensure that each code statement is executed once.
Branch Coverage or Node Testing:
Coverage of each code branch in from all possible was.
Compound Condition Coverage:
For multiple condition test each condition with multiple paths and combination of different path to reach that condition.
Basis Path Testing:
Each independent path in the code is taken for testing.
Data Flow Testing (DFT):
In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code.DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. In short each data variable is tracked and its use is verified.
This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.
Path Testing:
Path testing is where all possible paths through the code are defined and covered. Its a time consuming task.
Loop Testing:
These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested by this approach.
Why we do White Box Testing?
To ensure:

• That all independent paths within a module have been exercised at least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational bounds internal data structures validity.

Need of White Box Testing?
To discover the following types of bugs:

• Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
• The design errors due to difference between logical flow of the program and the actual implementation
• Typographical errors and syntax checking

Skills Required:
We need to write test cases that ensure the complete coverage of the program logic.
For this we need to know the program well i.e. We should know the specification and the code to be tested. Knowledge of programming languages and logic.
Limitations of WBT:
Not possible for testing each and every path of the loops in program. This means exhaustive testing is impossible for large systems.
This does not mean that WBT is not effective. By selecting important logical paths and data structure for testing is practically possible and effective.
Reference- http://www.softrel.org/stgb.html


http://www.softwaretestinghelp.com/white-box-testing/

Desarrollo de software. Antipatrón. Con la mitad es suficiente

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.
El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en “apagar el incendio”, dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.
Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.
Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.
Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un “alarde de creatividad” deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.
El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.
Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

http://jummp.wordpress.com/2012/01/21/desarrollo-de-software-antipatron-con-la-mitad-es-suficiente/

Algoritmo

Los algoritmos son independientes de los lenguajes de programación. En cada problema el algoritmo puede escribirse y luego ejecutarse en un lenguaje de diferente programación. 

El algoritmo es la infraestructura de cualquier solución, escrita luego en cualquier lenguaje de programación.

Algoritmo: Un Algoritmo, se puede definir como una secuencia de instrucciones que representan un modelo de solución para determinado tipo de problemas. O bien como un conjunto de instrucciones que realizadas en orden conducen a obtener la solución de un problema. 

Por lo tanto podemos decir que es un conjunto ordenado y finito de pasos que nos permite solucionar un problema.

Programa: Un programa es una serie de instrucciones ordenadas, codificadas en lenguaje de programación que expresa un algoritmo y que puede ser ejecutado en un computador.

Clasificación

Los algoritmos se pueden clasificar en cuatro tipos: 

1. Algoritmo computacional: Es un algoritmo que puede ser ejecutado en una computadora. Ejemplo: Fórmula aplicada para un cálculo de la raíz cuadrada de un valor x.
2. Algoritmo no computacional: Es un algoritmo que no requiere de una computadora para ser ejecutado. Ejemplo: Instalación de un equipo de sonido.
3. Algoritmo cualitativo: Un algoritmo es cualitativo cuando en sus pasos o instrucciones no están involucrados cálculos numéricos. Ejemplos: Las instrucciones para desarrollar una actividad física, encontrar un tesoro.
4. Algoritmo cuantitativo: Una algoritmo es cuantitativo cuando en sus pasos o instrucciones involucran cálculos numéricos. Ejemplo: Solución de una ecuación de segundo grado.

Características

Todo algoritmo debe tener las siguientes características: 

• Debe ser Preciso,
  porque cada uno de sus pasos debe indicar de manera precisa e inequívoca que se debe hacer.
• Debe ser Finito,
  porque un algoritmo debe tener un número limitado de pasos.
• Debe ser Definido,
  porque debe producir los mismos resultados para las mismas condiciones de entrada.
• Puede tener cero o más elementos de entrada. 
• Debe producir un resultado.
  Los datos de salida serán los resultados de efectuar las instrucciones.

Partes

Todo Algoritmo debe tener las siguientes partes:

• Entrada de datos, son los datos necesarios que el algoritmo necesita para ser ejecutado
• Proceso, es la secuencia de pasos para ejecutar el algoritmo.
• Salida de resultados, son los datos obtenidos después de la ejecución del algoritmo.

Técnicas de representación 

Para la representación de un algoritmo, antes de ser convertido a lenguaje de programación, se utilizan algunos métodos de representación escrita, gráfica o matemática. 

Los métodos más conocidos son:

• Diagramación libre (Diagramas de flujo).
• Diagramas Nassi-Shneiderman.
• Pseudocódigo.
• Lenguaje natural (español, inglés, etc.).
• Fórmulas matemáticas.

Fuente: http://informaticafrida.blogspot.mx/2009/03/algoritmo.html

Desarrollo de software. Método de desarrollo de sistemas dinámicos (DSDM)

En DSDM estamos ante otra metodología de naturaleza iterativa e incremental y es considerada la primera metodología ágil (su primera versión es del año 1995 y desde entonces se han realizado diversas actualizaciones de la misma).
DSDM está orientada a combatir los principios de la crisis del software, de manera que se puedan realizar proyectos de desarrollo de software en tiempo y presupuesto, verificando las expectativas del usuario (mediante la existencia de requisitos cambiantes que se tratan en las diferentes evoluciones del producto).
Antes de analizar brevemente las fases que componen el ciclo de vida DSDM, es importante repasar los nueve principios en los que se basa la metodología, ya que delimitan la naturaleza de la misma:
1.- Para llevar a cabo un proyecto eficiente y efectivo es necesario que el grupo de usuarios que participan en su definición estén implicados.
2.- El equipo de proyecto debe tener la capacidad de tomar decisiones importantes para que el proyecto siga avanzando sin necesidad de esperar la aprobación de niveles superiores de la jerarquía.
3.- Orientado a la existencia de frecuentes iteraciones, de manera que entregar algo bueno pronto es siempre mejor que esperar a entregar algo perfecto más tarde. El hecho que desde muy pronto se tenga la oportunidad de utilizar el producto, permite que desde etapas muy tempranas comience el continuo proceso de revisión que permita que en cada paso el producto además de ir asumiendo nuevas funcionales se acerque cada vez más a las expectativas del usuario.
4.- Se parte de lo más crítico y esa es la base para definir las características de las entregas, es decir, una entrega debe satisfacer unas serie de funcionalidades que son importantes o críticas en el sistema. No se trata de cubrir todas las necesidades del sistema (lo cual iría en contra de la naturaleza de este tipo de metodologías) sino de centrarse en las que resultan más necesarias, para que el proceso continuo de revisión empiece desde lo que resulta más importante que funcione de forma adecuada. Se trata de ir al grano, ya tocará en un futuro desarrollar y perfeccionar funcionalidades accesorias.
5.- La estrategia de desarrollo, por tanto, es iterativa e incremental y guiada por las necesidades de los usuarios.
6.- Cualquier cambio realizado en el proceso de desarrollo es reversible. Esto es muy importante. Un usuario se ha podido equivocar al especificar una funcionalidad o la forma en que debe operar la misma, si es así no se debe continuar con el error sino rehacer completamente la funcionalidad si fuera preciso.
7.- Los objetivos y requisitos de alto nivel del proyecto han debido ser pactados y aceptados entre las partes que participan en el proyecto, antes de que el proyecto comience.
8.- Las pruebas se realizan a lo largo de todo el ciclo de vida del proyecto, no solo se realizan entre iteración e iteración sino que están presentes en los diferentes entregables. Esto se realiza para la detección temprana de errores, ya que sabemos que cuánto más se tarde en corregirlos, más costoso resulta.
9.- Resulta fundamental la comunicación y cooperación de todas las partes implicadas en el proyecto.

Considero importante indicar los principios y asunciones antes que la metodología en sí, ya que son la base no solo de la misma, sino de prácticamente cualquier metodología de desarrollo que tenga una orientación iterativa e incremental.
Si no se cree en ellos, no se creerá en este tipo de metodologías. Como ya sabéis por los artículos que llevo escritos sobre la materia, considero que proyectos desarrollados de esta manera tienen un porcentaje de éxito mayor que otros desarrollados con metodologías más tradicionales como las basadas en el ciclo de vida clásico o cascada.
Las asunciones son las siguientes:
- Los sistemas no se construyen perfectamente en una solo intento. Sin embargo siguiendo el Principio de Pareto, el 80% de los objetivos de una solución perfecta se puede desarrollar en el 20% del esfuerzo que se requeriría para obtenerlos. Por tanto, la realización de un desarrollo rápido debería centrarse en priorizar funcionalidades importantes para la cobertura de las funcionalidades de negocio dejando con las mismas satisfechos al conjunto de usuarios. Esto debería ser posible ya que la metodología requiere una implicación real de los usuarios.
Intentar construir un sistema perfecto es una utopía e intentar aproximarse demasiado pronto a esa idea de sistema es una pérdida de energía que además pone en riesgo al propio sistema de información, ya que como consecuencia de ello muchos de los inconvenientes de la crisis del software habrán impactado en el proyecto. Si intentamos subir una cuesta a máximo rendimiento desde el principio probablemente tardemos más en alcanzar la cima (si es que llegamos a ella).
- No se puede quitar la vista del objetivo de conseguir proyectos con calidad y dentro de los plazos y presupuestos.
Y añado yo, que satisfaga al usuario (eso debería estar ya implícito en el concepto de calidad, pero nunca está de más tener siempre presente que los proyectos y que nuestro trabajo (en la mayoría de los casos) está orientado a informatizar procesos que utilizan personas y que si las mismas no se sientes cómodas y no le sacan rendimiento no serán eficientes en el uso de la aplicación y se resentirá la productividad y la calidad de los datos que se graban.
- Pueden desarrollarse simultáneamente varios incrementos siempre y cuando no se entorpezcan entre sí.
- La metodología es válida más allá de desarrollos que comiencen desde cero. Es igualmente aplicable para mantenimientos incluso de proyectos no desarrollados siguiendo esta metodología o una similar.
¿Por qué no iba a serlo? La clave está en definir adecuadamente los incrementos (aunque sea más o menos difícil). Si estamos ante el mantenimiento de un sistema gigantesco que tiene incendios por todos lados resultará más complicado priorizar y se tardarán bastantes iteraciones en conseguir una cierta estabilidad.
Las bases de la metodología o la metodología en sí no constituyen una piedra filosofal para que todos los proyectos tengan éxito. Esta forma de entender los proyectos de desarrollo de software marcan un camino que desde mi punto de vista es el adecuado, pero generalmente la vía es tan ancha y hay tantas nubes que es fácil perderse.

La metodología está compuesta por tres fases que se realizan de forma secuencial:
Preproyecto. Se define el alcance global, quiénes son los departamentos y personas implicadas, los compromisos de las distintas partes y quién o quienes financiarán el proyecto.
Ciclo de vida del proyecto. Está compuesto por cinco fases:
- Estudio de la viabiliadad (Feasability study). Se estudia la adecuación de DSDM al proyecto y se identifican los riesgos del mismo. En esta fase se realiza un informe de viabilidad, un prototipo de viabilidad (el prototipo tiene sentido si se quieren evaluar algunos aspectos técnicos o funcionales y se puede utilizar para obtener información adicional del proyecto) y plan general del proyecto (plan de desarrollo + registro de riesgos).
- Estudio del negocio (Business study). Si DSDM se ha considerado adecuado para el proyecto, el siguiente paso consiste en realizar un análisis más en profundidad del proceso o procesos de negocio que se van a informatizar. La participación e implicación del usuario resulta fundamental en esta fase, si en la misma no se consigue, habría que replantear la realización del proyecto siguiendo DSDM o con cualquier otra metodología.
En esta fase se obtiene un modelo de procesos identificando los usuarios clave en cada uno de ellos, un catálogo de requisitos priorizado (algo lógico para una metodología iterativa e incremental), la arquitectura del sistema y el plan de prototipado.
- Iteración del modelo funcional (Functional Model Iteration). Se divide en 4 fases: Identificación del prototipo funcional (se definen las funcionalidades que cubrirá el prototipo y se elabora un modelo funcional del mismo), Definición del calendario (se acuerda el plan de trabajo para la realización de este modelado funcional), Obtención del prototipo funcional y Revisión del prototipo funcional (se determina el grado de aceptación del prototipo desarrollado, mediante pruebas realizadas por el usuario y/o la revisión de documentación, es muy importante la obtención del feedback del usuario para que las especificaciones del producto a obtener con esta iteración se acerquen lo máximo posible a las necesidades del usuario).
- Iteración del diseño y de la construcción (Design and Build Iteration). Se divide en 4 fases: Identificación del prototipo de diseño (se determinan los requisitos funcionales y no funcionalidades que cubrirá el prototipo), Definición del calendario (se acuerda el plan de trabajo para la construcción de este prototipo), Construcción del prototipo de diseño (será un producto utilizable para los usuarios, tratándose por tanto de un producto finalista en el sentido de que ya podría ser usado para realizar el trabajo cotidiano sobre las funcionalidades implementadas), Revisión del prototipo de diseño.
- Implementación (Implementation). Se divide en 4 fases: Aprobación del usuario (el usuario realiza la aprobación del producto a entregar), Formación (se forma a los usuarios finales de la aplicación), Implementación (se instala el producto en las instalaciones del cliente), Revisión de negocio (se revisa la adecuación del sistema a las necesidades del negocio y a los objetivos iniciales que se habían establecido para el mismo, en función de lo que se decida en esta fase se irá a la fase de Postproyecto o a una de las fases anteriores del ciclo de vida).
Si falta o se detecta algún nuevo aspecto funcional relevante se vuelve a la fase de Estudio del Negocio, si no es relevante se vuelve a la fase de Iteración del modelo funcional, si falta o se detecta algún nuevo aspecto técnico se vuelve a la fase de Iteración del diseño y la construcción.
Postproyecto. Tiene como objetivo la continuidad del sistema en el sentido de que siga siendo útil a las necesidades de los usuarios, comprendería por tanto el mantenimiento del sistema que se realizaría (si se estima conveniente siguiendo el ciclo de vida DSDM).
Es importante señalar que DSDM permite trabajar con varios prototipos simultáneamente siempre y cuando “no se molesten” entre sí, esto permite reducir el tiempo necesario para que los usuarios tengan en producción las distintas evoluciones del producto.

Si se hace una lectura al pie de la letra sí que puede parecerlo, pero hay que tener en cuenta que básicamente lo que se obtiene en cada fase es:
Preproyecto. ¿Qué se pretende conseguir y quiénes van a participar para conseguirlo?
Ciclo de vida del proyecto.
- Estudio de la viabiliadad (Feasability study). Lo que se pretende conseguir, ¿se puede obtener realmente con los recursos con los que se van a contar?, ¿es DSDM una metodología adecuada para llevarlo a cabo?, ¿qué problemas pueden provocar que el proyecto no evolucione adecuadamente?.
- Estudio del negocio (Business study). ¿Qué procesos se van a informatizar?, ¿qué requisitos se deben cumplir en los mismos (no se requiere entrar en detalle)?, ¿cuáles son más prioritarios?, ¿cuál se el plan de desarrollo iterativo e incremental?.
- Iteración del modelo funcional (Functional Model Iteration). En esta fase se perfeccionan y cierran los requisitos. Se puede apoyar en la realización de un prototipo. Se define una calendario para la realización de las distintas tareas que comprenden la fase.
- Iteración del diseño y de la construcción (Design and Build Iteration). Se realiza el proceso de diseño y construcción. Se define una calendario para la realización de las distintas tareas que comprenden la fase.
- Implementación (Implementation). Se realiza la aceptación del sistema, formación, la implantación y se realiza un análisis sobre la evolución e impacto del sistema, condicionando las próximas iteraciones a desarrollar.
Postproyecto. Comprendería lo que es la fase posterior a la entrega de un producto finalista (resultado de sucesivas iteraciones), de manera que haría referencia al mantenimiento del sistema de información que se puede hacer siguiendo DSDM o no.
Por tanto, la metodología, vista desde más arriba no tiene por qué resultar pesada.



http://jummp.wordpress.com/2011/04/13/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-i/
http://jummp.wordpress.com/2011/04/14/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-ii/
http://jummp.wordpress.com/2011/04/15/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-iii/
http://jummp.wordpress.com/2011/04/16/desarrollo-de-software-metodo-de-desarrollo-de-sistemas-dinamicos-dsdm-iv/