Part – A

Q1. Why does knowing how the Software works influence how and what you should test?
Ans. If we don’t know how your software works and if we test only with a black-box view of the
software, we won't know if our test cases adequately cover all the parts of the software or if some of the
cases are redundant or missing. 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. When
we come to know about how our software works and what kind of actions it takes to solve our problems
and produce desired results then we can develop test cases to check its capabilities to work under
different kinds of conditions.
In white box testing view ,when we run our software under dynamic conditions if we do not know how
one module works like how it calls other modules we cannot develop any test case to check whether it is
performing its function right or not ?

Q2. What is the biggest problem of White-Box Testing either Static or Dynamic?
Ans. In white box testing there are three big problems which leads to incomplete development of the
software. These three problems are:
1. Complexity: Being able to see every constituent part of an application means that a tester must have
detailed programmatic knowledge of the application in order to work with it properly. This high-degree
of complexity requires a much more highly skilled individual to develop test case.
2. Fragility. While introspection is supposed to overcome the issue of application changes breaking test
scripts the reality is that often the names of objects change during product development or new paths
through the application are added. The fact that white-box testing requires test scripts to be tightly tied
to the underlying code of an application means that changes to the code will often cause white-box test
scripts to break. This, then, introduces a high degree of script maintenance into the testing process.
3. Integration. For white-box testing to achieve the degree of introspection required it must be tightly
integrated with the application being tested. This creates a few problems. To be tightly integrated with
the code you must install the white-box tool on the system on which the application is running. This is
okay, but where one wishes to eliminate the possibility that the testing tool is what is causing either a
performance or operational problem, this becomes impossible to resolve. Another issue that arises is
that of platform support. Due to the highly integrated nature of white-box testing tools many do not
provide support for more than one platform, usually Windows®. Where companies have applications
that run on other platforms, they either need to use a different tool or resort to manual testing.
Q3. How could you guarantee that your Software would never have a Configuration Problem?
Ans. We cannot easily guarantee that our software would never have a configuration problem. But it is
possible when we 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.

One example for such type of software is embedded system software such as micro wave oven. In
which only the software is only work for that very hardware. In such kind of equipments we may say
that we have configured completely but not hundred percent.

Q4. Create the equivalence partitioning and write test cases to test the login screen containing username
and password?
Ans. The following test cases formed to test the login screen containing user name and password:
Test Case Number 01

Test Purpose: - For All the users logging form Login window. It consist Username and Password fields.

Test procedure: - If User enters valid username with alphanumeric, password

Expected Result: - Login window access

Actual Result: - same as Expected result

Pass/Fail Criteria: - Test pass

Remarks: - No

Test Case number 02:

If user enter invalid username with symbols like *, &,. /? , valid password

Expected Result: - Login window opened

Actual result: - Login does\'t access. It displays error message.

Pass/Fail Criteria: - Test case failed

Remarks: - There is error message displays. Like enter valid user name

Q5. Explain the key elements involved in formal reviews?

Ans. Formal review is the just reviewing the code by the members of only one team, the team which
created the software. It is the steps in which static white box testing is performed. There are four major
key element in the formal review. These are describes as follows:
1. Identify Problems: in formal review method first thing is to find the proble. We find out things
that are not correct as well as the things which are missing. The designer of the software is held
responsible for this kind of wrong or missing things problems but actually what is needed to be
done is that we should focus on redeveloping the software by correcting the design.

2. Follow Rules: In this the rules that are designed for the software development process are
followed. These are fixed set of rules that must be followed to meet for good development. These
types of rules are
How much time will be spent?
What can be commented on?

3. 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 full-fill them at the review. Most of the problems
found through the review process are found during preparation, not at the actual review.

4. Write a Report: A written report must be created that describes the results of the review in nut-
shell 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. Although, it is not a good idea to release a product with configuration bugs, But still products are
released with configuration bugs. The one reason of this is that we are not able to get all the
configuration bugs and we will never be able to fix all of bugs. As in all testing, the process is risk
based. Configuration testing is the process of checking the operation of the software we are testing with
all various types of hardware. Now it is important to note that the software testers are not able to test
software with different hardware configuration. Because there are so many technologies are there and
the technologies changes day by day. We and our 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.

Q7. In addition to age and popularity what other criteria might you use to equivalence Partition
Hardware for Configuration testing?

Ans. Age and popularity is the one criteria, that is used for equivalence partition. There are several
criteria such as region or country is a possibility in which 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. It is
some time also depends upon the type.

Q8. What are the different levels of Testing and the goals of different levels? For each level Which
Testing Approach is more suitable?

Ans. Testing is the investigation conducting to provide information about the quality of the product or
service under the test with respect to context in which it is intended to operate. To steaming the process
of testing different level of testing are produced. In these levels the software is tested in steps by steps,
in line with the planned build and release strategies. There levels are described as follows:

1. Unit Test: A unit is smallest testable piece of software that can be can be compiled, linked,
loaded. E.g. functions/procedures, classes, interfaces. This type of testing is normally done by
programmer. Test cases written after coding. In unit testing we verify the program specifications
to the internal logic of the program or module and validate the logic.
 Goal: These types of tests are usually written by developers as they work on code, to ensure that
the specific function is working as expected. One function might have multiple tests, to catch
corner cases or other branches in the code. Unit testing alone cannot verify the functionality of a
piece of software, but rather is used to assure that the building blocks the software uses work
independently of each other.

2. Integration testing: Integration testing is used to test for correct interaction between system units
and systems ‐built by merging existing libraries. In this modules are coded by different people.
And mainly tests the interfaces among units. Top down integration testing is both the detection as
well as the correction of programming/code generation problems.

Examples: Regression testing, integration testing, smoke testing,

Goal: Integration tests works to expose defects in the interfaces and interaction between
integrated components (modules). Progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the software
works as a system

3. System Test: System testing is used to test of overall interaction of components and find
disparities between implementation and specification. It Involve load, performance, reliability
and security testing System testing tests a completely integrated system to verify that it meets its
requirements.
Examples: System testing, Recovery testing, Security testing Load & Stress testing, performance
testing, Installation testing

Goal: Verifies proper execution of the entire application components including interfaces to
other applications. Both functional and structural types of tests are performed to verify that the
system is functionally and operationally sound.

4. Acceptance testing: the Acceptance testing is done to demonstrates the satisfaction of user. The
users are essential part of process so their statisfection must be required. This type of testing
generally merged with System Testing and it is cumulative done by test team and customer.
Example: -UAT ensures that the project satisfies the customer requirements, Alpha testing, Beta
testing, Long term testing, Compatibility testing
 Goal: - System integration testing verifies that a system is integrated to any external or third party
systems defined in the system requirements.

Q9. Relate verification and validation to the Quality control and Quality Assurance with an example?
Ans. Quality Assurance is process of enforcing quality control standards by applying the planned,
systematic quality activities and working to improve the processes that are used in producing the web
sites and its components, infrastructure and content. Quality assurance examines the processes of site
implementation from inputs to output.

Quality control involves the formal and systematic use of testing to measure the achievements of a
specified standards and recommendations; the measurement and enforcement of defined level of
standards.

Here's an example to drive home the point. Let's say a project manager asked the sponsor to approve the
Business Requirements Report. If you were the sponsor, how would you validate and verify that the
business requirements seemed complete and correct?
One solution would be for you to actually review the document and the business requirements. If you
did that, you would be performing a quality control activity, since your actions would be based on
validating the deliverable itself.
However, let's say the document was thirty pages long and that you (as the sponsor) did not have the
expertise, the time, or the inclination to do a specific content review. In that case, you wouldn't ask to
review the document itself. Instead, you would ask the project manager to describe the process used to
create the document. Let's say you received the following reply.
Project manager - "I gathered eight of your major users in a facilitated session. After the meeting, I
documented the requirements and asked the group for their feedback, modifications, etc. I then took
these updated requirements to representatives from the Legal, Finance, Manufacturing and Purchasing
groups and they added requirements that were needed to support company standards. We then had a
meeting with the four managers in your area that are most impacted by this system. These managers
added a few more requirements. I then asked your four managers to sign off on the requirements and
you can see their signatures on the last page."
If you were the sponsor, would you now feel comfortable to sign the requirements? If it were me, I
would feel pretty comfortable.
That's the difference. Validation process with Quality control activities are focused on the deliverable
itself and verification process with Quality assurance activities are focused on the process used to create
the deliverable. They are both powerful techniques and both must be performed to ensure that the
deliverables meet your customers quality requirements.
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 ?
5. Does the code follow the coding conventions of the organization

Ans.
1. Ans. Is the entire conditional path reachable?
Category: -Control Flow Errors
2. If the pointers are used, are they initialized properly?
Category: - Data Declaration Errors
3. Is there any part of code unreachable?
Category: - Reference Errors
4. Has the use of similar looking operators (e.g. &,&& or =,== in C)checked ?

Category: -Code inspection errors and statement errors with comparison errors.