- 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.
viernes, noviembre 29
Chistes sobre Testing - Parte 4
jueves, noviembre 28
Test Project Estimation, The Rapid Way
Erik Petersen (with whom I’ve shared one of the more memorable meals in my life) says, in the Software Testing Yahoo! group,
I know when I train testers, nearly all of them complain about not enough time to test, or things being hard to test. The lack of time is typically being forced into a completely unrealistic time frame to test against.
I used to have that problem. I don’t have that problem any more, because I’ve reframed it (thanks to Cem Kaner, Jerry Weinberg, and particularly James Bach for helping me to get this). It’s not my lack of time, because the time I’ve got is a given. Here’s a little sketch for you.
I’m sitting in my office. Someone, a Pointy-haired Boss (Ph.B.), barges in and says…
Ph.B.: “We’re releasing on March 15th. How long do you need to test this product?”
Me: (pause) Um… Let’s see. June 22.
Ph.B.: WHAT?! That can’t be!
Me: You had some other date in mind?
Ph.B.: Well, something a little earlier than that.
Me: Okay… How about February 19?
Ph.B.: WHAT!?! We want to release it on March 15th! Are you just going to sit on your hands for four weeks?
Me: Oh. So… how about I test until about, say, March 14.
Ph.B.: Well that’s… better…
Me: (pause) …but I won’t tell you that it’s ready to ship.
Ph.B.: How do you know already that it won’t be ready to ship?
Me: I don’t know that. That’s not what I mean; I’m sorry, I didn’t make myself clear. I mean that I won’t tell you whether it’s ready to ship.
Ph.B.: What? You won’t? Why not?!
Me: It’s not my decision to ship or not to ship. The product has to be good enough for you, not for me. I don’t have the business knowledge you have. I don’t know if the stock price depends on quarterly results, and I definitely don’t know if there are bonuses tied to this release. There are bunches of factors that determine the business decision. I can’t tell you about most of those. But I can tell you things that I think are important about the product. In particular, I can tell you about important problems.
Ph.B.: But when will you know when I can ship?
Me: Only you can know that. I can’t make your decision, but I can give you information that helps you to make it. Every day, I’ll learn more and more about the product and our understanding of it, and I’ll pass that on to you. I’ll focus on finding important problems quickly. If you want to know something specific about the product, I’ll run tests to find it out, and I’ll tell you about what I find. Any time you want to ask me to report my status, I’ll do that. If at any time you decide to change the ship date, I’ll abide by that; you can release before or after or on the 15th—whenever you decide that you don’t have any more important questions about the product, and that you’re happy with the answers you’ve got.
Ph.B.: So when will you have run all the tests?
Me: All the tests that I can think of? I can always think of more questions that I could ask and answer about the product—and I’ll let you know what those are. At some point, you’ll decide that you don’t need those questions answered—the questions or answers aren’t interesting enough to prevent you from releasing the product. So I’ll keep testing until I’m done.
Ph.B.: When will you be done?
Me: You’re my client; I’ll test as long as you want me to. I’ll be done when you ask me to stop testing—or when you ship.
http://www.developsense.com/blog/2007/01/test-project-estimation-rapid-way/
I know when I train testers, nearly all of them complain about not enough time to test, or things being hard to test. The lack of time is typically being forced into a completely unrealistic time frame to test against.
I used to have that problem. I don’t have that problem any more, because I’ve reframed it (thanks to Cem Kaner, Jerry Weinberg, and particularly James Bach for helping me to get this). It’s not my lack of time, because the time I’ve got is a given. Here’s a little sketch for you.
I’m sitting in my office. Someone, a Pointy-haired Boss (Ph.B.), barges in and says…
Ph.B.: “We’re releasing on March 15th. How long do you need to test this product?”
Me: (pause) Um… Let’s see. June 22.
Ph.B.: WHAT?! That can’t be!
Me: You had some other date in mind?
Ph.B.: Well, something a little earlier than that.
Me: Okay… How about February 19?
Ph.B.: WHAT!?! We want to release it on March 15th! Are you just going to sit on your hands for four weeks?
Me: Oh. So… how about I test until about, say, March 14.
Ph.B.: Well that’s… better…
Me: (pause) …but I won’t tell you that it’s ready to ship.
Ph.B.: How do you know already that it won’t be ready to ship?
Me: I don’t know that. That’s not what I mean; I’m sorry, I didn’t make myself clear. I mean that I won’t tell you whether it’s ready to ship.
Ph.B.: What? You won’t? Why not?!
Me: It’s not my decision to ship or not to ship. The product has to be good enough for you, not for me. I don’t have the business knowledge you have. I don’t know if the stock price depends on quarterly results, and I definitely don’t know if there are bonuses tied to this release. There are bunches of factors that determine the business decision. I can’t tell you about most of those. But I can tell you things that I think are important about the product. In particular, I can tell you about important problems.
Ph.B.: But when will you know when I can ship?
Me: Only you can know that. I can’t make your decision, but I can give you information that helps you to make it. Every day, I’ll learn more and more about the product and our understanding of it, and I’ll pass that on to you. I’ll focus on finding important problems quickly. If you want to know something specific about the product, I’ll run tests to find it out, and I’ll tell you about what I find. Any time you want to ask me to report my status, I’ll do that. If at any time you decide to change the ship date, I’ll abide by that; you can release before or after or on the 15th—whenever you decide that you don’t have any more important questions about the product, and that you’re happy with the answers you’ve got.
Ph.B.: So when will you have run all the tests?
Me: All the tests that I can think of? I can always think of more questions that I could ask and answer about the product—and I’ll let you know what those are. At some point, you’ll decide that you don’t need those questions answered—the questions or answers aren’t interesting enough to prevent you from releasing the product. So I’ll keep testing until I’m done.
Ph.B.: When will you be done?
Me: You’re my client; I’ll test as long as you want me to. I’ll be done when you ask me to stop testing—or when you ship.
http://www.developsense.com/blog/2007/01/test-project-estimation-rapid-way/
Always Question the Process
Let me recount a story from the television show Babylon 5.
In one episode there is the description of guard posted in the middle
of an empty courtyard. There is nothing there to protect. When one of
the characters, Londo, questions why, he finds that no one, not even the
emperor, knows why. After doing some research, Londo discovers that
200 years before, the emperor's daughter came by the spot at the end of
winter. The first flower of the spring was poking up through the snow.
Not wanting anyone to step on the flower, she posted a guard there.
She then forgot about the flower, the guard, and never countermanded her
order. Now, 200 years later, there was still a guard posted but with
nothing to protect. There had been nothing to protect for 200 years.
This demonstrates the unfortunate power of process. It often takes
on a life of its own. Those creating the complex system of rules expect
it to be followed. Once written down though, people stop thinking
about why it was done. Instead, they only expect it to be carried out.
This often leads to situations where work is being done for the sake of
process instead of the outcome. It is from this situation that
bureaucracy gets its sullied reputation (well, that and the seeming
ineptitude of many bureaucrats). Process can easily become inflexible.
This is especially true in the technology industry where process is
embedded in the code of intranet sites and InfoPath forms.
I encourage you to constantly revisit your process. Question it.
Why do you do things the way you do? Is there still a reason for each
step? If you don't know, jettison that step. Simplify. You should
have just enough process to get the job done, but no more. Once again,
I'll re-iterate. You hire smart people. You pay them to think. Let
them.
This isn't to say that all process is bad. Having common ways of
accomplishing common tasks is efficient. If a process truly makes
things more efficient, it should be kept. If not, it should be killed.
What was at one time efficient probably isn't any more. Be vigilant.
http://blogs.msdn.com/b/steverowe/archive/2007/11/12/question-process.aspx
lunes, noviembre 25
Using a Severity Look-up Table for better and more accurate Bug Classification.
n the past I posted articles on the importance of differentiating between the severity and priority of a bug and about how to report a bug correctly; but there is one subject that I left out and got questioned about it a couple of days ago:
The hard way: to define the Severity each time from scratch
Sadly enough most groups work this way, asking their testers and/or bug-reporters to set the severity based on a scale (of either 3 or 5 levels) according to their objective understanding of the harm the bug causes the system or end-user.
What’s the problem with this approach?
1. It’s not objective, so two people may look at the same bug and set 2 different severities.
2. It usually gathers bugs towards the middle of the scale.
From personal experience if you leave your severity definition to the testers’ gut-feeling, the bug distribution at the end of the project will look like a normal curve.
At first you may think this is OK but think again… There is no logical explanation for this behavior, on the contrary for many or most projects you expect to see shifts to the right or left based on factors such as the maturity of the team, application, technology, etc.
My explanation is that we like to do things on a balanced way, so unconsciously we try to balance even the severities of the bugs we report (don’t blame your mother, its genetic…).
3. Your severity appreciation can shift with time.
You may have seen this in the past projects, as we advance in our testing we may look at a bug we reported in the past and feel that we gave it a severity that is too high compared to the ones we are reporting today.
This may be related to the old saying: “just when you though things can’t get any worst, they usually do”.
The easy way: create a Severity Look-up Table
In my opinion the best way to give the correct severity is by having a look-up table to help us classify our bugs. By thinking ahead of time about most bug cases and creating a table we are able to classify bugs more accurately and based on a standard system.
An example of a Severity Look-up Table I’ve used in the past is the following:
S1 – Critical
A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround.
Additional specific bugs:
- Spelling or Grammar Mistakes
- Important bugs that were reported from customers and we assured them will be fixed.
S2 – High
The defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users.
Additional specific bugs:
- High visibility GUI issues.
S3 – Medium
The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users.
S4 – Low
The defect causes no dysfunctions to the system and may even be unnoticed by most users . The bug has an easy workaround or may not even require a workaround at all.
S5 – Enhancement Request or Suggestion
No need to explain.
Notice that on some levels I added specific cases that even if they don’t fit the definition of the severity will still make it to that level. This is a practice that will help you include your specific issue themes into the Severity Look-up table.
Each Organization / Team / Project may need to review or fine-tune their Severity Look-up Table once in a while based on their individual definitions, requirements and customer needs.
I remember once I told a group I was training about this practice. A young tester got up and said that she thought using a Look-up Table would make her look inexperienced and unprofessional.
My reply was that I still use lists like this in almost every project I work, and that it would be less professional to use another approach if she knew that this one was easier and gave better results…
http://qablog.practitest.com/2008/12/using-a-severity-look-up-table-for-better-and-more-accurate-bug-classification/
how to give bugs the correct (and objective) severity?
I know of at least 2 ways to set the priority of each bug correctly, the hard way and the easy way.The hard way: to define the Severity each time from scratch
Sadly enough most groups work this way, asking their testers and/or bug-reporters to set the severity based on a scale (of either 3 or 5 levels) according to their objective understanding of the harm the bug causes the system or end-user.
What’s the problem with this approach?
1. It’s not objective, so two people may look at the same bug and set 2 different severities.
2. It usually gathers bugs towards the middle of the scale.
From personal experience if you leave your severity definition to the testers’ gut-feeling, the bug distribution at the end of the project will look like a normal curve.
At first you may think this is OK but think again… There is no logical explanation for this behavior, on the contrary for many or most projects you expect to see shifts to the right or left based on factors such as the maturity of the team, application, technology, etc.
My explanation is that we like to do things on a balanced way, so unconsciously we try to balance even the severities of the bugs we report (don’t blame your mother, its genetic…).
3. Your severity appreciation can shift with time.
You may have seen this in the past projects, as we advance in our testing we may look at a bug we reported in the past and feel that we gave it a severity that is too high compared to the ones we are reporting today.
This may be related to the old saying: “just when you though things can’t get any worst, they usually do”.
The easy way: create a Severity Look-up Table
In my opinion the best way to give the correct severity is by having a look-up table to help us classify our bugs. By thinking ahead of time about most bug cases and creating a table we are able to classify bugs more accurately and based on a standard system.
An example of a Severity Look-up Table I’ve used in the past is the following:
S1 – Critical
A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround.
Additional specific bugs:
- Spelling or Grammar Mistakes
- Important bugs that were reported from customers and we assured them will be fixed.
S2 – High
The defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users.
Additional specific bugs:
- High visibility GUI issues.
S3 – Medium
The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users.
S4 – Low
The defect causes no dysfunctions to the system and may even be unnoticed by most users . The bug has an easy workaround or may not even require a workaround at all.
S5 – Enhancement Request or Suggestion
No need to explain.
Notice that on some levels I added specific cases that even if they don’t fit the definition of the severity will still make it to that level. This is a practice that will help you include your specific issue themes into the Severity Look-up table.
Each Organization / Team / Project may need to review or fine-tune their Severity Look-up Table once in a while based on their individual definitions, requirements and customer needs.
I remember once I told a group I was training about this practice. A young tester got up and said that she thought using a Look-up Table would make her look inexperienced and unprofessional.
My reply was that I still use lists like this in almost every project I work, and that it would be less professional to use another approach if she knew that this one was easier and gave better results…
http://qablog.practitest.com/2008/12/using-a-severity-look-up-table-for-better-and-more-accurate-bug-classification/
Keep Process Simple
Year ago one of our
Software Test Engineers was tasked with documenting our smoke*
process. It should have been something simple like:
- Developer packages binaries for testing
- Developer places smoke request on web page
- Tester signs up for smoke on web page
- Tester runs appropriate tests
- Tester signs off on fix
- Developer checks in
Instead it turned into a ten page document. Needless to say, I took
one glance at the document and dismissed it as worthless. As far as I
know, no one ever followed the process as it was described in that
document. We all had a simple process like the six steps I laid out
above and we continued to follow it.
When tasked with creating a process for a given task, the tendency is
to make the process complex. It's not always a conscious effort, but
when you start taking into account every contingency, the flow chart
gets big, the document gets long, and the process becomes complex. To
make matters worse, when a problem happens that the process didn't
prevent, another new layer of process is added on top. Without
vigilance, all process becomes large and unwieldy.
The problem with a large, complex process is that it quickly becomes
too big to keep in one's mind. When a process is hard to remember, it
isn't followed. If it takes a flow chart to describe an everyday task,
it is probably too big. It is far better to have a simple, but
imperfect process to one that is complete. The simple process will be
followed out faithfully. The complete one will at best be simplified by
those carrying it out. Worse, it may be fully ignored. It is
deceptive to think that a complex process will avoid trouble. More
often than not, it will only provide the illusion of serenity.
I have discovered that process is necessary, but it must be simple.
It is best to keep it small enough that it is easily remembered. The
best way to do this is to document what is done, not what you want to be
done. People have usually worked out a good solution. Document that.
Don't try to cover all the contingencies. It will only hide the real
work flow. Documented process should exist to bring new people up to
speed quickly. It should be there to unify two disparate systems. It
should not be there to solve problems. You hire smart people, let them
do that. Expect them to think.
My final advice on this topic is do not task people with creating
process. It is tempting to say to someone, "Go create a process for
creating test collateral." Tasking someone with creating process is a
surefire way to choke the system on too much process. The results won't
be pretty. Nor will they be followed.
*Smoke testing is a process involving testing fixes before committing
them to the mainline build. Its purpose is to catch bugs before they
affect most users.
Ejercicios Diagrama de flujo - Propuestos 5
Quinta serie de ejercicios propuestos para realizar diagramas de flujo.
Los demás ejercicios Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Ejemplo 1 Ejemplo 2 Ejemplo 3 Ejemplo 4 Ejemplo 5
1) Suponga que tiene una tienda y desea registrar sus ventas por medio de una computadora.
Diseñe un pseudocódigo que lea por cada cliente:
a) El monto de la venta,
b) Calcule e imprima el IVA ,
c) Calcule e imprima el total a pagar,
d) Lea la cantidad con que paga el cliente,
e) Calcule e imprime el cambio.
Al final del día deberá imprimir la cantidad de dinero que debe haber en la caja.
2) Modificar el pseudocódigo anterior de tal forma que no permita que la cantidad con la que paga el cliente sea menor a lo que debe pagar.
3) Se tiene un conjunto de 1,000 tarjetas cada una contiene la información del censo para una persona:
1.- Número de censo,
2.- Sexo
3.- Edad
4.- Estado civil (a.- soltero, b. Casado, c. Viudo, d. Divorciado )
Diseñe un pseudocódigo estructurado que lea todos estos datos, e imprima el número de censo de todas las jóvenes solteras que estén entre 16 y 21 años.
4) Diseñe un pseudocódigo que lea el valor de un ángulo expresado en radianes y calcule e imprima el valor del seno de dicho ángulo.
Se leerá también el número de términos de la serie:
SEN(X) = X - ( X 3 / 3 ! ) + ( X 5 / 5 ! ) - (X7/ 7!) + .....
5) Un jeep puede viajar 500 km con un tanque lleno de gasolína. Desde una posición inicial, conteniendo 'N' tanques de gasolina el mismo jeep puede viajar:
L = 500 ( 1 + 1/3 + 1/5 + ...+ 1 / (2n -1) ) km
Estableciendo economía de combustible en una ruta.
Diseñe un pseudocódigo que calcule el valor de 'L' dado 'N' .
6) Se ofrece un trabajo que pague un centavo en la primera semana, pero dobla su salario cada semana, es decir , $.01 la primera semana; $.02 la segunda semana; $0.4 la tercera semana; ... etc. Hasta $(2n-1)/100 la N-ésima .
Diseñar el pseudocódigo que determine ( y escriba ) el salario por cada semana y el salario pagado hasta la fecha por espacio de 50 semanas.
7) Diseñe un pseudocódigo que calcule e imprima el pago de 102 trabajadores que laboran en la Empresa TUTEIS.
Los datos que se leerán serán los siguientes:
a) Las horas trabajadas
b) El sueldo por hora
c) El tipo de trabajador (1.-obrero,2.-empleado)
Para calcular los pagos considerar lo siguiente:
- Los obreros pagan 10 % de impuesto
- Los empleados pagan 10 % de impuesto.
- Los trabajadores (obreros y empleados) que reciban un pago menor de 100,000 pesos no pagan impuesto.
Al final se deberá imprimir el total a pagar a los trabajadores y a los empleados.
8) Diseñar un pseudocódigo que convierta un número del sistema decimal a :
a) sistema binario
b) sistema octal
c) sistema hexadecimal.
Según se elija.
9) Un objeto es dejado caer a una altura de 100 mts.
Diseñe un pseudocódigo que imprima cada décima de segundo la distancia entre el objeto y el suelo y al final imprima el tiempo necesario en décimas de segundo para que el objeto toque el suelo.
10) La empresa Automovilística Tuteis Mexicana, S.A. de C.V premia anualmente a sus mejores vendedores de acuerdo a la siguiente tabla:
Si vendió --- Le corresponde de Comisiónsobre ventas totales
1,000,000 <= v < 3,000,000 --- 3%
3,000,000 <= v < 5,000,000 --- 4%
5,000,000 <= v < 7,000,000 --- 5%
7,000,000 <= v --- 6%
Diseñar un pseudocódigo que lea las ventas de 100 vendedores y que escriba la comisión anual que le corresponda a cada vendedor.
Suponer que nadie vende más de 10,000,000 al año.
11) Diseñe un pseudocódigo que imprima la fecha en palabras a partir de la representación siguiente: S,DD,MM, AA.
En donde:
S = Día de la semana, 1 a 7 ( 1 = lunes; 2 = martes; etc..);
DD = Día del mes, 1 a 30 ó 31, según el mes. Fijar el mes de febrero con 28 días;
AA = Dos últimas cifras del año.
12) Un grupo de 100 estudiantes presentan un exámen de Física.
Diseñe un diagrama que lea por cada estudiante la calificación obtenida y calcule e imprima:
A.- La cantidad de estudiantes que obtuvieron una calificación menor a 50.
B.- La cantidad de estudiantes que obtuvieron una calificación de 50 o más pero menor que 80.
C.- La cantidad de estudiantes que obtuvieron una calificación de 70 o más pero menor que 80.
D. La cantidad de estudiantes que obtuvieron una calificación de 80 o más.
13) Un avión que viaja 800 Km/hr dispara un proyectil autoimpulsado, en el momento del disparo, el avión hace un giro de 90° y acelera a 20 mtrs/seg². El proyectil sigue su curso, acelerando a 10 mtrs./seg².
Diseñe un pseudocódigo que escriba cada segundo, la distancia que separa al avión del proyectil, hasta que estén a 10,000 mtrs. o más.
14) Una pizzería, vende sus pizzas en tres tamaños:
pequeña (10 pulg. De diámetro);
mediana (12 pulg. De diámetro); y
grandes (16 pulg. De diámetro);
Una pizza puede ser sencilla (con sólo salsa y carne),
o con ingredientes extras, tales como pepinillos,champiñones o cebollas
Los propietarios desean desarrollar un programa que calcule el precio de venta de una pizza, dándole el tamaño y el numero de ingredientes extras.
El precio de venta será 1.5 veces el costo total, que viene determinado por el área de la pizza, mas el numero de ingredientes.
En particular el costo total se calcula sumando:
- un costo fijo de preparación
- un costo base variable que es proporcional al tamaño de la pizza
- un costo adicional por cada ingrediente extra.
Por simplicidad se supone que cada ingrediente extra tiene el mismo costo por unidad de área.
15) Diseñar un pseudocódigo que calcule el promedio ponderado para alumno del Tecnológico Universitario de Tecnologías de la Información . El cálculo se hace de la siguiente forma:
- Se multiplica cada calificación por los créditos de cada materia
- El resultado anterior se suma con los resultados de todas las materias, por separado se suman los créditos de cada materia y finalmente se divide la suma de todas las materias por sus respectivos créditos, entre la suma de todos los créditos.
16) Calcule la suma de los términos de la serie FIBONACCI cuyos valores se encuentran entre 100 y 10,000.
17) Calcule exactamente el numero de días vividos por una persona hasta la fecha.
Contemplar los años bisiestos.
Los demás ejercicios Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Ejemplo 1 Ejemplo 2 Ejemplo 3 Ejemplo 4 Ejemplo 5
1) Suponga que tiene una tienda y desea registrar sus ventas por medio de una computadora.
Diseñe un pseudocódigo que lea por cada cliente:
a) El monto de la venta,
b) Calcule e imprima el IVA ,
c) Calcule e imprima el total a pagar,
d) Lea la cantidad con que paga el cliente,
e) Calcule e imprime el cambio.
Al final del día deberá imprimir la cantidad de dinero que debe haber en la caja.
2) Modificar el pseudocódigo anterior de tal forma que no permita que la cantidad con la que paga el cliente sea menor a lo que debe pagar.
3) Se tiene un conjunto de 1,000 tarjetas cada una contiene la información del censo para una persona:
1.- Número de censo,
2.- Sexo
3.- Edad
4.- Estado civil (a.- soltero, b. Casado, c. Viudo, d. Divorciado )
Diseñe un pseudocódigo estructurado que lea todos estos datos, e imprima el número de censo de todas las jóvenes solteras que estén entre 16 y 21 años.
4) Diseñe un pseudocódigo que lea el valor de un ángulo expresado en radianes y calcule e imprima el valor del seno de dicho ángulo.
Se leerá también el número de términos de la serie:
SEN(X) = X - ( X 3 / 3 ! ) + ( X 5 / 5 ! ) - (X7/ 7!) + .....
5) Un jeep puede viajar 500 km con un tanque lleno de gasolína. Desde una posición inicial, conteniendo 'N' tanques de gasolina el mismo jeep puede viajar:
L = 500 ( 1 + 1/3 + 1/5 + ...+ 1 / (2n -1) ) km
Estableciendo economía de combustible en una ruta.
Diseñe un pseudocódigo que calcule el valor de 'L' dado 'N' .
6) Se ofrece un trabajo que pague un centavo en la primera semana, pero dobla su salario cada semana, es decir , $.01 la primera semana; $.02 la segunda semana; $0.4 la tercera semana; ... etc. Hasta $(2n-1)/100 la N-ésima .
Diseñar el pseudocódigo que determine ( y escriba ) el salario por cada semana y el salario pagado hasta la fecha por espacio de 50 semanas.
7) Diseñe un pseudocódigo que calcule e imprima el pago de 102 trabajadores que laboran en la Empresa TUTEIS.
Los datos que se leerán serán los siguientes:
a) Las horas trabajadas
b) El sueldo por hora
c) El tipo de trabajador (1.-obrero,2.-empleado)
Para calcular los pagos considerar lo siguiente:
- Los obreros pagan 10 % de impuesto
- Los empleados pagan 10 % de impuesto.
- Los trabajadores (obreros y empleados) que reciban un pago menor de 100,000 pesos no pagan impuesto.
Al final se deberá imprimir el total a pagar a los trabajadores y a los empleados.
8) Diseñar un pseudocódigo que convierta un número del sistema decimal a :
a) sistema binario
b) sistema octal
c) sistema hexadecimal.
Según se elija.
9) Un objeto es dejado caer a una altura de 100 mts.
Diseñe un pseudocódigo que imprima cada décima de segundo la distancia entre el objeto y el suelo y al final imprima el tiempo necesario en décimas de segundo para que el objeto toque el suelo.
10) La empresa Automovilística Tuteis Mexicana, S.A. de C.V premia anualmente a sus mejores vendedores de acuerdo a la siguiente tabla:
Si vendió --- Le corresponde de Comisiónsobre ventas totales
1,000,000 <= v < 3,000,000 --- 3%
3,000,000 <= v < 5,000,000 --- 4%
5,000,000 <= v < 7,000,000 --- 5%
7,000,000 <= v --- 6%
Diseñar un pseudocódigo que lea las ventas de 100 vendedores y que escriba la comisión anual que le corresponda a cada vendedor.
Suponer que nadie vende más de 10,000,000 al año.
11) Diseñe un pseudocódigo que imprima la fecha en palabras a partir de la representación siguiente: S,DD,MM, AA.
En donde:
S = Día de la semana, 1 a 7 ( 1 = lunes; 2 = martes; etc..);
DD = Día del mes, 1 a 30 ó 31, según el mes. Fijar el mes de febrero con 28 días;
AA = Dos últimas cifras del año.
12) Un grupo de 100 estudiantes presentan un exámen de Física.
Diseñe un diagrama que lea por cada estudiante la calificación obtenida y calcule e imprima:
A.- La cantidad de estudiantes que obtuvieron una calificación menor a 50.
B.- La cantidad de estudiantes que obtuvieron una calificación de 50 o más pero menor que 80.
C.- La cantidad de estudiantes que obtuvieron una calificación de 70 o más pero menor que 80.
D. La cantidad de estudiantes que obtuvieron una calificación de 80 o más.
13) Un avión que viaja 800 Km/hr dispara un proyectil autoimpulsado, en el momento del disparo, el avión hace un giro de 90° y acelera a 20 mtrs/seg². El proyectil sigue su curso, acelerando a 10 mtrs./seg².
Diseñe un pseudocódigo que escriba cada segundo, la distancia que separa al avión del proyectil, hasta que estén a 10,000 mtrs. o más.
14) Una pizzería, vende sus pizzas en tres tamaños:
pequeña (10 pulg. De diámetro);
mediana (12 pulg. De diámetro); y
grandes (16 pulg. De diámetro);
Una pizza puede ser sencilla (con sólo salsa y carne),
o con ingredientes extras, tales como pepinillos,champiñones o cebollas
Los propietarios desean desarrollar un programa que calcule el precio de venta de una pizza, dándole el tamaño y el numero de ingredientes extras.
El precio de venta será 1.5 veces el costo total, que viene determinado por el área de la pizza, mas el numero de ingredientes.
En particular el costo total se calcula sumando:
- un costo fijo de preparación
- un costo base variable que es proporcional al tamaño de la pizza
- un costo adicional por cada ingrediente extra.
Por simplicidad se supone que cada ingrediente extra tiene el mismo costo por unidad de área.
15) Diseñar un pseudocódigo que calcule el promedio ponderado para alumno del Tecnológico Universitario de Tecnologías de la Información . El cálculo se hace de la siguiente forma:
- Se multiplica cada calificación por los créditos de cada materia
- El resultado anterior se suma con los resultados de todas las materias, por separado se suman los créditos de cada materia y finalmente se divide la suma de todas las materias por sus respectivos créditos, entre la suma de todos los créditos.
16) Calcule la suma de los términos de la serie FIBONACCI cuyos valores se encuentran entre 100 y 10,000.
17) Calcule exactamente el numero de días vividos por una persona hasta la fecha.
Contemplar los años bisiestos.
jueves, noviembre 21
Know That Which You Test
Someone recently related to me his experience using the new Microsoft Robotics Studio.
He loaded it up and proceeded through one of the tutorials. To make
sure he understood, he typed everything in instead of cutting and
pasting the sample code. After doing so, he compiled and ran the
results. It worked! It did exactly what it was supposed to. The only
problem--he didn't understand anything he had typed. He went through
the process of typing in the lines of code, but didn't understand what
they really meant. Sometimes testers do the same thing. It is easy to
"test" something without actually understanding it. Doing so is
dangerous. It lulls us into a false sense of security. We think we've
done a good job testing the product when in reality we've only scratched
the surface.
Being a good tester requires understanding not just the language we're writing the tests in, but also what is going on under the covers. Black-box testing can be useful, but without a sense of what is happening inside, testing can only be very naive. Without breaking the surface, it is nearly impossible to understand what the equivalency classes are. It is hard to find the corner cases or the places where errors are most likely to happen. It's also very easy to miss a critical path because it wasn't apparent from the API.
There are three practices which help to remedy this. First, program in the same language as whatever is being tested. A person writing tests written in C# against a COM interface will have a hard time beginning to understand the infrastructure beneath the interface. It can also be difficult to understand the frailties of a language different than the one being coded in. Each language has different weaknesses. Thinking about the weaknesses of C++ will blind a person to the weaknesses of Perl. Second, use code coverage data to help guide testing. Examining code coverage reports can help uncover places that have been missed. If possible, measure coverage against each test case. Validate that each new case adds to the coverage. If it doesn't, the case is probably covering the same equivalency class as another test. Third, and perhaps most importantly, become familiar with the code being testing. Read the code. Read the specs. Talk to the developers.
http://blogs.msdn.com/b/steverowe/archive/2008/04/21/know-that-which-you-test.aspx
Being a good tester requires understanding not just the language we're writing the tests in, but also what is going on under the covers. Black-box testing can be useful, but without a sense of what is happening inside, testing can only be very naive. Without breaking the surface, it is nearly impossible to understand what the equivalency classes are. It is hard to find the corner cases or the places where errors are most likely to happen. It's also very easy to miss a critical path because it wasn't apparent from the API.
There are three practices which help to remedy this. First, program in the same language as whatever is being tested. A person writing tests written in C# against a COM interface will have a hard time beginning to understand the infrastructure beneath the interface. It can also be difficult to understand the frailties of a language different than the one being coded in. Each language has different weaknesses. Thinking about the weaknesses of C++ will blind a person to the weaknesses of Perl. Second, use code coverage data to help guide testing. Examining code coverage reports can help uncover places that have been missed. If possible, measure coverage against each test case. Validate that each new case adds to the coverage. If it doesn't, the case is probably covering the same equivalency class as another test. Third, and perhaps most importantly, become familiar with the code being testing. Read the code. Read the specs. Talk to the developers.
http://blogs.msdn.com/b/steverowe/archive/2008/04/21/know-that-which-you-test.aspx
lunes, noviembre 18
Severity vs. Priority of a Bug
This week the subject came up again at a customer: “why do we need a separate bug field for Priority and Severity…”?
To make a long story short, the Dev Lead kept saying that he only looks at the Priority field and so we shouldn’t waste time writing down the Severity; then (to emphasize his point) he said that 90% of the time Priority and Severity have the same value and where they don’t it was only since the QA wanted to exaggerate the severity of some Bugs…
Without getting into the outcome of the discussion, I think that in most projects Priority and Severity should be 2 separate fields.
1. Severity refers to the Bug and how it affects the User’s interaction with the Application. Priority refers to the Project and how urgent it is to solve the Bug in the context of the work been done.
2. Severity is objectively set based on the direct and indirect repercussions of the bug, together with the probability of its occurrence. Priority is set based on changing project factors such as where is development and QA focused at the present time, how many more defects do we think we will fix before release, how important is this bug for a specific customer or objective, etc.
3. Severity is usually a static field, the only reason to modify it would be if we learn something new about the bug (such as possible workarounds, additional user scenarios, etc), or if the functionality of the application changes in ways that affects the bug.
Priority should be dynamic, to be revised and updated as the project progresses and we want to shift the focus of our efforts into specific product areas, and as we start reaching the end of the schedule and we need to make sacrifices about what will be fixed for the current version and what will be pushed to future ones.
The Priority of a bug should be set and modified in agreement by the project stakeholders based on the strategic and tactical decisions of the project. In most cases, this is done during a regular (daily, weekly, etc) meeting where they review and evaluate the open bugs in the system.
An additional gain of correctly working with both fields is that as we start a new project and we need to review all the bugs left opened from the previous one we have a way to categorize and organize our list based on its objective severity.
Having said all the above in some cases, and specially on small or simple projects, one field will do for both values. This happens mainly when all bugs are fixed based on their Severity and thus Priority becomes redundant.
Regardless of how you organize your Defects and/or your Project. You need to make sure to capture as much information for the bug as possible. This will help you in your present project, and it will also provide you with valuable information for future ones.
http://qablog.practitest.com/2008/10/severity-vs-priority-of-a-bug/
To make a long story short, the Dev Lead kept saying that he only looks at the Priority field and so we shouldn’t waste time writing down the Severity; then (to emphasize his point) he said that 90% of the time Priority and Severity have the same value and where they don’t it was only since the QA wanted to exaggerate the severity of some Bugs…
Without getting into the outcome of the discussion, I think that in most projects Priority and Severity should be 2 separate fields.
1. Severity refers to the Bug and how it affects the User’s interaction with the Application. Priority refers to the Project and how urgent it is to solve the Bug in the context of the work been done.
2. Severity is objectively set based on the direct and indirect repercussions of the bug, together with the probability of its occurrence. Priority is set based on changing project factors such as where is development and QA focused at the present time, how many more defects do we think we will fix before release, how important is this bug for a specific customer or objective, etc.
3. Severity is usually a static field, the only reason to modify it would be if we learn something new about the bug (such as possible workarounds, additional user scenarios, etc), or if the functionality of the application changes in ways that affects the bug.
Priority should be dynamic, to be revised and updated as the project progresses and we want to shift the focus of our efforts into specific product areas, and as we start reaching the end of the schedule and we need to make sacrifices about what will be fixed for the current version and what will be pushed to future ones.
The Priority of a bug should be set and modified in agreement by the project stakeholders based on the strategic and tactical decisions of the project. In most cases, this is done during a regular (daily, weekly, etc) meeting where they review and evaluate the open bugs in the system.
An additional gain of correctly working with both fields is that as we start a new project and we need to review all the bugs left opened from the previous one we have a way to categorize and organize our list based on its objective severity.
Having said all the above in some cases, and specially on small or simple projects, one field will do for both values. This happens mainly when all bugs are fixed based on their Severity and thus Priority becomes redundant.
Regardless of how you organize your Defects and/or your Project. You need to make sure to capture as much information for the bug as possible. This will help you in your present project, and it will also provide you with valuable information for future ones.
http://qablog.practitest.com/2008/10/severity-vs-priority-of-a-bug/
Stop being a NON-Technical Tester!
A short while ago I posted an open question on twitter:
“Do tester need to be as technical as programmer
to be successful at their jobs?”
I got plenty of answers, so I will only post some of them representing the main opinions threads:
@TestAndAnalysis - Testing is a technical discipline that is different to programming and testers add a lot of value to projects
@huibschoots – No! It depends on the context they work in. But in general they need to have some basic technical skills (or the will to learn)
@datoon83 – I’d say that all people involved in the delivery need to talk 1 language – that of the domain and customers!
@klyr – Technical and non-technical testers have a different approach to testing, and will find different bugs.
@sgershon – Certainly do. Not sure about “more/less technical” as programmers, possibly they have to be “differently technical” than them.
@halperinko – @sgershon @joelmonte I normally look at it as in depth knowledge for devs, vs. System-wise knowledge for testers. (Some don’t follow rules)
There were also a couple of tweeps who replied with blog posts of their own sharing their opinion on the subject.
@diamontip – my answer – do tester need to be as technical as programmers to be successful at their jobs? bit.ly/v5vcX
and
@adampknight – I personally dislike calling testers “technical” wrote about it here bit.ly/tVHDOB
To all the tweeps above and those I missed, thanks for the great feedback!
But as you surely guessed I have my own opinion on the subject and I want to share it with you, so here it goes…
Specially
after reading Adam’s post I feel the need to explain what do I mean by
technical, or better yet how do I differentiate a Technical Tester from a
Non-Technical Tester. (If you read my previous blogs on “Why are some tester not really Professional Testers” then you should already have an idea…)
A Technical Tester is not afraid of doing most of the following stuff on a regular basis as part of his job (without any specific order):
- Understand the architecture of the product he is testing,
including the pros & cons of the specific design, as well as the risks linked to each of the components and interfaces in the product.
He then uses this information to plan his testing strategy, to execute his tests and find the hidden issues, and also to provide visibility to his team regarding the risks involved in developing a specific feature or making a given change to the system.
- Review the code he needs to test.
He can do this on a number of levels, starting from going only over the names of the files that were changed, and all the way to reviewing the code itself. This information will provide valuable inputs to help decide what needs to be tested and how, as well as to find things about the changes that might have been missed by the developer or the documentation.
BTW, by code I mean SQL queries, scripts, configuration files, etc.
- Work with scripts & tools to help his work.
A
technical tester should be able to create (or at least “play”) with
scripts to help him run repetitive tests such as sanity or smoke, and
tasks such as configurations, installation, setups, etc.
He should also be able to work with free automation tools such as Selenium or WATIR (or any of the paid ones like QTP, SeeTest, TestComplete, etc) to create and run test scripts that will increase the stability of the product in development, and over time save time…
- Be up to date with the technical aspects of his infrastructure
(e.g. browsers, databases, languages, etc)
He should read the latest updates on all aspects of his infrastructure that may have an effect on his work. For example new updates to his O/S matrix, known issues with the browsers supported by his product, updates to external products they integrate, etc.
With the help of Google alerts and by subscribing to a couple of newsletters anyone can do this by reading 5 to 10 email 2 or 3 times a week. The value gained from becoming an independent source of knowledge greatly exceeds the time invested in the efforts.
- Is able to troubleshoot issues from Logs or other System Feeds.
He is aware of all the logs and feeds available in his system, and uses them to investigate more about any issue or strange behavior.
This information is helpful during testing to provide more information than simply writing “there is a bug with functionality X”. And it will be critical if he is called to work on a customer bug, where he needs to understand complex issues quickly and without access to all the information.
In addition to the above, a technical tester should also be able to:
- Provide feedback and run the unit tests created by his programmer peers.
- Run SQL Queries on the DB directly to help verify his testing results.
- Install and configure the system he is testing.
etc.
It may sound like this, but actually it’s not!
As testers we work on projects that revolve around Software, Hardware, and/or Embedded products. The only way to do a good job in testing them is to have a deep understanding of both angles: technical and functional.
This doesn’t mean that you need replace or have the same technical dept as your developers, or surpass your Product Marketing’s knowledge of your users.
You need to achieve a balance, where you have “enough” knowledge and understanding of both these areas in order to do your job as a tester, or rephrasing the tweet from @halperinko – as testers we should achieve system-wide knowledge, as opposed to the in-dept knowledge required from the developers or the product marketing guys.
Like in many other situations, the best answer to how technical do you need to be is: “It Depends…”
You should be at least technical enough to do your job effectively and to talk the same language with the rest of your programming and testing peers.
What do I mean by that?
If you work on a software development firm then you should understand enough of the languages used by your developers to be able to read the code and understand their changes. If you work on a heavily DB-related project then you need to understand enough of SQL and database management. If you work on a Website development firm then you should know enough CSS, HTML and JS, and so it goes…
If you like testing and you are good at it, why should you quit? On the other hand, this is a great opportunity to improve your work and (as @diamontip wrote on his blog) increase your market value as a tester
And the best part of it is… it’s not very hard to become a more
technical tester! Just start by asking questions, searching the web,
reading books, etc.
I’m also confident that if you show the potential to increase the value of your current work to your manager, he won’t mind you investing sometime during your day to learn these new trades (as long as you manage to explain why this is also good for him!).
So, stop making excuses for not been technical enough. Just make a decision (or a New Year’s resolution…) to start working on improving your technical skills!
Go ahead and get rid of the NON-Technical Tester in you!
It will be worth your time and make your job more interesting and satisfying.
http://qablog.practitest.com/2011/12/stop-being-a-non-technical-tester/
“Do tester need to be as technical as programmerto be successful at their jobs?”
@TestAndAnalysis - Testing is a technical discipline that is different to programming and testers add a lot of value to projects
@huibschoots – No! It depends on the context they work in. But in general they need to have some basic technical skills (or the will to learn)
@datoon83 – I’d say that all people involved in the delivery need to talk 1 language – that of the domain and customers!
@klyr – Technical and non-technical testers have a different approach to testing, and will find different bugs.
@sgershon – Certainly do. Not sure about “more/less technical” as programmers, possibly they have to be “differently technical” than them.
@halperinko – @sgershon @joelmonte I normally look at it as in depth knowledge for devs, vs. System-wise knowledge for testers. (Some don’t follow rules)
There were also a couple of tweeps who replied with blog posts of their own sharing their opinion on the subject.
@diamontip – my answer – do tester need to be as technical as programmers to be successful at their jobs? bit.ly/v5vcX
and
@adampknight – I personally dislike calling testers “technical” wrote about it here bit.ly/tVHDOB
To all the tweeps above and those I missed, thanks for the great feedback!
But as you surely guessed I have my own opinion on the subject and I want to share it with you, so here it goes…
My definition of Technical
Specially
after reading Adam’s post I feel the need to explain what do I mean by
technical, or better yet how do I differentiate a Technical Tester from a
Non-Technical Tester. (If you read my previous blogs on “Why are some tester not really Professional Testers” then you should already have an idea…)A Technical Tester is not afraid of doing most of the following stuff on a regular basis as part of his job (without any specific order):
- Understand the architecture of the product he is testing,
including the pros & cons of the specific design, as well as the risks linked to each of the components and interfaces in the product.
He then uses this information to plan his testing strategy, to execute his tests and find the hidden issues, and also to provide visibility to his team regarding the risks involved in developing a specific feature or making a given change to the system.
- Review the code he needs to test.
He can do this on a number of levels, starting from going only over the names of the files that were changed, and all the way to reviewing the code itself. This information will provide valuable inputs to help decide what needs to be tested and how, as well as to find things about the changes that might have been missed by the developer or the documentation.
BTW, by code I mean SQL queries, scripts, configuration files, etc.
- Work with scripts & tools to help his work.
A
technical tester should be able to create (or at least “play”) with
scripts to help him run repetitive tests such as sanity or smoke, and
tasks such as configurations, installation, setups, etc.He should also be able to work with free automation tools such as Selenium or WATIR (or any of the paid ones like QTP, SeeTest, TestComplete, etc) to create and run test scripts that will increase the stability of the product in development, and over time save time…
- Be up to date with the technical aspects of his infrastructure
(e.g. browsers, databases, languages, etc)
He should read the latest updates on all aspects of his infrastructure that may have an effect on his work. For example new updates to his O/S matrix, known issues with the browsers supported by his product, updates to external products they integrate, etc.
With the help of Google alerts and by subscribing to a couple of newsletters anyone can do this by reading 5 to 10 email 2 or 3 times a week. The value gained from becoming an independent source of knowledge greatly exceeds the time invested in the efforts.
- Is able to troubleshoot issues from Logs or other System Feeds.
He is aware of all the logs and feeds available in his system, and uses them to investigate more about any issue or strange behavior.
This information is helpful during testing to provide more information than simply writing “there is a bug with functionality X”. And it will be critical if he is called to work on a customer bug, where he needs to understand complex issues quickly and without access to all the information.
In addition to the above, a technical tester should also be able to:
- Provide feedback and run the unit tests created by his programmer peers.
- Run SQL Queries on the DB directly to help verify his testing results.
- Install and configure the system he is testing.
etc.
Sounds like Superman or MacGyver?
It may sound like this, but actually it’s not!As testers we work on projects that revolve around Software, Hardware, and/or Embedded products. The only way to do a good job in testing them is to have a deep understanding of both angles: technical and functional.
This doesn’t mean that you need replace or have the same technical dept as your developers, or surpass your Product Marketing’s knowledge of your users.
You need to achieve a balance, where you have “enough” knowledge and understanding of both these areas in order to do your job as a tester, or rephrasing the tweet from @halperinko – as testers we should achieve system-wide knowledge, as opposed to the in-dept knowledge required from the developers or the product marketing guys.
Is it black and white?
This time quoting “Cokolwiek” who commented on one of my latest posts, “Not everything is black and white”. Meaning there is no standard to define how technical should a tester be on every project and product.Like in many other situations, the best answer to how technical do you need to be is: “It Depends…”
You should be at least technical enough to do your job effectively and to talk the same language with the rest of your programming and testing peers.
What do I mean by that?
If you work on a software development firm then you should understand enough of the languages used by your developers to be able to read the code and understand their changes. If you work on a heavily DB-related project then you need to understand enough of SQL and database management. If you work on a Website development firm then you should know enough CSS, HTML and JS, and so it goes…
So if I am not Technical enough, should I quit testing???
Definitely not!If you like testing and you are good at it, why should you quit? On the other hand, this is a great opportunity to improve your work and (as @diamontip wrote on his blog) increase your market value as a tester
And the best part of it is… it’s not very hard to become a more
technical tester! Just start by asking questions, searching the web,
reading books, etc.I’m also confident that if you show the potential to increase the value of your current work to your manager, he won’t mind you investing sometime during your day to learn these new trades (as long as you manage to explain why this is also good for him!).
So, stop making excuses for not been technical enough. Just make a decision (or a New Year’s resolution…) to start working on improving your technical skills!
Go ahead and get rid of the NON-Technical Tester in you!
It will be worth your time and make your job more interesting and satisfying.
http://qablog.practitest.com/2011/12/stop-being-a-non-technical-tester/
jueves, noviembre 14
The Test Servant
f testing is a service, what does that make testers?
I’ve heard much about the definition of testing being a service to the project, or at least that this should be the definition of testing, and I agree. Most of this comes from what I’ve heard and read from James Bach and Michael Bolton as part of the Rapid Testing courses.
I’d like to extend this metaphor a step further though. What do you call the person who performs a service? The word service is tossed around so often in the software world that it’s lost a lot of meaning and is easy on the ears. Once the form is changed to “servant†though, you might get some interesting responses. “Me, a servant?â€
At the last STAR West conference, Lee Copeland jokingly asked the single people in his audience to try an experiment at the Lost Bar there at the Disneyland Hotel. My paraphrase of what he said was, “Let’s see who gets more dates, the people who introduce themselves as a “testerâ€, or those who call themselves a “QA Analystâ€. No findings have yet been reported, but I hope to see the results published in a highly detailed graph this year!
This illustrates a point though. I think as testers, we often suffer from genius envy. We need to have inflated titles because we think we must always keep justifying what we do as important. We come up with elaborate plans and documentation that are often unnecessary in our context, just so we can look more impressive.
I had a boss once who liked to tell me that I “suffer from being a nice guy.†This used to bother me, but now I take it as a compliment. Does software really need more egos? Does jockeying for position and pulling the CYA routine over and over really make a better product? What if we got ourselves out of the way and started making decisions based solely on what’s best for the stakeholders, and dare I say it, the other people we work alongside? Somebody has to take the first step, and we testers are prime candidates to be the leaders for a movement like this, because we often have smaller egos already.
I’ll be starting a new job next week. Conventional wisdom says I need to come in and make a splash. Show what an expert I am, assert my dominance, and spout off a bunch of terms nobody else understands to make myself sound knowledgeable. I’d like to think that this time though, it’s not about me. It’s only about how I can serve the people I work with, and the people who have an interest in the software I’m helping to create.
I’ve heard Michael Bolton say many times that it’s not our job to be the gatekeepers for quality, and I agree. I think it’s a mistake to try to assert more and more power over the release.
We serve.
We’re like Jiminy Cricket whispering in the ear of Pinocchio. “Here’s what you need to know, watch out for thisâ€. If Pinocchio decides to run away, get turned into a donkey, and swallowed by a whale, all we can do is say “We served you the best we couldâ€, and continue our service as long as we’re part of the team, let the rest of the chips fall where they may. To stride in with a haughty spirit, demanding respect, jockeying with your project peers for control is folly, and only goes before a fall.
http://testingreflections.com/node/7231
I’ve heard much about the definition of testing being a service to the project, or at least that this should be the definition of testing, and I agree. Most of this comes from what I’ve heard and read from James Bach and Michael Bolton as part of the Rapid Testing courses.
I’d like to extend this metaphor a step further though. What do you call the person who performs a service? The word service is tossed around so often in the software world that it’s lost a lot of meaning and is easy on the ears. Once the form is changed to “servant†though, you might get some interesting responses. “Me, a servant?â€
At the last STAR West conference, Lee Copeland jokingly asked the single people in his audience to try an experiment at the Lost Bar there at the Disneyland Hotel. My paraphrase of what he said was, “Let’s see who gets more dates, the people who introduce themselves as a “testerâ€, or those who call themselves a “QA Analystâ€. No findings have yet been reported, but I hope to see the results published in a highly detailed graph this year!
This illustrates a point though. I think as testers, we often suffer from genius envy. We need to have inflated titles because we think we must always keep justifying what we do as important. We come up with elaborate plans and documentation that are often unnecessary in our context, just so we can look more impressive.
I had a boss once who liked to tell me that I “suffer from being a nice guy.†This used to bother me, but now I take it as a compliment. Does software really need more egos? Does jockeying for position and pulling the CYA routine over and over really make a better product? What if we got ourselves out of the way and started making decisions based solely on what’s best for the stakeholders, and dare I say it, the other people we work alongside? Somebody has to take the first step, and we testers are prime candidates to be the leaders for a movement like this, because we often have smaller egos already.
I’ll be starting a new job next week. Conventional wisdom says I need to come in and make a splash. Show what an expert I am, assert my dominance, and spout off a bunch of terms nobody else understands to make myself sound knowledgeable. I’d like to think that this time though, it’s not about me. It’s only about how I can serve the people I work with, and the people who have an interest in the software I’m helping to create.
I’ve heard Michael Bolton say many times that it’s not our job to be the gatekeepers for quality, and I agree. I think it’s a mistake to try to assert more and more power over the release.
We serve.
We’re like Jiminy Cricket whispering in the ear of Pinocchio. “Here’s what you need to know, watch out for thisâ€. If Pinocchio decides to run away, get turned into a donkey, and swallowed by a whale, all we can do is say “We served you the best we couldâ€, and continue our service as long as we’re part of the team, let the rest of the chips fall where they may. To stride in with a haughty spirit, demanding respect, jockeying with your project peers for control is folly, and only goes before a fall.
http://testingreflections.com/node/7231
What is client-server and web based testing and how to test these applications
Question:
What is the difference between client-server testing and web based testing and what are things that we need to test in such applications?
Ans:
Projects are broadly divided into two types of:
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.
The application launched on front-end will be having forms and reports which will be monitoring and manipulating data
E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase
The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing
WEB TESTING
This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.
The applications accessible in browser would be developed in HTML, DHTML, XML, JavaScript etc. (We can monitor through these applications)
Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed)
The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in the database available on the DB server)
The tests performed on these types of applications would be
- User interface testing
- Functionality testing
- Security testing
- Browser compatibility testing
- Load / stress testing
- Interoperability testing/intersystem testing
- Storage and data volume testing
A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-> webserver (manipulates data) [manipulations are done using programming languages or scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server (stores data) [data storage and retrieval is done using databases like oracle, sql server, sybase, mysql].
The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations, services levels, order of functionality, links, content of web page & backend coverage’s
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing
A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]
The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop applications:
Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only
Client/Server application:
1. Application runs in two or more machines
2. Application is a menu-driven
3. Connected mode (connection exists always until logout)
4. Limited number of users
5. Less number of network issues when compared to web app.
Web application:
1. Application runs in two or more machines
2. URL-driven
3. Disconnected mode (state less)
4. Unlimited number of users
5. Many issues like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues etc.
As per difference in both the applications come where, how to access the resources. In client server once connection is made it will be in state on connected, whereas in case of web testing http protocol is stateless, then there comes logic of cookies, which is not in client server.
For client server application users are well known, whereas for web application any user can login and access the content, he/she will use it as per his intentions.
So, there are always issues of security and compatibility for web application.
Over to you: On which application are you working? Desktop, client-server or web application? What is your experience while testing these applications?
http://www.softwaretestinghelp.com/what-is-client-server-and-web-based-testing-and-how-to-test-these-applications/
What is the difference between client-server testing and web based testing and what are things that we need to test in such applications?
Ans:
Projects are broadly divided into two types of:
- 2 tier applications
- 3 tier applications
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.
The application launched on front-end will be having forms and reports which will be monitoring and manipulating data
E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase
The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing
WEB TESTING
This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.
The applications accessible in browser would be developed in HTML, DHTML, XML, JavaScript etc. (We can monitor through these applications)
Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed)
The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in the database available on the DB server)
The tests performed on these types of applications would be
- User interface testing
- Functionality testing
- Security testing
- Browser compatibility testing
- Load / stress testing
- Interoperability testing/intersystem testing
- Storage and data volume testing
A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-> webserver (manipulates data) [manipulations are done using programming languages or scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server (stores data) [data storage and retrieval is done using databases like oracle, sql server, sybase, mysql].
The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations, services levels, order of functionality, links, content of web page & backend coverage’s
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing
A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]
The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop applications:
Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only
Client/Server application:
1. Application runs in two or more machines
2. Application is a menu-driven
3. Connected mode (connection exists always until logout)
4. Limited number of users
5. Less number of network issues when compared to web app.
Web application:
1. Application runs in two or more machines
2. URL-driven
3. Disconnected mode (state less)
4. Unlimited number of users
5. Many issues like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues etc.
As per difference in both the applications come where, how to access the resources. In client server once connection is made it will be in state on connected, whereas in case of web testing http protocol is stateless, then there comes logic of cookies, which is not in client server.
For client server application users are well known, whereas for web application any user can login and access the content, he/she will use it as per his intentions.
So, there are always issues of security and compatibility for web application.
Over to you: On which application are you working? Desktop, client-server or web application? What is your experience while testing these applications?
http://www.softwaretestinghelp.com/what-is-client-server-and-web-based-testing-and-how-to-test-these-applications/
SQL Injection – How to Test Web Applications against SQL Injection Attacks
Many
applications use some type of a database. An application under test
might have a user interface that accepts user input that is used to
perform the following tasks:
1. Show the relevant stored data
to the user e.g. the application checks the credentials of the user
using the log in information entered by the user and exposes only the
relevant functionality and data to the user
2.
Save the data entered by the user to the database e.g. once the user
fills up a form and submits it, the application proceeds to save the
data to the database; this data is then made available to the user in
the same session as well as in subsequent sessions
Some of the
user inputs might be used in framing SQL statements that are then
executed by the application on the database. It is possible for an
application NOT to handle the inputs given by the user properly. If this
is the case, a malicious user could provide unexpected inputs
to the application that are then used to frame and execute SQL
statements on the database. This is called SQL injection. The consequences of such an action could be alarming.
The following things might result from SQL injection:
1. The user could log in to the application as another user, even as an administrator.
2. The
user could view private information belonging to other users e.g.
details of other users’ profiles, their transaction details etc.
3. The user could change application configuration information and the data of the other users.
4. The user could modify the structure of the database; even delete tables in the application database.
5. The user could take control of the database server and execute commands on it at will.
Since
the consequences of allowing the SQL injection technique could be
severe, it follows that SQL injection should be tested during the
security testing of an application. Now with an overview of the SQL
injection technique, let us understand a few practical examples of SQL
injection.
Important: The SQL injection problem should be tested only in the test environment.
If
the application has a log in page, it is possible that the application
uses a dynamic SQL such as statement below. This statement is expected
to return at least a single row with the user details from the Users
table as the result set when there is a row with the user name and
password entered in the SQL statement.
SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & “’;”
If
the tester would enter John as the strUserName (in the textbox for user
name) and Smith as strPassword (in the textbox for password), the above
SQL statement would become:
SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’;
If the tester would enter John’– as strUserName and no strPassword, the SQL statement would become:
SELECT * FROM Users WHERE User_Name = ‘John’– AND Password = ‘Smith’;
Note
that the part of the SQL statement after John is turned into a comment.
If there were any user with the user name of John in the Users table,
the application could allow the tester to log in as the user John. The
tester could now view the private information of the user John.
What
if the tester does not know the name of any existing user of the
application? In such a case, the tester could try common user names like
admin, administrator and sysadmin. If none of these users exist in the
database, the tester could enter John’ or ‘x’=’x as strUserName and
Smith’ or ‘x’=’x as strPassword. This would cause the SQL statement to
become like the one below.
SELECT * FROM Users WHERE User_Name = ‘John’ or ‘x’='x’ AND Password = ‘Smith’ or ‘x’=’x’;
Since ‘x’=’x’ condition is always true, the result set would consist
of all the rows in the Users table. The application could allow the
tester to log in as the first user in the Users table.
Important:
The tester should request the database administrator or the developer
to copy the table in question before attempting the following SQL
injection.
If the tester would enter John’; DROP
table users_details;’—as strUserName and anything as strPassword, the
SQL statement would become like the one below.
SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = ‘Smith’;
This statement could cause the table “users_details” to be permanently deleted from the database.
Though
the above examples deal with using the SQL injection technique only the
log in page, the tester should test this technique on all the pages of
the application that accept user input in textual format e.g. search
pages, feedback pages etc.
SQL injection might be possible in
applications that use SSL. Even a firewall might not be able to protect
the application against the SQL injection technique.
I have tried
to explain the SQL injection technique in a simple form. I would like to
re-iterate that SQL injection should be tested only in a test
environment and not in the development environment, production
environment or any other environment. Instead of manually testing
whether the application is vulnerable to SQL injection or not, one could
use a web vulnerability scanner that checks for SQL injection.
http://www.softwaretestinghelp.com/sql-injection-%E2%80%93-how-to-test-application-for-sql-injection-attacks/
lunes, noviembre 11
Principles of Good Bug Reporting
This week I heard a developer commenting on a couple of testers
saying that he was annoyed by their low level of professionalism.
Since I actually know both of them I could understand his comment regarding one of them, but the second one is actually a great tester…
So I asked the developer and he told me that whenever he got a bug from the second tester he was always missing something. Sometimes it was vague steps to reproduce, other times it was attachments with captures of the error messages, and on top of that every bug this guy reported was ALWAYS urgent – never correctly prioritized.
Reporting a good bug is not hard, but many times we do it hurriedly and without putting our full attention into it. As in the case above, the results of a badly written bug are 3-fold:
1. You waste your time reporting a bug incorrectly and most certainly will need to re-write it.
2. You waste the time of the other people reviewing the bug and trying to make sense of what you wrote.
3. You harm your good name as a QA Professional, by writing a bug that is either correct but incomprehensible or altogether wrong.
What are the components of a Good Bug?
1. Short and precise title
Each bug should have its individual title. The title gives us the opportunity to quickly understand and remember what the bug is all about.
The title cannot be generic (e.g. Error on Application), or too long. It should be one sentence, providing the highlights of the issue and the way to understand how a user could run into it.
Examples of good and bad titles are (taken from actual bugs!): “Unable to log into the system when username contains foreign characters” and not “User cannot work in Chinese”; or “Log rotation doesn’t work, grows until the disc runs out of space” and not “Server crashes due to log size”.
2. Concise but complete description: Steps to reproduce, consequences of the bug, and suggested behavior
The description of the bug is where the tester can express his “artistic sense” and write what he thinks will help stakeholders to understand and handle the bug.
The most important things to include in the bug are:
i. Steps to reproduce – with all the steps, sometimes even the trivial ones, just to make sure people who need to judge the bug and are not experts in the system can understand it correctly. Make sure to include also the data required to reproduce it (e.g account names, strings, etc).
ii. Consequences of the bug – what will happen to the user if/when she runs into it.
Here again, sometimes it is trivial but other times it isn’t and you need to make sure this information reaches the person who is reading your report.
iii. Suggested/Expected behavior – specially when you are reporting a bug that doesn’t create data-loss or other catastrophes, but on the other hand makes the application uncomfortable or unusable to the end-user.
The description is the place where you can add all the information that you cannot write on any other place, but on the other hand you cannot write to much into it (and expect people to read it) or write irrelevant information.
As a rule of thumb, 3 to 10 lines should be enough in 80% of the cases.
3. Good attachments
Specially true when you need to show GUI malfunctions, error messages, and/or log files that compliment the description of your bug.
One thing to take into account is to provide ONLY the relevant information in your attachment. This means that if you have a long log file attach only what you know is relevant and not all of it, if you have a screen capture cut down the area that is relevant and not all the desktop if it is unnecessary, etc
Use also zip files and compressed formats in order to save space.
4. Complete definition of the categorizing fields
If you work with a Structured Bug tracking system you will have fields that categorize your issues. Examples of these fields are Module, Infrastructure, Browser, etc.
This fields will help your team to categorize and in some cases reproduce the bug correctly. The only reasons not to fill this fields laziness or carelessness.
5. Correct Severity & Priority Another big Tester Sin is to over prioritize your bugs. Obviously you are happy you found a bug and you want it fixed, but giving it the wrong severity will only make the person in charge of the bug angry and it will lower your chances of having this bug fixed.
You will also automatically harm your name with this person and from now on she will be skeptic whenever you report a critical issue (remember “the boy who cried wolf”…)
If your problem is that you are not sure what severity to give your bug you can either consult with a fellow tester or developer, or ask you lead for a table describing the cases and standards used in your company for this purpose.
6. Follow-up and comment.
You should continue following up on your bugs, and providing comments when necessary. This is specially true when a developer or other stakeholder does not understand the bug, and either rejects it or delays it.
You are not the owner of your bugs, but you certainly have say on them and you should make sure that say is heard.
Depending on your company this last point may not apply, but I think in most companies it does.
———
To finalize, writing a bug is not Rocket Science but it requires you to concentrate on what you do and to make sure you don’t abuse or become careless with what you are doing. Just put your head into it…
Since I actually know both of them I could understand his comment regarding one of them, but the second one is actually a great tester…
So I asked the developer and he told me that whenever he got a bug from the second tester he was always missing something. Sometimes it was vague steps to reproduce, other times it was attachments with captures of the error messages, and on top of that every bug this guy reported was ALWAYS urgent – never correctly prioritized.
Reporting a good bug is not hard, but many times we do it hurriedly and without putting our full attention into it. As in the case above, the results of a badly written bug are 3-fold:
1. You waste your time reporting a bug incorrectly and most certainly will need to re-write it.
2. You waste the time of the other people reviewing the bug and trying to make sense of what you wrote.
3. You harm your good name as a QA Professional, by writing a bug that is either correct but incomprehensible or altogether wrong.
What are the components of a Good Bug?
1. Short and precise title
Each bug should have its individual title. The title gives us the opportunity to quickly understand and remember what the bug is all about.
The title cannot be generic (e.g. Error on Application), or too long. It should be one sentence, providing the highlights of the issue and the way to understand how a user could run into it.
Examples of good and bad titles are (taken from actual bugs!): “Unable to log into the system when username contains foreign characters” and not “User cannot work in Chinese”; or “Log rotation doesn’t work, grows until the disc runs out of space” and not “Server crashes due to log size”.
2. Concise but complete description: Steps to reproduce, consequences of the bug, and suggested behavior
The description of the bug is where the tester can express his “artistic sense” and write what he thinks will help stakeholders to understand and handle the bug.
The most important things to include in the bug are:
i. Steps to reproduce – with all the steps, sometimes even the trivial ones, just to make sure people who need to judge the bug and are not experts in the system can understand it correctly. Make sure to include also the data required to reproduce it (e.g account names, strings, etc).
ii. Consequences of the bug – what will happen to the user if/when she runs into it.
Here again, sometimes it is trivial but other times it isn’t and you need to make sure this information reaches the person who is reading your report.
iii. Suggested/Expected behavior – specially when you are reporting a bug that doesn’t create data-loss or other catastrophes, but on the other hand makes the application uncomfortable or unusable to the end-user.
The description is the place where you can add all the information that you cannot write on any other place, but on the other hand you cannot write to much into it (and expect people to read it) or write irrelevant information.
As a rule of thumb, 3 to 10 lines should be enough in 80% of the cases.
3. Good attachments
Specially true when you need to show GUI malfunctions, error messages, and/or log files that compliment the description of your bug.
One thing to take into account is to provide ONLY the relevant information in your attachment. This means that if you have a long log file attach only what you know is relevant and not all of it, if you have a screen capture cut down the area that is relevant and not all the desktop if it is unnecessary, etc
Use also zip files and compressed formats in order to save space.
4. Complete definition of the categorizing fields
If you work with a Structured Bug tracking system you will have fields that categorize your issues. Examples of these fields are Module, Infrastructure, Browser, etc.
This fields will help your team to categorize and in some cases reproduce the bug correctly. The only reasons not to fill this fields laziness or carelessness.
5. Correct Severity & Priority Another big Tester Sin is to over prioritize your bugs. Obviously you are happy you found a bug and you want it fixed, but giving it the wrong severity will only make the person in charge of the bug angry and it will lower your chances of having this bug fixed.
You will also automatically harm your name with this person and from now on she will be skeptic whenever you report a critical issue (remember “the boy who cried wolf”…)
If your problem is that you are not sure what severity to give your bug you can either consult with a fellow tester or developer, or ask you lead for a table describing the cases and standards used in your company for this purpose.
6. Follow-up and comment.
You should continue following up on your bugs, and providing comments when necessary. This is specially true when a developer or other stakeholder does not understand the bug, and either rejects it or delays it.
You are not the owner of your bugs, but you certainly have say on them and you should make sure that say is heard.
Depending on your company this last point may not apply, but I think in most companies it does.
———
To finalize, writing a bug is not Rocket Science but it requires you to concentrate on what you do and to make sure you don’t abuse or become careless with what you are doing. Just put your head into it…
http://qablog.practitest.com/2008/12/principles-of-good-bug-reporting/
What Tests Belong in the BVTs?
BVTs or Build
Verification Tests are standard Microsoft parlance for the tests we run
every day to ensure that we didn't break anything important with our
checkins the day before. I've previously written about the importance
of keeping them clean.
Within the range of tests that consistently pass, which ones should be
in the BVT? BVT test failures should be something you're willing to act
on immediately. In other words, the failures must be important. Based
on that, here are some criteria:
http://blogs.msdn.com/b/steverowe/archive/2008/03/05/what-tests-belong-in-the-bvts.aspx
- Test major scenarios not minor ones. If major features are failing, they will be fixed right away. If a minor feature is failing, it should be noted, but may have to wait until later to be fixed.
- Test majority use cases, not corner cases. Tests for the interaction of 3 parts shouldn't be in the BVTs. Tests outside most user scenarios shouldn't be in the BVTs. While every book on testing says to test the boundary conditions, the BVTs may not be the place to do that. Instead, pick the most likely to be used values and scenarios.
- Run "positive" not "negative" tests. By that I mean, don't send out-of-bounds conditions or invalid values. These are valid tests and should definitely be run, but not in the BVTs. An API faulting when sent a null pointer should be fixed, but the fix can wait until next week.
http://blogs.msdn.com/b/steverowe/archive/2008/03/05/what-tests-belong-in-the-bvts.aspx
Ejercicios Diagrama de flujo - Propuestos 4
Cuarta serie de ejercicios propuestos para realizar diagramas de flujo.
Los demás ejercicios Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Ejemplo 1 Ejemplo 2 Ejemplo 3 Ejemplo 4 Ejemplo 5
1) En una tienda de descuento las personas que van a pagar el importe de su compra llegan a la caja y sacan una bolita de color, que les dirá que descuento tendrán sobre el total de su compra.
Determinar la cantidad que pagara cada cliente desde que la tienda abre hasta que cierra.
Se sabe que si el color de la bolita es roja el cliente obtendrá un 40% de descuento;
si es amarilla un 25% y si es blanca no obtendrá descuento.
2) En un supermercado una ama de casa pone en su carrito los artículos que va tomando de los estantes. La señora quiere asegurarse de que el cajero le cobre bien lo que ella ha comprado, por lo que cada vez que toma un articulo anota su precio junto con la cantidad de artículos iguales que ha tomado y determina cuanto dinero gastara en ese artículo.
A esto le suma lo que irá gastando en los demás artículos, hasta que decide que ya tomo todo lo que necesitaba.
Ayúdale a esta señora a obtener el total de sus compras.
3) Un teatro otorga descuentos según la edad del cliente. determinar la cantidad de dinero que el teatro deja de percibir por cada una de las categorías. Tomar en cuenta que los niños menores de 5 años no pueden entrar al teatro y que existe un precio único en los asientos.
Los descuentos se hacen tomando en cuenta el siguiente cuadro:
Edad y Descuento
Categoría 1 --- 5 - 14 --- 35 %
Categoría 2 --- 15 - 19 --- 25 %
Categoría 3 --- 20 - 45 --- 10 %
Categoría 4 --- 46 - 65 --- 25 %
Categoría 5 --- 66 en adelante --- 35 %
4) La presión, volumen y temperatura de una masa de aire se relacionan por la formula:
masa= presión * volumen .
0.37 * (temperatura + 460)
Calcular el promedio de masa de aire de los neumáticos de n vehículos que están en compostura en un servicio de alineación y balanceo.
Los vehículos pueden ser motocicletas o automóviles.
5) Determinar la cantidad semanal de dinero que recibirá cada uno de los N obreros de una empresa. Se sabe que cuando las horas que trabajo un obrero exceden de 40, el resto se convierte en horas extras que se pagan al doble de una hora normal, cuando no exceden de 8;
cuando las horas extras exceden de 8 se pagan las primeras 8 al doble de lo que se paga por una hora normal y el resto al triple.
6) En una granja se requiere saber alguna información para determinar el precio de venta por cada kilo de huevo. Es importante determinar el promedio de calidad de las N gallinas que hay en la granja.
La calidad de cada gallina se obtiene según la formula:
calidad = peso de la gallina * altura de la gallina
numero de huevos que pone
Finalmente para fijar el precio del kilo de huevo, se toma como base la siguiente tabla:
PRECIO TOTAL DE CALIDAD PESO POR KILO DE HUEVO
mayor o igual que 15 ---- 1.2 * promedio de calidad
mayor que 8 y menor que 15 ---- 1.00 * promedio de calidad
menor o igual que 8 ---- 0.80 * promedio de calidad
7) En la Cámara de Diputados se levanta una encuesta con todos los integrantes con el fin de determinar que porcentaje de los N diputados esta a favor del Tratado de Libre Comercio, qué porcentaje está en contra y qué porcentaje se abstiene de opinar.
8) Una persona que va de compras a la tienda “ALimentos el Habano, S.A.”, decide llevar un control sobre lo que va comprando, para saber la cantidad de dinero que tendrá que pagar al llegar a la caja. La tienda tiene una promoción del 20% de descuento sobre aquellos artículos cuya etiqueta sea roja. Determinar la cantidad de dinero que esta persona deberá pagar.
9) Un censador recopila ciertos datos aplicando encuestas para el ultimo Censo Nacional de Población y Vivienda.
Desea obtener de todas las personas que alcance a encuestar en un día, qué porcentaje tiene estudios de primaria, secundaria, carrera técnica, estudios profesionales y estudios de posgrado.
10) Un jefe de casilla desea determinar cuántas personas de cada una de las secciones que componen su zona asisten el día de las votaciones. Las secciones son: norte, sur y centro.
También desea determinar cual es la sección con mayor numero de votantes.
11) Un negocio de copias tiene un limite de producción diaria de 10 000 copias si el tipo de impresión es offset y de 50 000 si el tipo es estándar.
Si hay una solicitud de un el empleado tiene que verificar que las copias pendientes hasta el momento y las copias solicitadas no excedan del limite de producción.
Si el limite de producción se excediera el trabajo solicitado no podría ser aceptado.
El empleado necesita llevar un buen control de las copias solicitadas hasta el momento para decidir en forma rápida si los trabajos que se soliciten en el día se deben aceptar o no.
12) Calcular la suma siguiente: "100 + 98 + 96 + 94 + . . . + 0" en este orden.
13) Leer 50 calificaciones de un grupo de alumnos. Calcule y escriba el porcentaje de reprobados.
Tomando en cuenta que la calificación mínima aprobatoria es de 70.
14) Leer por cada alumno de Diseño de Algoritmos su numero de control y su calificación en cada una de las 5 unidades de la materia.
Al final que escriba el numero de control del alumno que obtuvo mayor promedio. Suponga que los alumnos tienen diferentes promedios.
15) Leer los 250,000 votos otorgados a los 3 candidatos a gobernador e imprimir el numero del candidato ganador y su cantidad de votos.
16) Suponga que tiene usted una tienda y desea registrar las ventas en su computadora. Diseñe un algoritmo que lea por cada cliente, el monto total de su compra.
Al final del día que escriba la cantidad total de ventas y el numero de clientes atendidos.
Los demás ejercicios Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Ejemplo 1 Ejemplo 2 Ejemplo 3 Ejemplo 4 Ejemplo 5
1) En una tienda de descuento las personas que van a pagar el importe de su compra llegan a la caja y sacan una bolita de color, que les dirá que descuento tendrán sobre el total de su compra.
Determinar la cantidad que pagara cada cliente desde que la tienda abre hasta que cierra.
Se sabe que si el color de la bolita es roja el cliente obtendrá un 40% de descuento;
si es amarilla un 25% y si es blanca no obtendrá descuento.
2) En un supermercado una ama de casa pone en su carrito los artículos que va tomando de los estantes. La señora quiere asegurarse de que el cajero le cobre bien lo que ella ha comprado, por lo que cada vez que toma un articulo anota su precio junto con la cantidad de artículos iguales que ha tomado y determina cuanto dinero gastara en ese artículo.
A esto le suma lo que irá gastando en los demás artículos, hasta que decide que ya tomo todo lo que necesitaba.
Ayúdale a esta señora a obtener el total de sus compras.
3) Un teatro otorga descuentos según la edad del cliente. determinar la cantidad de dinero que el teatro deja de percibir por cada una de las categorías. Tomar en cuenta que los niños menores de 5 años no pueden entrar al teatro y que existe un precio único en los asientos.
Los descuentos se hacen tomando en cuenta el siguiente cuadro:
Edad y Descuento
Categoría 1 --- 5 - 14 --- 35 %
Categoría 2 --- 15 - 19 --- 25 %
Categoría 3 --- 20 - 45 --- 10 %
Categoría 4 --- 46 - 65 --- 25 %
Categoría 5 --- 66 en adelante --- 35 %
4) La presión, volumen y temperatura de una masa de aire se relacionan por la formula:
masa= presión * volumen .
0.37 * (temperatura + 460)
Calcular el promedio de masa de aire de los neumáticos de n vehículos que están en compostura en un servicio de alineación y balanceo.
Los vehículos pueden ser motocicletas o automóviles.
5) Determinar la cantidad semanal de dinero que recibirá cada uno de los N obreros de una empresa. Se sabe que cuando las horas que trabajo un obrero exceden de 40, el resto se convierte en horas extras que se pagan al doble de una hora normal, cuando no exceden de 8;
cuando las horas extras exceden de 8 se pagan las primeras 8 al doble de lo que se paga por una hora normal y el resto al triple.
6) En una granja se requiere saber alguna información para determinar el precio de venta por cada kilo de huevo. Es importante determinar el promedio de calidad de las N gallinas que hay en la granja.
La calidad de cada gallina se obtiene según la formula:
calidad = peso de la gallina * altura de la gallina
numero de huevos que pone
Finalmente para fijar el precio del kilo de huevo, se toma como base la siguiente tabla:
PRECIO TOTAL DE CALIDAD PESO POR KILO DE HUEVO
mayor o igual que 15 ---- 1.2 * promedio de calidad
mayor que 8 y menor que 15 ---- 1.00 * promedio de calidad
menor o igual que 8 ---- 0.80 * promedio de calidad
7) En la Cámara de Diputados se levanta una encuesta con todos los integrantes con el fin de determinar que porcentaje de los N diputados esta a favor del Tratado de Libre Comercio, qué porcentaje está en contra y qué porcentaje se abstiene de opinar.
8) Una persona que va de compras a la tienda “ALimentos el Habano, S.A.”, decide llevar un control sobre lo que va comprando, para saber la cantidad de dinero que tendrá que pagar al llegar a la caja. La tienda tiene una promoción del 20% de descuento sobre aquellos artículos cuya etiqueta sea roja. Determinar la cantidad de dinero que esta persona deberá pagar.
9) Un censador recopila ciertos datos aplicando encuestas para el ultimo Censo Nacional de Población y Vivienda.
Desea obtener de todas las personas que alcance a encuestar en un día, qué porcentaje tiene estudios de primaria, secundaria, carrera técnica, estudios profesionales y estudios de posgrado.
10) Un jefe de casilla desea determinar cuántas personas de cada una de las secciones que componen su zona asisten el día de las votaciones. Las secciones son: norte, sur y centro.
También desea determinar cual es la sección con mayor numero de votantes.
11) Un negocio de copias tiene un limite de producción diaria de 10 000 copias si el tipo de impresión es offset y de 50 000 si el tipo es estándar.
Si hay una solicitud de un el empleado tiene que verificar que las copias pendientes hasta el momento y las copias solicitadas no excedan del limite de producción.
Si el limite de producción se excediera el trabajo solicitado no podría ser aceptado.
El empleado necesita llevar un buen control de las copias solicitadas hasta el momento para decidir en forma rápida si los trabajos que se soliciten en el día se deben aceptar o no.
12) Calcular la suma siguiente: "100 + 98 + 96 + 94 + . . . + 0" en este orden.
13) Leer 50 calificaciones de un grupo de alumnos. Calcule y escriba el porcentaje de reprobados.
Tomando en cuenta que la calificación mínima aprobatoria es de 70.
14) Leer por cada alumno de Diseño de Algoritmos su numero de control y su calificación en cada una de las 5 unidades de la materia.
Al final que escriba el numero de control del alumno que obtuvo mayor promedio. Suponga que los alumnos tienen diferentes promedios.
15) Leer los 250,000 votos otorgados a los 3 candidatos a gobernador e imprimir el numero del candidato ganador y su cantidad de votos.
16) Suponga que tiene usted una tienda y desea registrar las ventas en su computadora. Diseñe un algoritmo que lea por cada cliente, el monto total de su compra.
Al final del día que escriba la cantidad total de ventas y el numero de clientes atendidos.
Suscribirse a:
Entradas (Atom)