Dhomaseghanshyam.files.wordpress.com



BE Computer 2015 Pattern

Software Testing Quality Assurance

Mock END Paper Solution 2019-20 SEM-1

Q-1 a) What is bug, defect, error & failure give an example of each?

Ans- DEFECT:  It can be simply defined as a variance between expected and actual. Defect is an error found AFTER the application goes into production. It commonly refers to several troubles with the software products, with its external behavior or with its internal features. In other words Defect is the difference between expected and actual result in the context of testing.  It is the deviation of the customer requirement.

Defect can be categorized into the following:

Wrong: When requirements are implemented not in the right way. This defect is a variance from the given specification. It is Wrong!

Missing:  A requirement of the customer that was not fulfilled. This is a variance from the specifications, an indication that a specification was not implemented, or a requirement of the customer was not noted correctly.

Extra: A requirement incorporated into the product that was not given by the end customer. This is always a variance from the specification, but may be an attribute desired by the user of the product. However, it is considered a defect because it’s a variance from the existing requirements.

ERROR: An error is a mistake, misconception, or misunderstanding on the part of a software developer. In the category of developer we include software engineers, programmers, analysts, and testers. For example, a developer may misunderstand a de-sign notation, or a programmer might type a variable name incorrectly – leads to an Error. It is the one which is generated because of wrong login, loop or due to syntax. Error normally arises in software; it leads to change the functionality of the program.

BUG: A bug is the result of a coding error. An Error found in the development environment before the product is shipped to the customer. A programming error that causes a program to work poorly, produce incorrect results or crash. An error in software or hardware that causes a program to malfunction. Bug is terminology of Tester.

FAILURE: A failure is the inability of a software system or component to perform its required functions within specified performance requirements. When a defect reaches the end customer it is called a Failure. During development Failures are usually observed by testers.

FAULT: An incorrect step, process or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. A fault is introduced into the software as the result of an error. It is an anomaly in the software that may cause it to behave incorrectly, and not according to its specification. It is the result of the error.

Q-1 b) Differentiate between software Testing tool and Technique.

Ans- Technique is the actual method/manner/way to perform a particular task.

Tools are the objects or means which help in performing the tasks.

For example, Painting is a task and there are different techniques like oil painting, etc. Then there are some paintin gtools - like crayons, brushes, poster colors etc. Hope this makes sense...

When we talk in terms of software testing,

Testing techniques are the types of testing . Various testing techniques are functional testing, performance testing etc. They can be furthwer classified into many techniques.

Testing tools are software programs clubbed together to per testing activities. These tools generally provide record and playback features along with common scripting platform to customize the tests. Common functional testing tools are - Quick Test Professional, Selenium etc. Common performance testing tools are Load Runner, Rational Performance Tester etc.

Imagine traveling from point A to B is the test that you need to perform. And the above image suggests that there are 2 ways to do it

• Test technique 1 - By Running

• Test technique 2 - By walking

But in both these 2 techniques, one thing is common. The tool/ component used to implement these techniques. In both these techniques, the person uses his/ her legs to either run on walk.

So, Testing tools are the components or software packages you you to test an application, while the testing techniques dictates how you use these tools to test your application.

Practical example would be

Testing tool - Selenium WebDriver

Testing technique 1 - Sanity test script

Testing technique 2 - Regression test script

Q-2 a) what is impact of defect in different phases of Software development.

Ans- The cost of defects can be measured by the impact of the defects and when we find them. Earlier the defect is found lesser is the cost of defect. For example if error is found in the requirement specifications during requirements gathering and analysis, then it is somewhat cheap to fix it. The correction to the requirement specification can be done and then it can be re-issued.

In the same way when defect or error is found in the design during design review then the design can be corrected and it can be re-issued. But if the error is not caught in the specifications and is not found till the user acceptance then the cost to fix those errors or defects will be way too expensive.

If the error is made and the consequent defect is detected in the requirements phase then it is relatively cheap to fix it.

Similarly if a requirement specification error is made and the consequent defect is found in thedesign phase then the design can be corrected and reissued with relatively little expense.

[pic]

The same applies for construction phase. If however, a defect is introduced in the requirement specification and it is not detected until acceptance testing or even once the system has been implemented then it will be much more expensive to fix. This is because rework will be needed in the specification and design before changes can be made in construction; because one defect in the requirements may well propagate into several places in the design and code; and because all the testing work done-to that point will need to be repeated in order to reach the confidence level in the software that we require.

It is quite often the case that defects detected at a very late stage, depending on how serious they are, are not corrected because the cost of doing so is too expensive.

b) What is bug tracking, bug fixing & bug verification?

Ans- Bug tracking means tracking the status of any bug until it get closed. At any point of time a bug must be in any of the states given below in the diagram-

[pic]

There are several stages in a bug life cycle

• Open – bug that is raised and yet to be validated.

• In Progress – bug is validated and under fixing.

• Not a Bug – Sometimes developer or team lead can mark the bug as “Not a Bug” if the system is working according to specifications and bug is just due to some misinterpretation.

• Deferred – When a bug cannot be addressed in that particular cycle it is deferred to future release.

• Duplicate – Same bug is already logged by QA team.

• Fixed – Bug has been fixed by developer and QA has to verify it in next build.

• Reopened – When the bug is NOT fixed, QA reopens/reactivates the bug.

• Closed – If bug is verified by the QA team and it is fixed then QA can mark bug as ‘Closed’ or a bug can be closed if the defect is duplicate or considered as NOT as bug.

Bug fix: A bug is a a mistake in the code A fix is a correction of that mistake

A bug is a flaw in a piece of software that causes it to not to do what was intended. A bug could be in the specification of the software (we should have made it do this instead of that), in the design and coding of the software (we said it should do this but it does that instead), or sometimes in the documentation (the software does exactly what we want it to do, but the user manual says something different). A coding (programming) bug can manifest as incorrect results or crashes in the software system.

A bug fix is, simply the fix to a bug, that is, the set of modifications to the software system that would correct the flaw. For example:

• Bug: The “cancel” button runs off the right edge of the screen on smaller phones.

• Bug fix: Change the code to position the “cancel” button farther to the left.

Bug Fix Verification is a process of verifying if the bug was fixed or not. SO At first a tester re-tests application and then checks whether new bugs appeared after the previous bug was fixed.

Q. 3 A) Write test cases for simple calculator application.

Ans-

|No. |Test Case -ID |Test case Objec tive |Prereq uisite |

|BSR1 |Application Login and |Student, Professor, |A student can login with correct username and password (i.e. credentials) only if |

| |Logout |Dean, Staff |user role is selected as ‘Student’. Similarly it applies to user role as Professor, |

| | | |Dean, and Staff. |

|BSR2 |Profile Page |Student, Professor, |Student, Professor, Dean, and Staff post successful login could see their profile |

| | |Dean, Staff |details not the other profiles. |

|BSR3 |Task Assignment |Student, Professor, |Student can accept or decline assignments assigned by Professor. Dean can approve and|

| | |Dean, Staff |disapprove the assignment assigned by professor. Professor can approve and disapprove|

| | | |assignment submitted by Student. Staff is to capture the grade and marks submitted by|

| | | |professor towards student assignment. |

STEP 2: Our corresponding (Functional requirement Document) FRD will look as shown below.

|Functional Requirement (FTR) |Description |

|FTR1 |User ID is a required field and cannot be empty. |

|FTR2 |Password is a required field and cannot be empty. |

|FTR3 |User role is a required field and should be chosen among Student, Professor, Dean, Staff. |

|FTR4 |User ID, Password, and User Role are valid. Login Successful. |

|FTR5 |If User ID or Password is wrong but User Role is valid. Login Unsuccessful. |

|FTR6 |If User ID and Password are correct but User Role is invalid. Login Unsuccessful. |

|FTR7 |Student, Professor, Dean, Staff can see their receptive profile page. |

|FTR8 |Assignment Task can only be assigned by Professor. |

|FTR9 |Student can accept or decline the assignment Task. |

|FTR10 |Dean can approve or disapprove the assignment accepted by Student. |

|FTR11 |Professor can approve or disapprove the assignment submitted by Student. |

|FTR12 |Staff can capture the grade or marks provided by Professor towards Student’s assignment. |

STEP 3: Testing team can use these two documents (i.e. BRD and FRD) and start preparing test cases (say the Test case covers successful login).

|Test Case ID |Test Case Name |Test Steps |Test Data |Expected Result |

|TC1 |Successful Login |1) Browse the Login page |Userid=abc123 |Successful Login and profile page is |

| | |URL. |Password=123456 |visible. |

| | |2) Enter correct user ID |User Role= STUDENT | |

| | |3) Enter Correct password | | |

| | |4) Enter correct user role | | |

|TC2 |Unsuccessful Login due to invalid username and |1) Browse the Login page |Userid=abc123 |Unsuccessful Login and Login page will |

| |password |URL. |Password=wrong |show error. |

| | |2) Enter correct user ID |User Role= STUDENT | |

| | |3) Enter wrong password | | |

| | |4) Enter correct user role | | |

|TC3 |Unsuccessful Login due to invalid user role |1) Browse the Login page |Userid=abc123 |Unsuccessful Login and Login page will |

| | |URL. |Password=123456 |show error. |

| | |2) Enter correct user ID |User Role= DEAN | |

| | |3) Enter Correct password | | |

| | |4) Enter wrong user role | | |

STEP 4: Let’s map the Business Requirement ID (BSR), and Functional Requirement ID (FTR) to the above Test Case. Above table will look as shown below.

|Test Case ID |BSR |FTR |

|TC1 |BSR1 |FTR4 |

|TC2 |BSR1 |FTR5 |

|TC3 |BSR1 |FTR6 |

Requirement Traceability matrix (RTM)

Q-6 B) What is mutation testing? give an example

Ans- Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors. It is a type of White Box Testing which is mainly used for Unit Testing. The changes in mutant program are kept extremely small, so it does not affect the overall objective of the program.

The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as Fault based testing strategy as it involves creating fault in the program

Mutation was originally proposed in 1971 but lost fervor due to high costs involved. Now, again it has picked steam and is widely used for languages such as Java and XML.

[pic]

Following are the steps to execute mutation testing:

Step 1: Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.

Step 2: Test cases are applied to the original program and also to the mutant program. A Test Case should be adequate, and it is tweaked to detect faults in a program.

Step 3: Compare the results of original and mutant program.

Step 4: If the original program and mutant programs generate the different output, then that the mutant is killed by the test case. Hence the test case is good enough to detect the change between the original and the mutant program.

Step 5: If the original program and mutant program generate same output, Mutant is kept alive. In such cases, more effective test cases need to be created that kill all mutants.

Original Program Mutant program

If (x>y) If(x ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download