2nd asmt

8/7/2019 2nd asmt

http://slidepdf.com/reader/full/2nd-asmt 1/19

CAP526 – Software Testing and Quality Assurance

HOME-WORK 2

SOFTWARE TESTING AND QUALITY ASSURANCE

SUBMITTED TO:

Mr Deepak Mehta

SUBMITTED BY:

VIKAS RANA

ROLL NO. 03

REG. NO. 7010070026

BCA (H) – MCA

8/7/2019 2nd asmt



Q1. Why does knowing how the Software worksinfluence how and what you should test?

Ans: It is easy to tell when software is ready to release butdifficult to implement. Those days have arrived, software isbecoming more pervasive all the time. Unfortunately,software isn't as reliable as it ought to be, and its inherentunreliability is passed on to every system it touches. Andwhile consumers would like software to be perfect beforethey ever encounter it, perfect software doesn't exist;however, deciding when it's "good enough" to release is nosimple task. Project managers frequently must make toughcalls when it comes to deciding when software is ready tomarket. There are deadlines that must be met and otherpressures to consider, and sometimes the actualfunctionality of the program suffers. Not to mention thehidden costs of rushing a product to market.

In a classical software project, it's easy to tell whensoftware is ready to be released. It has to fulfill the

requirements, it has to have passed testing, and it has tobe ready for the user. It has to have the appropriatedocumentation and/or user's manual and/or online help.But, is it Software Operating Usably and Properly (SOUP)?

With so much software being produced throughout theworld (made available across the Internet) some importantthings are being forgotten. When software is released, it's

supposed to be usable, it's supposed to show that thecompany or group of people who have developed thesoftware are professionals, and that they know what theyare doing. The difference between good SOUP and badSOUP is really up to the user, but there are many thingsthat the people developing the software need to addressbefore the software is released.

8/7/2019 2nd asmt



How little functionality is too little functionality? How muchusability is enough? These are questions that have to beaddressed, and within a customer driven project (one which

the customer is actively involved in, such as a proprietaryproject for a specific customer, or Open Source/FreeSoftware), these issues are taken care of on the fly – thecustomer is involved in all aspects of the development, andhave a steady rapport with the development team.

In other types of software projects – such as new types of applications (and even new operating systems), the target

is a moving one, and is difficult to assess. Typically, thepotential customers won't even know that they want theproduct, or how they would use it – and because of this,SOUP is that much more important to these projects.

Marketing an incomplete product with features that haven'tbeen tested yet increases expectations, and is goodbusiness in the classical sense. The risk, though, is that

expectations will not be met – and the users will see bugsin their SOUP.

Q2. What is the biggest problem of White-BoxTesting either Static or Dynamic?

Ans: White Box Testing (also known as Clear Box Testing,

Open Box Testing, Glass Box Testing, Transparent Box Testing or Structural Testing) is a software testing methodin which the internal structure/design/implementation of the item being tested is known to the tester. The testerchooses inputs to exercise paths through the code anddetermines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White

8/7/2019 2nd asmt



box testing is testing beyond the user interface and intothe nitty-gritty of a system.

White Box Testing method is named so because thesoftware program, in the eyes of the tester, is like awhite/transparent box; inside which one clearly sees.

Eg:- A tester, usually a developer as well, studies theimplementation code of a certain field on a webpage,determines all legal (valid and invalid) AND illegal inputsand verifies the outputs against the expected outcomes,

which is also determined by studying the implementationcode.

DISADVANTAGES OF WHITE BOX TESTING

• Since tests can be very complex, highly skilledresources are required, with thorough knowledge of programming and implementation.

• Test script maintenance can be a burden if the

implementation changes too frequently.• Since this method of testing it closely tied with the

application being testing, tools to cater to every kindof implementation/platform may not be readilyavailable.

Q3. How could you guarantee that your Softwarewould never have a Configuration Problem?ANS: As we know new technologies are emerging day byday and user requirements and expectations keep onchanging so it is not possible to fully guarantee that oursoftware can never have a configuration Problem.

For this we have to give guarantee to customers thatthis software is running in any type of environment . it can

8/7/2019 2nd asmt



support this type of hardware requirements , if thisrequirements is matched with the user hardware then wecan say that it does not generate kind of problem.

For example: by purchasing a video game , we can say thata video game is set of instruction that it is developed incode so it is a software . when we purchased it from themarket the in the back side of that cd there is page inwhich hardware requiremaents are mentioned this meansthat this video is run only in that kind of envoirnment ,

foreg. It can support window VISTA or higher version then itcan work in windows XP

Q4. Create the equivalence partitioning and writetest cases to test the login screen containingusername and password?

The following sections describe details of these steps.

Step 1: Identify variables for each use case step

You need to identify all input variables in all of the steps inthe given scenario. For example, if in some step the userenters a user ID and password, there are two variables.One variable is the user ID, and the second variable is thepassword. The variable can also be a selection that theuser can make (for instance, Save changes or Cancel).

Step 2 : Identify significantly different options for eachvariable

Options are "significantly different" if they may triggerdifferent system behavior. For example, if we select a userid, which is supposed to be from 6 to 10 characters long,the following entries are significantly different:

8/7/2019 2nd asmt



• Alex -- because it is too short, and we expect an errormessage to appear

• Alexandria -- because it is a valid user id• Alexandrena -- because it is too long, and we expect

the system to prevent us from entering a user id thatlong

However, "Alexandria" and "JohnGordon" are notsignificantly different, because they are both valid user idsthat should cause the system to react in the same way.

The following guidelines describe some specificcases.

An option can be considered significantly differentif:

1. It triggers different flow of the process (usually analternative flow)

Example

o Entering invalid password will trigger AlternativeFlow 2

2. It triggers different error message

Example

o If email is to long, the message is "Email shouldhave no more than 50 characters"

o If email does not contain @ sign, the message is:"Invalid email address"

PASSWORD

Example

Since password should have at least 6 characters weshould test:

o Password with 5 characterso Password with 6 characters

8/7/2019 2nd asmt



If we are testing numbers, we may consider the followingoptions:

• Regular number, reasonable from the applicationpoint of view

• Zero• Negative number• A number with two decimals• The biggest number that can be entered

(99999999999999 - as many nines as can fit)

How do you know what is the minimum and maximumallowed length of a field? This requirement can come fromdifferent sources. Sometimes it comes from the businessanalyst or a customer. For example, if we enter a Dun andBradstreet number that identifies a company, it shouldalways be a number containing 9 digits. It is a businessrequirement.

Quite often, however, it doesn't come from the customer orthe user. If you ask the customer how big the last namefield should be, they might say that they don't care and ask

you to make it whatever is reasonable. In this case it is adesign step rather than a requirement step to decide howlong the variable should be.

In another situation, it may be suggested by the dataanalyst or database designer-- for example, if all otherapplications in the corporation store last names in 30-character long fields, your application should probablycomply with this standard as well.

Regardless of the source of the requirement, it shouldalways be agreed upon and documented before we do thetest cases.

Step 3: Combine options to be tested into testcases

8/7/2019 2nd asmt



In the previous step you identified all the options. In thisstep, you need to combine them in the sequence of testcase steps.

Figure 10 graphically illustrates the options to be tested. Ineach column, there is an input variable to be tested, andeach row is one option: R is regular, E is empty, and thenone character, 50 characters, 51, and so forth. "L" meansvery large, and "I" means illegal.

To create the first test case, you can pick and connect anyoptions. When you create the second test case, pick one of the options that was not used in the first one. Continueadding test cases until all nodes of the graph (as shown inFigure 11) are covered. Usually you'll need from 4 to 6 testcases to cover all the options that should be tested.However, some specific situations may require more.

Allocation of test cases can also be represented inthe form of a test case allocation matrix, as shown inTable 4.

Stepnumbe

r

Variableor

selectionTC1 TC2 TC3 TC4

B1 Website ActualURL Actual URL Actual URL Actual URL

B2 Email RegularMinallowed (1char)

Maxallowed (50char)

Regular

B2 Password RegularMinallowed (6char)

Maxallowed (10char)

Min allowed(6 char)

Table 4 describes the graph from Figure 11 in the form of amatrix where every column contains a different test case.Each row corresponds to one variable entered by a user.

Step 4: Assign values to variables

8/7/2019 2nd asmt



Q5. Explain the key elements involved informal reviews?

Formal Reviews

A formal review is the process under which static white-boxtesting is performed. A formal review can range from a simplemeeting between two programmers to a detailed, rigorousinspection of the software's design or its code.

There are four essential elements to a formal review:

Identify Problems. The goal of the review is to findproblems with the softwarenot just items that are wrong,but missing items as well. All criticism should be directedat the design or code, not the person who created it.Participants shouldn't take any criticism personally. Leaveyour 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 acouple hundred lines), how much time will be spent (acouple hours), what can be commented on, and so on. Thisis important so that the participants know what their rolesare and what they should expect. It helps the review runmore 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 needto know what their duties and responsibilities are and beready to actively fulfill them at the review. Most of theproblems found through the review process are foundduring preparation, not at the actual review.

Write a Report. The review group must produce awritten report summarizing the results of the review andmake that report available to the rest of the product

8/7/2019 2nd asmt



development team. It's imperative that others are toldthe results of the meetinghow many problems werefound, where they were found, and so on.

What makes formal reviews work is following an establishedprocess. Haphazardly "getting together to go over some code"isn't sufficient and may actually be detrimental. If a process isrun in an ad-hoc fashion, bugs will be missed and theparticipants will likely feel that the effort was a waste of time.

If the reviews are run properly, they can prove to be a greatway to find bugs early. Think of them as one of the initial nets

(see Figure 6.1) that catches the big bugs at the beginning of the process. Sure, smaller bugs will still get through, but they'llbe caught in the next testing phases with the smaller nets withthe tighter weave.

In addition to finding problems, holding formal reviewshas a few indirect results:

• Communications . Information not contained in theformal report is communicated. For example, the black-box testers can get insight into where problems may lie.Inexperienced programmers may learn new techniquesfrom more experienced programmers. Management mayget a better feel for how the project is tracking itsschedule.

• Quality . A programmer's code that is being gone over indetail, function by function, line by line, often results inthe programmer being more careful. That's not to saythat he would otherwise be sloppyjust that if he knowsthat his work is being carefully reviewed by his peers, hemight make an extra effort to triple-check it to make surethat it's right.

• Team Camaraderie . If a review is run properly, it can bea good place for testers and programmers to build

8/7/2019 2nd asmt



respect for each other's skills and to better understandeach other's jobs and job needs.

• Solutions . Solutions may be found for tough problems,although whether they are discussed depends on therules for the review. It may be more effective to discusssolutions outside the review.

These indirect benefits shouldn't be relied on, but they dohappen. On many teams, for whatever reasons, the membersend up working in isolation. Formal reviews are a great way toget them in the same room, all discussing the same projectproblems.

Peer Reviews

The easiest way to get team members together and doingtheir first formal reviews of the software is through peerreviews, the least formal method. Sometimes called buddyreviews, this method is really more of an "I'll show you mine if you show me yours" type discussion.

Walkthroughs

Walkthroughs are the next step up in formality from peerreviews. In a walkthrough, the programmer who wrote thecode formally presents (walks through) it to a small group of five or so other programmers and testers. The reviewersshould receive copies of the software in advance of the reviewso they can examine it and write comments and questions thatthey want to ask at the review. Having at least one seniorprogrammer as a reviewer is very important.

Inspections

Inspections are the most formal type of reviews. They arehighly structured and require training for each participant.Inspections are different from peer reviews and walkthroughsin that the person who presents the code, the presenter orreader, isn't the original programmer. This forces someoneelse to learn and understand the material being presented,potentially giving a different slant and interpretation at the

8/7/2019 2nd asmt



inspection meeting.

Inspections have proven to be very effective in finding bugs inany software deliverable, especially design documents andcode, and are gaining popularity as companies and productdevelopment teams discover their benefits.

Q6. Is it acceptable to release a Software Productthat has Configuration Bugs?

ANS: NO its not accepatale to release software product thathaving configuration bugs because itEffect the reliability or usability of the software and also affectthe reputation of the software so never should release thesoftware that having configuration bugs. To avoid thiscompany or programmer should having concentrate on thefollowing areas.

1. Once you release the first version of your softwareproduct and the marketing machine is starting to roll on,

you might think about what to do next. You probablythink about all the great features which haven’t made itinto the 1.0 and are now waiting to be implemented. Youcan’t wait to start your editor and start hacking rightaway. But wait! Think twice about what you do next,because adding features to software is quite differentafter you released it.

Backwards Compatibility

Ever wondered why Microsoft is so successful? It is widelyknown that they had really buggy releases in the past. And it isalso known that many products of their competitors are of thesame or even better quality. But today they are the biggestsoftware company in the world and this is obviously a bigaccomplishment.

Besides great marketing and delivering products the userswant, they are known for keeping their software backward

http://blogs.msdn.com/oldnewthing/


8/7/2019 2nd asmt



compatible . They go to great strength to guarantee thatapplications still work on newer versions of their operatingsystem, even when they have to work around bugs in theoriginal software application.

Listen To Your Customers

One of the great aspects when your software goes public isthat you get more feedback. If something is missing or notworking as expected, your customers will tell you faster thanyou can fix or implement it. Some feature requests or bugreports might be surprising, something you never thought of when you developed your software. Others are more expected.

Whatever customers report, keep track of it. If you have manyrequests for a particular feature and it seems logical toimplement it, then look at it in more detail. You should also tryto find similarities between the different feature requests andthen choose the best way to implement it. Try to bring yoursoftware to the next level based on your customersuggestions.

.

Carefully Choose New Features

Once you have a list of features you want to add, you shouldlook at them in more detail. In my opinion, it’s usually a goodidea to look at the usability improvements first. Normally thosethings are easy to change or enhance and they add a greatvalue to your product.

There are more things to pay attention to. Think aboutimproving your documentation. A detailed and usefuldocumentation can save you and your customers a lot of timeif it’s so good that there’s no need to ask you how a specificfeature works or how to use it. When it comes to biggerchanges, verify if they are really worth it. They need to addreal value to your program. Don’t add any features if they are




8/7/2019 2nd asmt



not going to be used anyway.

Take Up Time to Release

You should always plan to do a comprehensive testing phasebefore releasing a new version. You don’t want to release aversion that has more quirks and bugs than your previous one,do you? Carefully test new and old functionality. Think aboutpossible side effects your changes might cause.

A good idea is to use automated tests. This way you canalways easily ensure that old functionality still works as

expected after changing your code. This is called regressiontesting – verifying that a previously working feature still workscorrectly after adding new features or fixing bugs.

Q7. In addition to age and popularity what othercriteria might you use to equivalence PartitionHardware for Configuration testing?

In addition to age and popularity other criteria that we might

use to equivalence Partition Hardware for Configuration testingare: -

Type : - First work to do this type of equivalence partitioning isto break the software world into types such as painting,writing, accounting, databases, communications, and so on likesoftware is for only accounting like Tally software or forcreating high level graphics and motion pictures used for CAD,as presentation graphics that needs special hardware. Thennext thing to do is select hardware from each category fortesting.

Manufacturer : -Another criterion would be to pick hardwarebased on the company that created it.

we have chosen, place or country is a possibility as somehardware devices such as DVD players only work with DVDs intheir geographic region. Another might be consumer or

8/7/2019 2nd asmt



business. Some hardware is specific to one, but not the other.

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

Unit testing refers to tests that verify the functionality of aspecific section of code, usually at the function level. In anobject-oriented environment, this is usually at the class level,and the minimal unit tests include the constructors anddestructors.

These type of tests are usually written by developers as theywork on code (white-box style), to ensure that the specificfunction is working as expected. One function might havemultiple tests, to catch corner cases or other branches in thecode. Unit testing alone cannot verify the functionality of apiece of software, but rather is used to assure that the buildingblocks the software uses work independently of each other.

Unit testing is also called Component Testing.

Integration testing is any type of software testing that seeksto verify the interfaces between components against asoftware design. Software components may be integrated inan iterative way or all together ("big bang"). Normally theformer is considered a better practice since it allows interfaceissues to be localised more quickly and fixed.

Integration testing works to expose defects in the interfacesand interaction between integrated components (modules).Progressively larger groups of tested software componentscorresponding to elements of the architectural design areintegrated and tested until the software works as a system.

System testing tests a completely integrated system to

http://en.wikipedia.org/wiki/Integration_testing

http://en.wikipedia.org/wiki/System_testing


http://en.wikipedia.org/wiki/System_testing

8/7/2019 2nd asmt



verify that it meets its requirements

System integration testing verifies that a system isintegrated to any external or third party systems defined in thesystem requirements.

Regression testing focuses on finding defects after a majorcode change has occurred. Specifically, it seeks touncover software regressions , or old bugs that have come

back. Such regressions occur whenever software functionalitythat was previously working correctly stops working asintended. Typically, regressions occur as an unintendedconsequence of program changes, when the newly developedpart of the software collides with the previously existing code.Common methods of regression testing include re-runningpreviously run tests and checking whether previously fixedfaults have re-emerged. The depth of testing depends on the

phase in the release process and the risk of the addedfeatures. They can either be complete, for changes added latein the release or deemed to be risky, to very shallow,consisting of positive tests on each feature, if the changes areearly in the release or deemed to be of low risk.

Acceptance testing can mean one of two things:

1. A smoke test is used as an acceptance test prior to

introducing a new build to the main testing process, i.e.before integration or regression .2. Acceptance testing performed by the customer,often in their lab environment on their own HW, is knownas user acceptance testing (UAT). Acceptance testingmay be performed as part of the hand-off processbetween any two phases of development

http://en.wikipedia.org/wiki/System_integration_testing

http://en.wikipedia.org/wiki/Software_regression

http://en.wikipedia.org/wiki/Unintended_consequence


http://en.wikipedia.org/wiki/Risk_management

http://en.wikipedia.org/wiki/Smoke_test


http://en.wikipedia.org/wiki/Regression_testing

http://en.wikipedia.org/wiki/Acceptance_testing#User_acceptance_testing

http://en.wikipedia.org/wiki/System_integration_testing

http://en.wikipedia.org/wiki/Software_regression



http://en.wikipedia.org/wiki/Risk_management

http://en.wikipedia.org/wiki/Smoke_test


http://en.wikipedia.org/wiki/Regression_testing

http://en.wikipedia.org/wiki/Acceptance_testing#User_acceptance_testing

8/7/2019 2nd asmt



Alpha testing

Alpha testing is simulated or actual operational testing bypotential users/customers or an independent test team at the

developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, beforethe software goes to beta testing.

Beta testing

Beta testing comes after alpha testing. Versions of thesoftware, known as beta versions , are released to a limitedaudience outside of the programming team. The software is

released to groups of people so that further testing can ensurethe product has few faults or bugs . Sometimes, beta versionsare made available to the open public to increasethe feedback field to a maximal number of future users. [

Q9. Relate verification and validation to the Qualitycontrol and Quality Assurance with an example?

Verification and validation is the process of checkingthat a product, service, or system meets specifications andthat it fulfills its intended purpose. These are criticalcomponents of a quality management system such as ISO9000 . Sometimes preceded with "Independent" (or IV&V) toensure the validation is performed by a disinterested thirdparty.

Verification is a Quality control process that is used toevaluate whether or not a product, service, or systemcomplies with regulations, specifications , or conditions

http://en.wikipedia.org/wiki/Beta_version

http://en.wikipedia.org/wiki/Computer_bug

http://en.wikipedia.org/wiki/Feedback#In_organizations

http://en.wikipedia.org/wiki/Quality_management_system

http://en.wikipedia.org/wiki/ISO_9000


http://en.wikipedia.org/wiki/Verification

http://en.wikipedia.org/wiki/Quality_control

http://en.wikipedia.org/wiki/Specification

http://en.wikipedia.org/wiki/Beta_version

http://en.wikipedia.org/wiki/Computer_bug

http://en.wikipedia.org/wiki/Feedback#In_organizations

http://en.wikipedia.org/wiki/Quality_management_system



http://en.wikipedia.org/wiki/Verification

http://en.wikipedia.org/wiki/Quality_control

http://en.wikipedia.org/wiki/Specification

8/7/2019 2nd asmt



imposed at the start of a development phase. Verificationcan be in development, scale-up, or production. This isoften an internal process.

Validation is a Quality assurance process of establishingevidence that provides a high degree of assurance that aproduct, service, or system accomplishes its intendedrequirements. This often involves acceptance of fitness forpurpose with end users and other product stakeholders.

It is sometimes said that validation can be expressed bythe query "Are you building the right thing?" andverification by "Are you building it right?" "Building theright thing" refers back to the user's needs, while "buildingit right" checks that the specifications be correctlyimplemented by the system. In some contexts, it isrequired to have written requirements for both as well asformal procedures or protocols for determining compliance

Q10. In a code review check list there are someitems as given below .Categories them.

1. Is the entire conditional path reachable?2. If the pointers are used, are they initializedproperly?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?

1. Entire conditional path categorize in the control flowerrors of code review checklist.

2. If pointers are used they are initialized they arecoming under the category of data declaration errors.because if they are not initialized then they can havegarbage value and that leads to dangling pointer

http://en.wikipedia.org/wiki/Validation

http://en.wikipedia.org/wiki/Quality_assurance

http://en.wikipedia.org/wiki/Validation

http://en.wikipedia.org/wiki/Quality_assurance

8/7/2019 2nd asmt



3. No, every part of the code is reachable, which is basedon the conditions to execute that statements bunch .

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

2nd asmt

Documents