Untitled

.)AutoIT (Excel):

#include <Excel.au3>
#include <MsgBoxConstants.au3>
#include <GUIConstantsEx.au3>
GUICreate("Custom MsgBox", 210, 80)

GUICtrlCreateLabel("This Script will open Microsoft Excel !!!!", 10, 10)
$OKID = GUICtrlCreateButton("Ok", 10, 50, 50, 20)
$ExitID = GUICtrlCreateButton("Exit", 150, 50, 50, 20)
GUISetState() ;display the GUICreate

Do
	$msg = GUIGetMsg()
	Select
	Case $msg = $OKID

		Local $oExcel = _Excel_Open()

		Local $oWorkbook = _Excel_BookNew($oExcel)

		_Excel_RangeWrite($oWorkbook, Default, "Test", "A1")

		_Excel_BookSaveAs($oWorkbook, @TempDir & "\_Excel12.xls", Default, True)

		_Excel_RangeWrite($oWorkbook, Default, "2nd Test", "B1")

		_Excel_BookSave($oWorkbook)
	MsgBox($MB_SYSTEMMODAL, "Excel UDF: _Excel_BookSave Example 1", "Workbook has been successfully saved as '" & @TempDir & "\_Excel.xls'.")
	_Excel_Close($oExcel)
	$msg = $GUI_EVENT_CLOSE or $msg = $ExitID

	Case $msg = $ExitID
	  case $msg = $GUI_EVENT_CLOSE
		//MsgBox(0,"You Clicked on", "Close")
	EndSelect
Until $msg = $GUI_EVENT_CLOSE or $msg = $ExitID


.)Selenium Webdriver:
(Steps)

o.create new project-> Dynamice Web Project ->"name"-> Finish
 now create two webpages
o.Web content->new->HTML page
java file
o.java resources->new->package->class

providing the jars files:
o.Project name->right click->build path-> configuren build path ->add exteranal jar files -> apply and close
o. right click on program->run as->java application

(Code)

>App.java

package seleniumProject.SeleniumPoject;


import org.openqa.selenium.firefox.FirefoxDriver;

public class App {
	public static void main( String[] args )

    {
		System.setProperty("webdriver.gecko.driver", "C:\\Users\\Admin3\\Desktop\\geckodriver.exe");

         FirefoxDriver driver=new FirefoxDriver();

         driver.get("http://localhost:8080/elenium/index.html");

         String a=driver.getTitle();

         System.out.println(driver.getTitle());

         driver.findElementByName("username").sendKeys("Hello");

         driver.findElementByName("password").sendKeys("Hi");

         driver.findElementByName("submit").click();

         String b=driver.getTitle();

         System.out.println(driver.getTitle());


         if(a.equalsIgnoreCase(b)) {
        	 System.out.println("Title Match");
         }else {
        	 System.out.println("Title not matched");
         }

         driver.quit();

    }
}


>Index.html


<!DOCTYPE html>
<html>
<head>
<meta charset="ISO-8859-1">
<title>First page</title>
</head>
<body>
<form action="secondpage.html">
UserName:<input type="text" name="username">
Password:<input type="password" name="password">
<input type="submit" name="submit">
</form>
</body>
</html>


>Secondage.html


<!DOCTYPE html>
<html>
<head>
<meta charset="ISO-8859-1">
<title>First page</title>
</head>
<body>
</form>
</body>
</html>

>Practical No. 1

AIM :  EVALUATING TEST EXIT CRITERIA  AND REPORTING
PROBLEM STATEMENT :

1.	What are the various properties of test execution process to measure completeness of testing and reporting?
2.	What type of worksheet can be used to track the number of important properties of test execution?
3.	Write a test plan in IEEE 829 format.

SOLUTION :

Answer 1 :

To measure completeness of the testing with respect to exit criteria, and to generate information needed for reporting, we can measure properties of the test execution

process such as the following:
•Number of test conditions, cases, or test procedures planned, executed, passed, and failed
•Total defects, classified by severity, priority, status, or some other factor
•Change requests proposed, accepted, and tested
•Planned versus actual costs, schedule, effort
•Quality risks, both mitigated and residual
•Lost test time due to blocking events
•Confirmation and regression test results

Answer 2 :


>Practical No. 02

AIM :  STATIC AND DYNAMIC ANALYSIS

EQUIVALENCE PARTITIONING EXERCISE

A screen prototype for one screen of the HELLOCARMS system is shown in figure 4-7. This screen asks for three pieces of information :
•The product being applied for, which is one of the following :
– Home equity loan
– Home equity line of credit
– Reverse mortgage
•Whether someone has an existing Globo bank checking account, which is either Yes or No
•Whether someone has an existing Globo bank savings account, which is either Yes or No

If the user indicates an existing Globo bank account, then the user must enter the corresponding account number. This number is validated
against the bank’s central database upon entry. If the user indicates no such account, the user must leave the corresponding account number
field blank. If the fields are valid, including the account number fields, then the screen will be accepted. If one or more fields are invalid,
 an error message is displayed.


The exercise consists of two parts :

1.Show the equivalence partitions for each of the three pieces of information, indicating valid and invalid members.
2.Create test cases to cover these partitions, keeping in mind the rules about combinations of valid and invalid members.


EQUIVALENCE PARTITIONING EXERCISE DEBRIEF

First, let’s take a look at the equivalence partitions.  For the application-product field, the equivalence partitions are as follows :

For each of two existing-account entries, the situation is best modeled as a single input field, which consists of two subfields.  The first
 subfield is the Yes/ No field. This subfield determines the rule for checking the second subfield, which is the account number.  If the first
subfield is Yes, the second subfield must be a valid account number.  If the first subfield is No, the second subfield must be blank.  So, the
 existing checking account information partitions are as follows and, the existing savings account information partitions are as follows:

Now, let’s create tests from these equivalence partitions. As we do so, we’re going to capture traceability information from the test case number
 back to the partitions. Once we have a trace from each partition to a test case, we’re done— provided that we’re careful to follow the rules
about combining valid and invalid partitions!


BOUNDARY VALUE ANALYSIS :

A black-box test design technique in which test cases are designed based on boundary values.


The above screen asks for two pieces of information:
–Loan amount
–Property value

For both fields, the system allows entry of whole dollar amounts only (no cents), and it rounds to the nearest $100. Assume the following rules apply to loans :
–The minimum loan amount is $5,000.
–The maximum loan amount is $1,000,000.
–The minimum property value is $25,000.
–The maximum property value is $5,000,000.

If the fields are valid, then the screen will be accepted. If one or both fields are invalid, an error message is displayed. The exercise consists of two parts :

1.Show the equivalence partitions and boundary values for each of the two fields, indicating valid and invalid members and the boundaries for those partitions.
2.Create test cases to cover these partitions and boundary values, keeping in mind the rules about combinations of valid and invalid members.


BOUNDARY VALUE EXERCISE DEBRIEF

First, let’s take a look at the equivalence partitions and boundary values, which are shown in figure 4-15.


So, for the loan amount we can show the boundary values and equivalence partitions as shown in 4-8.


Make sure you understand why these values are boundaries based on round-off rules given in the requirements. For the transfer decision, we
can show the equivalence partitions for the loan amount as shown in table 4-10.


Now, let’s create tests from these equivalence partitions and boundary values. We’ll capture traceability information from the test case
 number back to the partitions or boundary values, and as before, once we have a trace from each partition to a test case, we’re done—as
long as we didn’t combine invalid values !


DECISION TABLE :

A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.


DECISION TABLE TESTING :

A black-box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) has shown in a decision table.
During development, the HELLOCARMS project team added a feature to HELLOCARMS.
This feature allows the system to sell a life insurance policy to cover the amount of a home equity loan so that, should the borrower die,
 the policy will pay off the loan.  The premium is calculated annually, at the beginning of each annual policy period and based on the loan
 balance at that time.  The base annual premium will be $1 for $10,000 in loan balance. The insurance policy is not available for lines of credit
or for reverse mortgages.  The system will increase the base premium by a certain percentage based on some basic physical and health questions
that the Telephone Banker will ask during the interview.

A Yes answer to any of the following questions will trigger a 50%  increase to the base premium :
1.Have you smoked cigarettes in the past 12 months?
2.Have you ever been diagnosed with cancer, diabetes, high cholesterol, high blood pressure, a heart disorder, or stroke?
3.Within the last 5 years, have you been hospitalized for more than 72 hours except for childbirth or broken bones?
4.Within the last 5 years, have you been completely disabled from work for a week or longer due to a single illness or injury?

The Telephone Banker will also ask about age, weight, and height.  The weight and height are combined to calculate the body mass index (BMI).
 Based on that information, the Telephone Banker will apply the rules in table 4-18 to decide whether to increase the rate or even decline to
issue the policy based on possible weight-related illnesses in the person’s future.


The increases are cumulative. For example, if the person has normal weight, smokes cigarettes, and has high blood pressure, the annual rate is
increased from $1 per $10,000 to $2.255 per $10,000. If the person is a 45-year-old male diabetic with a body mass index of 39, the annual rate
is increased from $1 per $10,000 to $2.6256 per $10,000.

The exercise consists of three steps :
1.Create a decision table that shows the effect of the four health questions and the body mass index.
2.Show the boundary values for body mass index and age.
3.Create test cases to cover the decision table and the boundary values, keeping in mind the rules about testing nonexclusive rules.


DECISION TABLE EXERCISE DEBRIEF

First, we created the decision table from the four health questions and the BMI/ age table. The answer is shown in table 4-19. Note that the increases
are shown in percentages.


It’s important to notice that rules 1 through 4 are nonexclusive, though rules 5 through 12 are exclusive. In addition, there is an implicit
 rule that the age must be greater than 17 or the applicant will be denied not only insurance but the loan itself. We could have put that here
in the decision table, but our focus is primarily on testing business functionality, not input validation. We’ll cover those tests with boundary values.
Now, let’s look at the boundary values for body mass index and age, shown in figure 4-18.


For the BMI, we can show the boundary values and equivalence partitions as shown in table 4-20.


For the age, we can show the boundary values and equivalence partitions as shown in table 4-21.


Finally, table 4-22 shows the test cases. They are much like the decision table, but note that we have shown the rate (in dollars per
$10,000 of loan balance) rather than the percentage increase.


Notice our approach to testing the nonexclusive rules.  First, we tested every rule, exclusive and nonexclusive, in isolation. Then, we tested
the remaining untested boundary values.  Next, we tested combinations of only one nonexclusive rule with one exclusive rule, making sure each
nonexclusive rule had been tested once in combination (but not all the exclusive rules were tested in combination).

Finally, we tested a combination of all four nonexclusive rules with one exclusive rule.  We did not use combinations with the “decline”
rules since presumably there’s no way to check if the increase was correctly calculated.  For the decision table and the boundary values, we’ve
captured test coverage in the following tables to make sure we missed nothing.

Table 4-23, table 4-24, and table 4-25 show decision table coverage using three coverage metrics.


STATE TESTING EXERCISE

This exercise consists of three parts:
1.	Using the following semiformal use case, translate it into a state transition diagram, shown from the point of view of the Telephone Banker.
2.	Generate test cases to cover the states and transitions (0-switch).
3.	Generate a switch table to the 1-switch level.


STATE TESTING EXERCISE DEBRIEF

1. Create state transition diagram.
Figure 4-27 shows the state transition diagram we generated based on the preceding semiformal use case.


2. Generate test cases to cover the states and transitions (0-switch).
Let’s adopt a rule that says that any test must start in the initial waiting state and may only end in the waiting state or the shift over state. To achieve
state and transition coverage, the following tests will suffice :

1.(waiting, phone call, loan screens, exceed[value], escalate, approved, resume, system loan offer, offer screen, offer insurance, insurance screens,
cust ins accept, add to package, cust loan accept, send to LoDoPS, waiting)
2.(waiting, phone call, loan screens, exceed[loan], escalate, approved, resume, system loan offer, offer screen, offer insurance, insurance screens,
cust ins reject, archive, cust loan accept, send to LoDoPS, waiting)
3.(waiting, phone call, loan screens, system loan offer, offer screen, offer insurance, insurance screens, system ins reject, archive,
cust loan reject, archive, waiting)
4.(waiting, phone call, loan screens, exceed[loan], escalate, system loan decline, archive, waiting)
5.(waiting, phone call, loan screens, system loan decline, archive, waiting)
6.(waiting, phone call, loan screens, cust cancel, archive, waiting)
7.(waiting, phone call, loan screens, exceed[loan], escalate, cust cancel, archive, waiting)
8.(waiting, phone call, loan screens, system loan offer, offer screen, cust cancel, archive, waiting)
9.(waiting, phone call, loan screens, system loan offer, offer screen, offer insurance, insurance screens, cust cancel, archive, waiting)
10.(waiting, end of shift, log out, shift over)

Notice that we didn’t do an explicit boundary value or equivalence partitioning testing of, say, the loan amount or the property value, though we certainly could have.

Also, note that this is an example of when our rule of thumb for number of needed test cases did not work. This usually happens because there are multiple paths

between two non-final states (in this case between offering and gathering insurance info) that must be tested with separate test cases.

3. Generate a switch table to the 1-switch.
First, redraw the state transition diagram of figure 4-27 to make it easier to work with. It should look like figure 4-28.


From the diagram, we can generate the 1-switch table shown in table 4-27.  Notice that we have used patterns in the diagram to generate the table.
For example, the maximum number of outbound transitions for any state in the diagram is four, so we use four columns on both the 0-switch and 1-switch columns.
 We started with six 1-switch rows per 0-switch row because there are six states, though we were able to delete most of those rows as we went along.
This leads to a sparse table, but who cares as long as it makes generating this beast easier.


>Practical No. 03

AIM :  RATE QUALITY ATTRIBUTES FOR DOMAIN AND TECHNICAL TESTING

Technical test analysts, according to the ISTQB Advanced syllabus, should be able to identify opportunities to use test techniques that are appropriate for testing:
–Accuracy
–Suitability
–Interoperability
–Usability
–Security

USABILITY TEST EXERCISE

Review the HELLOCARMS system requirements document, specifically the usability section. Analyze the risks and create an informal test design for usability
 testing. The following section contains our solution. Of course, your solution may differ based on your experience with usability testing

USABILITY TEST EXERCISE DEBRIEF

There are several interesting requirements for HELLOCARMS under usability.  We selected 030-020-020 under the learn ability attribute and 030-010- 020
under understandability.  Non-functional testing often forces us to be more creative in coming up with test designs than functional testing. It is not
 always simply coming up with input data, expected output data and behaviors, etc. In line with recommendations from ISO 9126, much of our non-functional
testing will be static testing or trying to measure metrics after a project has occurred.

STARTING WITH 030-020-020 :

HELLOCARMS will include a self-contained training wizard for all users. This wizard will lead a new user through all of the screens using canned data.
 The training will be sufficient that an average user will become proficient in the use of HELLOCARMS within 8 hours of training.

Testing for this requirement would be straightforward static testing at first. It would consist of working through the wizard, one screen at a time, and
comparing the information presented the users to the requirements and designs actually used. We would check for completeness, correctness, and order of presentation.
Once the system was delivered into beta testing, we would send out questionnaires to Telephone Bankers and our partners asking for information on their
 first week of using the system. Specifically, we would target any errors, misunderstandings, or inefficiencies they run into, asking for feedback on
upgrades or changes they might like to see in the wizard.

Before each modification project for HELLOCARMS, we would scrutinize all reported defect records looking for evidence of mistakes made by ignorance of
 the system and make sure our documentation covers those areas correctly.

While going through the wizard, we would keep in mind the understandability requirement, 030-010-020 :

All screens, instructions, help, and error messages shall be understandable at an eighth grade level.
We would make sure that little or no difficult domain-specific jargon was thrown in to confuse a Telephone Banker or partner.

Looking at the understandability requirement, there are several different ways to try to determine the grade level required to understand a document.

One of the most common ways is the Flesch-Kincaid grade level readability formula (which just so happens to be built into MS Word). According to the
 Word help file, the formula is as follows :
FKRA = (0.39 x ASL) + (11.8 x ASW) - 15.59
In this formula, FKRA = Flesch-Kincaid reading age, ASL = Average sentence length, and ASW = average number of syllables per word.

MAINTAINABILITY AND PORTABILITY EXERCISE

Using the HELLOCARMS system requirements document, analyze the risks and create an informal test design for each of the following using one requirement for each:
•	Maintainability
•	Portability


MAINTAINABILITY AND PORTABILITY EXERCISE DEBRIEF

Maintainability is an interesting quality characteristic for testers to deal with. Most maintainability issues are not amenable to our normal concept of
a dynamic test, with input data, expected output data, etc. Certainly some maintainability testing is done that way, when dealing with patches, updates,
and so forth.

For this exercise, we are going to select requirement 050-010-010 : Standards and guidelines will be developed and used for all code and other generated
 materials used in this project to enhance maintainability.

Our first effort, therefore, done as early as possible, would be to review the programming standards and guidelines with the rest of the test team and
the development group. Assuming, of course, that we have standards and guidelines. If there were none defined, we would try to get a cross-functional
team busy defining them.

The majority of our effort would be during static testing. Starting (specifically for this requirement) at the low-level design phase, we would want to
attend reviews, walk-throughs, and inspections. We would use available checklists, including Marick’s, Laszlo’s24 and our own internal checklists based
on defects found previously.

Throughout each review, we would be asking the same questions: Are we actually adhering to the standards and guidelines we have? Are we building a system
that we will be able to troubleshoot when failures occur? Are we building a system with low coupling and high cohesion? Is it modular? How much effort will
 it take to test?

Since these standards and guidelines are not optional, we would work with the developers to make sure they understood them, and then we would start
 processing exceptions to them through the defect tracking database as we would any other issues.

Beyond the standards and guidelines, there would still be some dynamic testing of changes made to the system, specifically for regression after patches and other
 modifications. We would want to mine the defect tracking database and the support database to try to learn where regression bugs have occurred. New testing
 would be predicated on those findings, especially if we found hot spots where failures occurred with regularity.

Many of our metrics would have to come from analyzing other metrics. How hard was it to figure out what was wrong (analyzability)? When changes are needed,
how much effort and time does it take to make them (changeability)? How many regression bugs are found (in test and in the field) after changes are made
 (stability)? And, how much effort has it taken for testers to be able to test the system (testability)?

Portability testing consists of adaptability, installability, coexistence, and replaceability subattributes. Because HELLOCARMS is surfaced on browsers,
 we find the compelling attribute to be adaptability. Therefore, we have selected requirement 060-010-030 for discussion.


>Practical No. 04
AIM :  PERFORM REVIEW

Types of Reviews :

1.At the lowest level of formality (and, usually, defect removal effectiveness), we find the informal review. This can be as simple as two people, the author
 and a colleague, discussing a design document over the phone.
2.Technical reviews are more formalized, but still not highly formal.
3.Walk-throughs are reviews where the author is the moderator and the item under review itself is the agenda. That is, the author leads the review, and
in the review, the reviewers go section by section through the item under review.
4.Inspections are the most formalized reviews. The roles are well defined. Managers may not attend. The author may be neither moderator nor secretary.
A reader is typically involved.

What are Informal Reviews?

Informal reviews are applied many times during the early stages of the life cycle of the document. A two person team can conduct an informal review. In later
 stages these reviews often involve more people and a meeting. The goal is to keep the author and to improve the quality of the document. The most important
thing to keep in mind about the informal reviews is that they are not documented.

What are formal Reviews?

Formal reviews follow a formal process. It is well structured and regulated. A formal review process consists of six main steps:
1. Planning
2. Kick-off
3. Preparation
4. Review meeting
5. Rework
6. Follow-up

CODE REVIEW EXERCISE

In this exercise, you apply Marick’s and the Open Laszlo code review checklists to the following code shown following the instructions.
1.Prepare: Review the code, using Marick’s questions, Laszlo’s checklist, and any other C knowledge you have. Consider maintainability issues as you review the
 code. Document the issues you find.
2.Hold a review meeting: If you are using this book to support a class, work in a small group to perform a walk-through, creating a single list of problems.
3.Discuss: After the walk-through, discuss your findings with other groups and the instructor.

The solution to the first part is shown in the next section.

Here is the code that you are reviewing. This code performs a task by getting values from the user, performing a calculation, and then printing out the result.
On subsequent pages, we will present a debrief for this exercise.


1. getInputs(float *, float *, float *);
2. floatdoCalcs(float, float, float);
3. ShowIt(float);
4. main(){
5. float base, *power;
6. floatScaler;
7. getInputs(&base, power, &Scaler);
8. ShowIt(doCalculations(base, *power));
9. }
10. voidgetInputs(float *base, float power, float *S){
11. float base, power;
12. float i;
13. printf("\nInput the radix for calculation => ");
14. scanf("%f", *base);
15. printf("\nInput power => ");
16. scanf("%f", *power);
17. printf ("/nScale value => ")
18. scanf("i", i);
19. *Base = &base;
20. *P = &power; }
21. floatdoCalcs(float base, float power, float Scale){
22. float total;
23. if (Scale != 1) total == pow(base, power) * Scale;
24. else total == pow(base, power);
25. return;}
26. voidShowIt(float Val){
27. printf("The scaled power value is %f W.\n", Val);
28. }

CODE REVIEW EXERCISE DEBRIEF

This code is representative of code that Jamie frequently worked with when he was doing maintenance programming. Rex will let Jamie describe his findings here.

Let’s start with some general maintainability issues with this code :
1.No comments
2.No function headers. I have a standard that says that every callable function gets a formal header, explaining what it does, the arguments it takes,
  there turn value, and what the value means. I also include change flags and dates, with explanation for each change.
3.No reasonable naming conventions are followed. I would prefer Hungarian notation so we can discern the data type automatically.
4.No particular spacing standards used, so code is not as readable as it might be.

Based on Marick’s checklist and a general knowledge of C programming weaknesses and features, here are some specific issues with this code :

■ Line 0: Not shown: We need the includes for the library functions we are calling. We would need stdio.h (for printf() and scanf()) and math.h (forpow()).
 These problems would actually prevent the program from compiling, which should be a requirement before having a code review.
■ Line 1: Every function should have a return value, in this case void.
■ Line 2: No issues.
■ Line 3: Once again, the function should have a return value.
■ Line 4. This might work in some compilers, but the main should return avalue (int), and if it takes no explicit arguments, it should have void. This isa violation
 of Marick’s miscellaneous question, Does the program have a specific exit value?
■ Line 5: The variable power is defined as a pointer to float, but no storage is allocated for it. Near as I can tell, there is no reason to declare it as a pointer,
 and it should simply be a local float declared. Note that these variables are passed in to a function call before being initialized. This could be seen as a
 violation of Marick’s declaration question, Are all variables always initialized? Since no data has been allocated, this is a violation of Marick’s allocation
question, Is too little (or too much) data being allocated? And, just to make it interesting, assuming that the code was run this way, it would-be possible to
try to dereference the pointer *power, which breaks Marick’s pointer question, Can a pointer ever be dereferences when NULL?
■ Line 6: Variable is passed in to a function call before being initialized. This is a violation of Marick’s declaration question, Are all variables always
initialized?
■ Line 7: The function call arguments are technically correct since the variable power was defined as a pointer. However, the way it is written,
it will blow up since there is no storage allocated. This is a violation of Marick’s allocation question, Is too little (or too much) data being allocated?
Since I would change power to a float in line 5, this argument would have to be passed in as &power just like the other arguments.
■ Line 8: Same issue with power; it should be passed by value as just power.

Also, the function doCalculations() does not exist. It should be doCalcs().
And, if they are meant to be the same function, the argument count is incorrect.
■ Line 9: No issue.
■ Line 10: S is not a good name for a variable.
■ Line 11: The local variables have exactly the same name as the formal parameters passed in. I would like to think that this naming would prevent
 the module from compiling; I fear it won’t. It certainly will be confusing. If we must name the local variables the same as the parameters
(considering the way they are used, it makes a little sense), then we should change the capitalization to make them explicitly different. I would
capitalize the local variables Base and Power.
■ Line 12: While this is legal, it is a bad naming technique. The variable i, when used, almost always stands for an integer; here it is a float.
 At the very least it is confusing. This should likely match the others and be renamed Scaler.
■ Line 13: No issue although the prompt message is weak.

■ Line 14: No issue.
■ Line 15: No issue.
■ Line 16: No issue.
■ Line 17: The line feed is backwards: should be \n and not /n.
■ Line 18: We should be loading the value of S with this scanf() function.
There is no need for the local variable i.
■ Line 19: Let me say that I hate pointer notation with a passion. Here, we are assigning a pointer to the value pointed to by *Base. What we really want
to do is assign the actual value; the statement should read *base = Base (assuming we made the change in Line 11 to its name).
■ Line 20: Same as Line 19, and I still really hate pointer notation. Also, we are not returning any value to the third argument of the getInputs()
function. There should be a statement that goes *Scaler = scaler (assuming we change the name of the variable as suggested in line 12). *P is never declared;
 it is also a really poor name for a variable. Finally, the closing curly brace should not be on this line but moved down to the following line.
 That is the same indentation convention that we use for the other curly braces.
■ Line 21: No issue.
■ Line 22: No issue.
■ Line 23: We are doing an explicit equivalence check on a float [if (Scale != 1)].
This is a violation of Marick’s computation question, Are exact equality tests used on floating point numbers? On some architectures,
I would worry about whether the float representation of 1 is actually going to be equal to one. The problem is that I really don’t know what
 this scalar is supposed to do. It looks like, the way the code is written, Scale is only there to save a multiplication if it is equal to one.
 I would want to know if the user can scale at 5.3 (or any other real number) or if they could use only integers. If they could input only integers,
I would change the data type to in everywhere it is used. If there is a valid reason to input a real number (i.e., one with a decimal), then I would
lose the if statement and simply do the multiplication each time. Comments would help me understand the logic being used. The wrong operator has been used;
it should be an assignment statement (=) rather than a Boolean compare (==).
■ Line 24: Incorrect operator; need a single equal sign.

■ Line 25: The calculation is being lost because we are returning nothing. It should return the local variable value, total.
■ Line 26: No issue.
■ Line 27: No issue.


>Practical No.  05

AIM :  INCIDENT MANAGEMENT

Defect (or bug or fault or problem): A flaw in a component or system that can cause the component or system to fail to perform its required function,
e.g., an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

Incident (or deviation): Any event occurring that requires investigation.

INCIDENT MANAGEMENT EXERCISE

Assume that a select group of Telephone Bankers will participate in HELLOCARMS testing as a beta test. The bankers will enter live applications from customers,
 but they will also capture the information and enter it into the current system afterward to ensure that no HELLOCARMS defects affect the customers. The bankers are

not trained testers and are unwilling to spend time to learn testing fundamentals. So, to avoid having the bankers enter poorly written incident reports and introduce

noise into the incident report metrics, management has decided that, when a banker finds a problem, he or she will send an e-mail to a test analyst to enter the

report.

You receive the following e-mail from a banker describing a problem :

I was entering a home equity loan application for a customer with good credit. She owns a high-value house, though the loan amount is not very large.
At the proper screen, HELLOCARMS popped up the “escalate to Senior Telephone Banker” message. However, I clicked continue and it allowed me to proceed,
 even though no Senior Telephone Bank Authorization Code had been entered.
From that point forward in this customer’s application, everything behaved normally.
I had another customer with a similar application—high-value house, medium-sized loan amount—call in later that day. Again, it would let me
 proceed without entering the authorization code.

The exercise consists of two parts :

1.What IEEE 1044 recognition and recognition impact classification fields and data are available from this e-mail?
2.What steps would you take to clarify this report?
3.Incident Management Exercise Debrief
4.Rex did the solution to this exercise, so he’ll describe it here.
5.First, I evaluated each of the pertinent recognition and recognition impact classifications and data fields to see if this
e-mail or other information I assume I have is presented. My analysis is shown in table 7-2.

Next, I have annotated the report with some steps I’d take to clarify it before putting it into the system. The original information
 is shown in italic, while my text is shown in regular font.  I was entering a home equity loan application for a customer with good credit.
  I would want to find out her exact data, including income, debts, assets, credit score, etc.


She owns a high-value house, though the loan amount is not very large.  I would want to find out the exact value of the house and the loan amount.
  I would test various combinations of values and loan amounts to see if I could find a pattern.  At the proper screen, HELLOCARMS popped up the
“escalate to Senior Telephone Banker” message. However, I clicked continue and it allowed me to proceed, even though no Senior Telephone Bank
 Authorization Code had been entered.  I would want to find out if the banker entered anything at all into that field.  I would test leaving it empty,
 input blanks, input valid characters that were not valid authorization codes, and conduct some other checks to see whether it is ignoring the field completely.
 From that point forward in this customer’s application, everything behaved normally.  I would test to see whether such applications are transferred to
LoDoPS or are silently discarded. If they are transferred to LoDoPS, does LoDoPS proceed or does it catch the fact that this step was missed?
 I had another customer with a similar application—high-value house, medium sized  loan amount—call in later that day. Again, it would let me proceed
without entering the authorization code.  Here also I would want to find out the exact details on this applicant, the property value, and the loan amount.

>Practical No. 06

AIM :  PATH TESTING AND EQUIVALENCE PARTITIONING

PATH TESTING

We have looked at many different control-flow coverage schemes. But there are other ways to design test cases
 using the structure as a test basis. In this section, we will look at path testing.

Remember that we have covered three main different ways of approaching test design so far :

1.Statement testing, where the statements themselves drove the coverage.
2.Decision testing, where the branches drove the coverage.
3.Condition, decision/condition, modified condition/decision coverage, and multiple condition coverage,
all of which looked at sub-expressions and atomic conditions of a particular decision

CYCLOMATIC COMPLEXITY EXERCISE

The following C code function loads an array with random values.
1. int main (int MaxCols, int Iterations, int MaxCount)
2. {
3. int count = 0, totals[MaxCols], val = 0;
4.
5. memset (totals, 0, MaxCols * sizeof(int));
6.
7. count = 0;
8. if (MaxCount > Iterations)
9. {
10. while (count < Iterations)
11. {
12. val = abs(rand()) % MaxCols;
13. totals[val] += 1;
14. if (totals[val] > MaxCount)
15. {
16. totals[val] = MaxCount;
17. }
18. count++;
19. }
20. }
21. return (0);
22. }


1.Create a directed control-flow graph for this code.
2.Using any of the methods given in the preceding section, calculate the cyclomatic complexity.
3.List the basis tests that could be run.


CYCLOMATIC COMPLEXITY EXERCISE DEBRIEF

The directed control-flow graph should look like figure 4-45. Note that the edges D1 and D2 are labeled;
D1 is where the if conditional in line 14 evaluates to TRUE, D2 is where it evaluates to FALSE.  We could use
 three different ways to calculate the cyclomatic complexity of the code as shown in the box on the right in figure.


First, we could calculate the number of test cases by the region methods.


Remember, a region is an enclosed space. The first region can be seen on the left side of the image
. The curved line goes from B to E; it is enclosed by the nodes (and edges between them) B-C-E. The second region
 is the top edge that goes from C-D and is enclosed by line D1. The third is the region with the same top edge, C-D,
and is enclosed by D2.


Here is the formula:
C = # Regions + 1
C = 3 + 1
C = 4

The second way to calculate cyclomatic complexity uses McCabe’s cyclomatic complexity formula. Remember, we count up the edges
(lines between bubbles) and the nodes (the bubbles themselves) as follows:
C = E - N + 2
C = 7 - 5 + 2
C = 4

Finally, we could use our rule of thumb measure, which usually seems to work.  Count the number of places where decisions are made
 and add 1. So, in the code itself, we have line 8 (an if() statement), line 10 (a while() loop), and line 14 (an if() statement):
C = # decisions + 1
C = 3 + 1
C = 4

In each case, our basis path is equal to 4. That means our basis set of tests would also number 4. The following test cases would cover the basis paths:
1.ABE
2.ABCE
3.ABCD(D1)CE
4.ABCD(D2)CE

EQUIVALENCE PARTITIONING

Problem Statement :
A screen prototype for one screen of the HELLOCARMS system is shown in the figure below.
This screen asks for three pieces of information :

a)The product being applied for, which is one of the following:
1.Home equity loan
2.Home equity line of credit
3.Reverse mortgage

b)Whether someone has an existing Globobank checking account, which is either Yes or No

c)Whether someone has an existing Globobank savings account, which is either Yes or No
•If the user indicates an existing Globobank account, then the user must enter the corresponding account number.
•This number is validated against the bank’s central database upon entry.
•If the user indicates no such account, the user must leave the corresponding account number field blank.
•If the fields are valid, including the account number fields, then the screen will be accepted. If one or more fields are invalid, an error message is displayed.
•Show the equivalence partitions for each of the three pieces of information, indicating valid and invalid members.
•Create test cases to cover these partitions, keeping in mind the rules about Combinations of valid and invalid members.


THEORY :

The first of the dynamic testing techniques are the specification-based testing techniques. These are also known as 'black-box' or input/output-driven testing

techniques because they view the software as a black-box with inputs and outputs, but they have no knowledge of how the system or component is structured inside the

box. In essence, the tester is concentrating on what the software does, not how it does it.

Functional testing is concerned with what the system does, its features or functions. Non-functional testing is concerned with examining how well the system does

something, rather than what it does. Non-functional aspects (also known as quality characteristics or quality attributes) include performance, usability, portability,

maintainability, etc.

Techniques to test these non-functional aspects are less procedural and less formalized than those of other categories as the actual tests are more dependent on the

type of system, what it does and the resources available for the tests.

The four specification-based techniques are:
•Equivalence partitioning
•Boundary Value Analysis
•Decision Tables
•State Transition Testing


Equivalence partitioning (EP) is a good all-round specification-based black-box technique. It can be applied at any level of testing and is often a good technique to

use first. It is a common sense approach to testing, so much so that most testers practise it informally even though they may not realize it.
The idea behind the technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should

handle them equivalently), hence 'equivalence partitioning'. Equivalence partitions are also known as equivalence classes - the two terms mean exactly the same thing.

The equivalence-partitioning technique then requires that we need test only one condition from each partition. This is because we are assuming that all the conditions

in one partition will be treated in the same way by the software. If one condition in a partition works, we assume all of the conditions in that partition will work,

and so there is little point in testing any of these others.

Conversely, if one of the conditions in a partition does not work, then we assume that none of the conditions in that partition will work so again there is little

point in testing any more in that partition. Of course these are simplifying assumptions that may not always be right but if we write them down, at least it gives

other people the chance to challenge the assumptions we have made and hopefully help to identify better partitions.

SOLUTION :

For the application-product field, the equivalence partitions are as follows:

#Partitions
1.Home equity loan
2.Home equity line of credit
3.Reverse Mortgage

The existing checking account information partitions are as follows:

#Partitions
1.Yes-Valid
2.Yes-Invalid
3.No-Blank
4.No-Nonblank

The existing savings account information partitions are as follows:

#Partitions
1.Yes-Valid
2.Yes-Invalid
3.No-Blank
4.No-Nonblank


Test Cases:

Inputs	                                1	2	3	4	5	6	7
Product	                               HEL	LOC	RM	HEL	LOC	RM	HEL
Existing Checking?	               YES	NO	NO	YES	NO	NO	NO
Checking Account	               Valid	Blank	Blank	Invalid	Nonblank	Blank	Blank
Existing Savings	                No	Yes	No	No	No	Yes	No
Accept?	                                Yes	Yes	Yes	No	No	No	No
Error?	                                No	No	No	Yes	Yes	Yes	Yes

Product field partitions along with test cases

#Partition	            Test Case
1.Home equity loan	        1
2.Home equity line of credit	2
3.Reverse Mortgage	        3

Existing Checking account partitions along with test cases

#Partition	Test Case
1.Yes-Valid	1
2.Yes-Invalid	4
3.No-Blank	3
4.No-Nonblank	6

Existing savings account partitions along with test

#Partition	Test Case
1.Yes-Valid	2
2.Yes-Invalid	6
3.No-Blank	1
4.No-Nonblank	7


>Practical No. 07

AIM :  PERFORMANCE TESTING

PERFORMANCE TESTING EXERCISE

Given the efficiency requirements in the HELLOCARM system requirements document, determine the actual points of measurement and a brief description of how you will

measure the following:
1. 040-010-050
2. 040-010-060
3. 040-020-010
The results will be discussed in the next section.

PERFORMANCE TESTING EXERCISE DEBRIEF

040-010-050 :

Credit-worthiness of a customer shall be determined within 10 seconds of request. 98% or higher of all Credit Bureau Mainframe requests shall be completed within 2.5

seconds of the request arriving at the Credit Bureau.

In this case, we are testing time behavior. Note that this requirement is badly formed in that there are two completely different requirements in one. That being said,

we should be able to use the same test to measure both.

The first, 2.5 seconds to complete the Credit Bureau request :

Ideally, this measurement would be taken right at the Credit Bureau Mainframe, but that is probably not possible given the location of it. Instead, we would have to

instrument the Scoring Mainframe and measure the timing of a transaction request to the Credit Bureau Mainframe against the return of that same transaction.

That would not be exact because it does not include transport time, but since we are talking about a rather large time (2.5 seconds), it would likely be close enough.

The second, 10 seconds for the determination from the Telephone Banker side:  This measurement could be taken from the client side.

Start the timer at the point the Telephone Banker presses the Enter button and stop it at the point the screen informs the banker that it has completed. Note that in

this case, we would infer that the client workstation must be part of the loop, but since it is single threaded (i.e., only doing this one task), we would expect

actual client time to be negligible. So, our actual measurement could conceivably be taken from the time the virtual user (VU) sends the transaction to the time we get

a return on the wire. That would allow the performance tool to measure the time.

Clearly, this test would need to be run with different levels of load to make sure there is no degradation at rated load; 2,000 applications per hour in an early

release (040-010-110) and later at 4,000 applications per hour (040-010- 120).


In addition, it would need to be run a fairly long time to get an acceptable data universe to calculate the percentage of transactions that met the requirements.

040-010-060 :

Archiving the application and all associated information shall not impact the Telephone Banker's workstation for more than .01 seconds. Again, we are measuring time

behavior.

Because the physical archiving of the record is only a part of this test, this measurement would be made by an automation tool running concurrently with the

performance tool. Our assumption is that the way the requirement is worded; we want the Telephone Banker ready to take another call within the specified time period.

That means the workstation must reset its windows, clear the data, etc. while the archiving is occurring.

We would have a variety of scenarios that run from cancellation by the customer to declined applications to accepted. We would include all three types ofloans, both

high and low value. These would be run at random by the automation tool while the performance tool loaded down the server with a variety of loans.

The start of the time measurement will depend on the interface of HELLOCARMS.  After a job has completed, the system might be designed to reset itselfor the user might

be required to signal readiness to start a new job. If the systemresets itself, we would start an electronic timer at the first sign of that occurring and stop it when

the system gives an indication that it is ready. If the user must initiate the reset by hand, that will be the trigger to start the timer.

040-020-010 :

Load Database Server to no more than 20% CPU and 25% resource utilization average rate with peak utilization never more than 80% when handling 4,000 applications per

hour.  This requirement is poorly formed. During review, we would hope that we would be able to get clarification on exactly what resources are being discussed when

specifying percentages. For the purpose of this exercise, we are going to make the following assumptions:
■25% resource utilization will be limited to testing for memory and disk usage.
■ Peak utilization applies to CPU alone.

This test will be looking at resource utilization, so we would monitor a large number of metrics directly on the server side for all servers :

■Processor utilization on all servers supplying the horsepower
■ Available memory
■ Available disk space
■ Memory pages per second
■ Processor queue length
■ Context switches per second
■ Queue length and time of physical disk accesses


■ Network packets received errors
■ Network packets outbound errors

The test would be run for an indeterminate time, ramping up slowly and then running at the rated rate (4,000 applications per hour) with occasional forays just above

the required rate.

After the performance test runs, we would graph out the metrics that had been captured from the Database Server. Had the server CPU reached 80% at any time, we would

have to consider the test failed. Averaging out the entire time the test had been running, we would look for memory, disk, and CPU usage on the Database Server to make

sure they averaged less than the rated value.

Note that this test points out a shortcoming of performance testing. In production, the Database Server could easily be servicing other processes beyond HELLOCARMS.

These additional duties could easily cause the resources to have higher utilization than allowed under these requirements.

In performance testing, it is always difficult making sure we are comparing apples to apples and oranges to oranges. We fear that without more information, we might

just be measuring an entire fruit salad in this test.


>Practical No. 8

AIM :  TEST AUTOMATION USING SELENIUM IDE

Problem Statement :
Automate web test using Selenium IDE and Firebug.

Theory :

Selenium is a free (open source) automated testing suite for web applications across different browsers and platforms.
•Selenium is not just a single tool but a suite of software, each catering to different testing needs of an organization. It has four components.
•Selenium Integrated Development Environment (IDE)
•Selenium Remote Control (RC)
•WebDriver
•Selenium Grid


Selenium Integrated Development Environment (IDE) is the simplest framework in the Selenium suite and is the easiest one to learn. It is a Firefox plugin that you can

install as easily as you can with other plugins. However, because of its simplicity, Selenium IDE should only be used as a prototyping tool.

• If you want to create more advanced test cases, you will need to use either Selenium RC or WebDriver.