CAP526 – Software Testing and Quality Assurence

Home Work – 2

DOA: 01-03-10 DOS: 10-03-10

Course Instructor: Lect. Garagi Sharma COURSE CODE:-

CAP-526

Roll No: RD3803A01 Section: D3803

DECLARATION:

I declare that this assignment is my individual work. I have not copied

from any other students’ work or from any other source, except where
due acknowledgement is made explicitly in the text, not has any part
being written for me by other person.

Ravinder kaur

Evaluator comments…………………………………………………………………………..

Marks obtained ………. out of …………….

 Part – A

Q1. Why does knowing how the Software works

influence how an what you should test?.

ANS:

If you test only with a black-box view of the software, you won't know if your test cases
adequately cover all the parts of the software or if some of the cases are redundant. An
experienced black-box tester can design a fairly efficient suite of tests for a program but he
can't know how good that suite is without some white-box knowledge. Some testing
techniques are:

1. black box
2. white box
3. gray box
4. comparison
5. compatibility
6. stress testing
7. load testing

Q2. What is the biggest problem of White-Box testing

either Static or Dynamic?

ANS: Biggest problem of white box testing:

purpose of white-box testing: that all independent paths within a module have been
exercised at least once. all logical decisions verified on their true and false values. All loops
executed at their boundaries and within their operational bounds internal data structures
validity. Logical error tends to creep into our work when we design and implement functions,
conditions or controls that are out of the program. The design errors due to difference
between logical flow of the program and the actual implementation. Typographical errors and
syntax checking. Not possible for testing each and every path of the loops in program. This
means exhaustive testing is impossible for large systems. This does not mean that WBT is not
effective. By selecting important logical paths and data structure for testing is practically
possible and effective.
Q3. How could you guarantee that your software would never have a
configuration problem?

Ans:
You'd need to ship the hardware and software together as one package, the software would
only work on that hardware, and the hardware would have to be completely sealed, not having
a single interface to the outside world. Testing is aimed at assessing the product performance
within broad range of hardware and peripheral configurations as well as under different
operating systems and software. It checks how an application works in different configuration
environments. A typical example is a printing application:

Q4. Create the equivalence partitioning and write test cases to test the login
screen containing username and password?

Ans:
Equivalence partitioning is a software testing technique that divides the input data of a
software unit into partition of data from which test cases can be derived. In principle, test
cases are designed to cover each partition at least once. This technique tries to define test case
that uncovers classes of errors, thereby reducing the total number of test cases that must be
developed.

Test cases:
1) Go to user id field and without entering data in that field press "enter" key.
Expected-it should prompt message “please enter 'user id' "

2) Go to login screen enter "user id” and without entering password try to click on "ok"
button.
Expected-it should prompt message "please enter 'password' "

3) Go to login screen enter "user id” and enter wrong password try to click on "ok"
button.
Expected-it should prompt message “please enter proper 'user id' and ‘password’ "

4) Go to login screen enter all required data and press "ok" button then software window
will open. In that window click on "back" button.
expected-it should go back to 'login' screen and that screen should not show "user id"
and "password"
5) Go to login screen enter "user id" and enter password as "god12" try to click on "ok"
button. expected-it should prompt message for wrong password.

6) Enter valid username with 10 characters and without enter password and click on ?
Error message: please enter password
 7) Enter password only with 6 characters and click on? Error message: please enter
username

8) Enter username with special characters and enter password with special characters and
click on?
please enter valid username and password without special characters

9) Enter username with 16 characters and enter password as 6 characters and click on ?
ok? Please
Enter below 15 characters for username

10) Enter username as 12 characters and enter password as 3 characters and click on?
Please enter min 5
Characters for password.

Q5. Explain the key elements involved in formal reviews?

Ans:
There are four essential elements to a formal review:

• Identify problems. The goal of the review is to find problems with the softwarenot
just items that are wrong, but missing items as well. All criticism should be directed at
the design or code, not the person who created it. Participants shouldn't take any
criticism personally. Leave your egos, emotions, and sensitive feelings at the door.
• Follow rules. A fixed set of rules should be followed. They may set the amount of
code to be reviewed (usually a couple hundred lines), how much time will be spent (a
couple hours), what can be commented on, and so on. This is important so that the
participants know what their roles are and what they should expect. It helps the review
run more smoothly.
• Prepare. Each participant is expected to prepare for and contribute to the review.
Depending on the type of review, participants may have different roles. They need to
know what their duties and responsibilities are and be ready to actively fulfill them at
the review. Most of the problems found through the review process are found during
preparation, not at the actual review.
• Write a report. The review group must produce a written report summarizing the
results of the review and make that report available to the rest of the product
development team. It's imperative that others are told the results of the meeting how
many problems were found, where they were found, and so on.
 Part – B
Q6. Is it acceptable to release a software product that has configuration
bugs?

Ans:
Probably you will never be able to fix all of them. As in all testing, the process is risk based.
You and your team will need to decide what you can fix and what you can't. Leaving in an
obscure bug that only appears with a rare piece of hardware is an easy decision. Others won't
be as easy.

Q: 7. In addition to age and popularity what other criteria might you use to
equivalence partition hardware for configuration testing?

Ans:

Region or country is a possibility as some hardware devices such as DVD players only work
with DVDs in their geographic region. Another might be consumer or business. Some
hardware is specific to one, but not the other. Think of others that might apply to your
software.

Cost or budget: as cost is directly relates to time for testing any software. Greater time for
testing the software greater will be its cost or budget. If software does not work on the current
hardware i.e., the software is failed to pass the configuration testing, the project manager must
find those types of hardware on that the software will work. To do this, he/she has to make
some alternatives on the basis of brand, cost, models, etc. And choose the best among them.

Q8. What are the different levels of testing and the goals of different levels?
For each level which testing approach is more suitable?

Ans:
different levels of testing are given below:

 Unit testing or buddy testing

 •team approach to coding and testing
 •one programmer codes the other tests and vice versa
  test cases ‐written by tester(beforecoding starts). Better than single
worker approach
 •objectivity
 •cross‐training
 •models program specification requirement

 Integration testing

 •test for correct interaction between system units

 •systems ‐built by merging existing libraries
 •modules coded by different people
 •mainly tests the interfaces among units
 •bottom up integration testing
 •use of drivers
 •top down integration testing that is use of stubs.

SYSTEM TESTING
 Test of overall interaction of components
 •find disparities between implementation and specification
 •usually where most resources go to
 •involves –load, performance, reliability and security testing

 acceptance testing

 •demonstrates satisfaction of user

 •users are essential part of process
 •usually merged with system testing
 •done by test team and customer
 •done in simulated environment/real environment.

 Regression testing

 •on going process throughout testing lifecycle

 •new bug‐fix breaks previously tested units?
 •perform regression test whenever program
 Smoke test
this is also called as sanity testing. This is mainly used to identify environmental
related problems and is performed mostly by test manager. For any application it is
always necessary to have the environment first checked for smooth running of the
application. So in this testing process the application is run in the environment
technically called as dry run and checked to find that the application could run without
any problem or a bend in between.
 Alpha testing
the above different testing process described takes place in different stages of
development as per the requirement and needs. But a final testing is always made after
a full finished product that is before it released to end users and this is called as alpha
testing. The alpha testing involves both the white box testing and black box testing
thus making alpha testing to be carried out in two phases.

Beta testing
this process of testing is carried out to have more validity of the software developed.
This takes place after the alpha testing. After the alpha phase also the generally the
release is not made fully to all end users. The product is released to a set of people and
feedback is got from them to ensure the validity of the product. So here normally the
testing is being done by group of end users and therefore this beta testing phase covers
black box testing or functionality testing only.

Q9. Relate verification and validation to the quality control and quality
assurance with an example?

ANS:
Verification and validation is the process of checking that a product, service, or system
meets specifications and that it fulfills its intended purpose In SQA, software process
specialists and auditors take a broader view on software and its development. They examine
and change the software engineering process itself to reduce the amount of faults that end up
in the delivered software: the so-called defect rate. Verification refers to the collection of
activities and procedures conducted during the planning andDevelopment, or after completion
of an inventory that can help to establish its reliability for theIntended applications of the
inventory.

Quality control (qc) is a system of routine technical activities to assess and maintain the
quality
Of the inventory as it is being compiled. It is performed by personnel compiling the
inventory. The
Qc system is designed to:
(i) provide routine and consistent checks to ensure data integrity, correctness, and
completeness;
(ii) Identify and address errors and omissions;
(iii) Document and archive inventory material and record all qc activities.

Relating quality assurance and quality control to verification and validation.

Quality assurance directly related to validation and quality control relates to verification...
Verification activities may be constituents of both QA and QC, depending on theMethods
used and the stage at which independent information is used. In practice inventory compilers
do not have unlimited resources. Quality control requirements improved Accuracy and
reduced uncertainty need to be balanced against requirements for timeliness and cost
effectiveness’ good practice system for QA/QC and verification seeks to achieve that balance,
and also to enable continuous Improvement of inventory estimates. Judgments to select the
respective parameters will need to be made on the
Following:
 resources allocated to QA/ QC for different categories and the compilation
process;
 time allocated to conduct the checks and reviews of emissions and removal
estimates;
 frequency of QA/QC checks and reviews on different parts of the inventory;
 the level of QA/QC appropriate for each category;
 availability and access to information on activity data, emission factors and
other estimation parameters,
 Including uncertainties and documentation;
 acquisition of additional data specifically required, e.g., alternative data sets
for comparisons and checks;
 procedures to ensure confidentiality of inventory and category information,
when required;
 requirements for documenting and archiving information;
 whether increased effort on QA/QC will result in improved estimates and
reduced uncertainties

Q10. In a code review check list there are some items as given below
.categories them.

1. Is the entire conditional path reachable?

2. If the pointers are used, are they initialized properly?
3. Is there any part of code unreachable?
4. Has the use of similar looking operators (e.g. &,&& or =,== in
c)checked ?
Does the code follow the coding conventions of the organization?

Ans:
1. Entire conditional path categorize in the control flow errors of code review checklist.

2. If pointers are used they are initialized they are coming under the category of data
declaration errors.

3. Is there any part of code unreachable comes under subroutines and error: do the unit of
each parameter matching with the corresponding arguments.

4. Logical operator comes under the category of comparison error . Because they have
different meaning in different situations. For example ‘=’ means assign the value. And
‘&&’ means combining two conditions.