Showing posts with label Software Testing Tutorials. Show all posts
Showing posts with label Software Testing Tutorials. Show all posts

Monday, May 23, 2011

Software Testing Some Importent Tips

What are the steps to perform software testing?
  • Understand requirements and business logic
  • Determine required standards and processes
  • Set priorities, and determine scope and limitations of tests
  • Determine test approaches and methods
  • Determine test environment, test ware, test input data requirements
  • Set milestones and prepare test plan document
  • Write test cases
  • Have needed reviews/inspections/approvals of test cases
  • Set up test environment
  • Execute test cases
  • Evaluate and report results
  • Bug Tracking and fixing
  • Retesting or regression testing if needed
  • Update test plans, test cases, test results, traceability matrix etc.
. What are the components of a bug report?
  • Application name
  • The function, module, name
  • Bug ID
  • Bug reporting date
  • Status
  • Test case ID
  • Bug description
  • Steps needed to reproduce the bug
  • Names and/or descriptions of file/data/messages/etc. used in test
  • Snapshot that would be helpful in finding the cause of the problem
  • Severity estimate
  • Was the bug reproducible?
  • Name of tester
  • Description of problem cause (filled by developers)
  • Description of fix (filled by developers)
  • Code section/file/module/class/method that was fixed (filled by developers)
  • Date of fix (filled by developers)
  • Date of retest or regression testing
  • Any remarks or comments
What is configuration management?

It covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools / compilers / libraries / patches, changes made to them, and who makes the changes.

How can web based applications be tested?

Apart from functionality consider the following:
  • What are the expected loads on the server and what kind of performance is expected on the client side?
  • Who is the target audience?
  • Will down time for server and content maintenance / upgrades be allowed?
  • What kinds of security will be required and what is it expected to do?
  • How reliable are the site's Internet / intranet connections required to be?
  • How do the internet / intranet affect backup system or redundant connection requirements and testing?
  • What variations will be allowed for targeted browsers?
  • Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site?
  • How will internal and external links be validated and updated?
  • How are browser caching and variations in browser option settings?
  • How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?

From the usability point of view consider the following:

  • Pages should be 3-5 screens longer.
  • The page layouts and design elements should be consistent throughout the application / web site.
  • Pages should be as browser-independent or generate based on the browser-type.
  • There should be no dead-end pages. A link to a contact person or organization should be included on each page.
Read More about Software Testing Tutorials

Monday, October 20, 2008

Web Testing: Complete guide on testing web applications

Let’s have first web testing checklist.
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing

1) Functionality Testing:

Test for - all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.

Check all the links:

  • Test the outgoing links from all the pages from specific domain under test.
  • Test all internal links.
  • Test links jumping on the same pages.
  • Test links used to send the email to admin or other users from web pages.
  • Test to check if there are any orphan pages.
  • Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:
Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?

  • First check all the validations on each field.
  • Check for the default values of fields.
  • Wrong inputs to the fields in the forms.
  • Options to create forms if any, form delete, view or modify the forms.

Let’s take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps. So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated web testing.

Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing)

Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to different search engines.

Database testing:
Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below.

2) Usability Testing:

Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.

Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing

Other user information for user help:
Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.

3) Interface Testing:
The main interfaces are:
Web server and application server interface
Application server and Database server interface.

Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between?

4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:

  • Browser compatibility
  • Operating system compatibility
  • Mobile browsing
  • Printing options

Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.

Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.

5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing

Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.

In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,

6) Security Testing:

Following are some test cases for web security testing:

  • Test by pasting internal url directly into browser address bar without login. Internal pages should not open.
  • If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user. Access should denied for this user to view others stats.
  • Try some invalid inputs in input fields like login username, password, input text boxes. Check the system reaction on all invalid inputs.
  • Web directories or files should not be accessible directly unless given download option.
  • Test the CAPTCHA for automates scripts logins.
  • Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.
  • All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

REMEMBER SOFTWARE TESTING 10 RULES

1. Test early and test often.
2. Integrate the application development and testing life cycles. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.
3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
5. Use both static and dynamic testing.
6. Define your expected results.
7. Understand the business reason behind the application. You’ll write a better application and better testing scripts.
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
9. Review and inspect the work, it will lower costs.
10. Don’t let your programmers check their own work; they’ll miss their own errors.

Website Cookie Testing

What is Cookie?

Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.

For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server don’t know anything about to whom the previous page 1.html served.

What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.

How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.

How cookies are stored?
Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.

Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM

Applications where cookies can be used:

1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.

2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.

3) User tracking:
To track number of unique visitors online at particular time.

4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.

5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.

Drawbacks of cookies:

1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic.

2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.

3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.

Some Major Test cases for web application cookie testing:

The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.

Test cases:

1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.

2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.

3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.

4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)

5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.

6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.

7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.

8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.

9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.

10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.

These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations. If you have some different application scenario, you can mention your test cases in comments below.

Read More about Software Testing Tutorials


Tuesday, September 16, 2008

Levels of Testing

Levels of Testing

  1. Unit Testing.
    • Unit Testing is primarily carried out by the developers themselves.
    • Deals functional correctness and the completeness of individual program units.
    • White box testing methods are employed


  2. Integration Testing.
    • Integration Testing: Deals with testing when several program units are integrated.
    • Regression testing : Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least.
    • Incremental Integration Testing : Checks out for bugs which encounter when a module has been integrated to the existing.
    • Smoke Testing : It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing.


  3. System Testing.
    • System Testing - Deals with testing the whole program system for its intended purpose.
    • Recovery testing : System is forced to fail and is checked out how well the system recovers the failure.
    • Security Testing : Checks the capability of system to defend itself from hostile attack on programs and data.
    • Load & Stress Testing : The system is tested for max load and extreme stress points are figured out.
    • Performance Testing : Used to determine the processing speed.
    • Installation Testing : Installation & uninstallation is checked out in the target platform.


  4. Acceptance Testing.
    • UAT ensures that the project satisfies the customer requirements.
    • Alpha Testing : It is the test done by the client at the developer’s site.
    • Beta Testing : This is the test done by the end-users at the client’s site.
    • Long Term Testing : Checks out for faults occurrence in a long term usage of the product.
    • Compatibility Testing : Determines how well the product is substantial to product transition.
Read More about Software Testing Tutorials

Monday, March 17, 2008

SQL Testing Information.

Types of Joins:

Joins are one of the most important operations performed by a relational database system. An RDBMS uses joins to match rows from one table with rows from another table. For example, we can use joins to match sales with customers or books with authors. Without joins, we might have a list of sales and customers or books and authors, but we would have no way to determine which customers bought which items or which authors wrote which books.

We can join two tables explicitly by writing a query that lists both tables in the FROM clause. We can also join two tables by using a variety of different sub-queries. Finally, SQL Server may introduce joins for a variety of purposes into a query plan during optimization.

This is the first of several posts that I am planning for joins. In this post, I’m going to start by introducing the logical join operators that SQL Server supports. These are:

While different implementations have many ways of joining tables, you concentrate on the most common joins in this lesson. The types of joins that you learn are

  • EQUIJOINS( Inner join)
  • NATURAL JOINS
  • NON-EQUIJOINS
  • Using Table Aliases
  • OUTER JOINS
  • SELF JOINS
  • Cross join
  • Cross apply
  • Semi-join
  • Anti-semi-join

Here is a simple schema and data set that I will use to illustrate each join type:

create table Customers (Cust_Id int, Cust_Name varchar(10))

insert Customers values (1, 'Craig')

insert Customers values (2, 'John Doe')

insert Customers values (3, 'Jane Doe')

create table Sales (Cust_Id int, Item varchar(10))

insert Sales values (2, 'Camera')

insert Sales values (3, 'Computer')

insert Sales values (3, 'Monitor')

insert Sales values (4, 'Printer')

Inner joins

Perhaps the most used and important of the joins is the EQUIJOIN, also referred to as an INNER JOIN. The EQUIJOIN joins two tables with a common column in which each is usually the primary key.

The syntax for an EQUIJOIN is

SELECT TABLE1.COLUMN1, TABLE2.COLUMN2...
FROM TABLE1, TABLE2 [, TABLE3 ]
WHERE TABLE1.COLUMN_NAME = TABLE2.COLUMN_NAME
[ AND TABLE1.COLUMN_NAME = TABLE3.COLUMN_NAME ]

NOTE

Inner joins are the most common join type. An inner join simply looks for two rows that put together satisfy a join predicate. For example, this query uses the join predicate “S.Cust_Id = C.Cust_Id” to find all Sales and Customer rows with the same Cust_Id:

select *

from Sales S inner join Customers C

on S.Cust_Id = C.Cust_Id

Cust_Id Item Cust_Id Cust_Name

----------- ---------- ----------- ----------

2 Camera 2 John Doe

3 Computer 3 Jane Doe

3 Monitor 3 Jane Doe

Notes:

  • Cust_Id 3 bought two items so this customer row appears twice in the result.
  • Cust_Id 1 did not purchase anything and so does not appear in the result.
  • We sold a ‘Printer’ to Cust_Id 4. There is no such customer so this sale does not appear in the result.

Inner joins are fully commutative. “A inner join B” and “B inner join A” are equivalent.

Natural Joins

A NATURAL JOIN is nearly the same as the EQUIJOIN; however, the NATURAL JOIN differs from the EQUIJOIN by eliminating duplicate columns in the joining columns. The JOIN condition is the same, but the columns selected differ.

The syntax is as follows:

SELECT TABLE1.*, TABLE2.COLUMN_NAME
    [ TABLE3.COLUMN_NAME ]
FROM TABLE1, TABLE2 [ TABLE3 ]
WHERE TABLE1.COLUMN_NAME = TABLE2.COLUMN_NAME
[ AND TABLE1.COLUMN_NAME = TABLE3.COLUMN ]

Look at the following example:

SELECT EMPLOYEE_TBL.*, EMPLOYEE_PAY_TBL.SALARY
FROM EMPLOYEE_TBL,
   EMPLOYEE_PAY_TBL
WHERE EMPLOYEE_TBL.EMP_ID = EMPLOYEE_PAY_TBL.EMP_ID;

This SQL statement returns all columns from EMPLOYEE_TBL and SALARY from the EMPLOYEE_PAY_TBL. The EMP_ID is in both tables, but is retrieved only from the EMPLOYEE_TBL because both contain the same information and do not need to be selected.

The following example selects all columns from the EMPLOYEE_TBL table and only one column from the EMPLOYEE_PAY_TBL table. Remember that the asterisk (*) represents all columns of a table.

SELECT EMPLOYEE_TBL.*, EMPLOYEE_PAY_TBL.POSITION
FROM EMPLOYEE_TBL, EMPLOYEE_PAY_TBL
WHERE EMPLOYEE_TBL.EMP_ID = EMPLOYEE_PAY_TBL.EMP_ID;
EMP_ID     LAST_NAM FIRST_NA M ADDRESS          CITY         ST  ZIP  PHONE
---------- -------- -------- - -------------   ------------  -- ----- ----------
PAGER      POSITION
---------- --------------
311549902  STEPHENS TINA     D  RR 3 BOX 17A    GREENWOOD    IN 47890 3178784465
           MARKETING
 
442346889  PLEW     LINDA    C  3301 BEACON     INDIANAPOLIS IN 46224 3172978990
           TEAM LEADER
 
213764555 GLASS    BRANDON S 1710 MAIN ST    WHITELAND    IN 47885 3178984321
3175709980 SALES MANAGER
 
313782439 GLASS    JACOB       3789 RIVER BLVD INDIANAPOLIS IN 45734 3175457676
8887345678 SALESMAN
 
220984332  WALLACE  MARIAH      7889 KEYSTONE   INDIANAPOLIS IN 46741 3173325986
           SHIPPER
 
443679012  SPURGEON TIFFANY     5 GEORGE COURT  INDIANAPOLIS IN 46234 3175679007
           SHIPPER

6 rows selected.

NOTE

Notice how the output has wrapped in the previous example. The wrap occurred because the length of the line has exceeded the limit for the line (which is usually 80 characters per line by default).

Using Table Aliases

The use of table aliases means to rename a table in a particular SQL statement. The renaming is a temporary change. The actual table name does not change in the database. As you will learn later in this hour, giving the tables aliases is a necessity for the SELF JOIN. Giving tables aliases is most often used to save keystrokes, which results in the SQL statement being shorter and easier to read. In addition, fewer keystrokes means fewer keystroke errors. Also, programming errors are typically less frequent if you can refer to an alias, which is often shorter in length and more descriptive of the data with which you are working. Giving tables aliases also means that the columns being selected must be qualified with the table alias. The following are some examples of table aliases and the corresponding columns:

SELECT E.EMP_ID, EP.SALARY, EP.DATE_HIRE, E.LAST_NAME
FROM EMPLOYEE_TBL E,
   EMPLOYEE_PAY_TBL EP
WHERE E.EMP_ID = EP.EMP_ID
AND EP.SALARY > 20000;

The tables have been given aliases in the preceding SQL statement. The EMPLOYEE_TBL has been renamed E. The EMPLOYEE_PAY_TBL has been renamed EP. The choice of what to rename the tables is arbitrary. The letter E is chosen because the EMPLOYEE_TBL starts with E. Because the EMPLOYEE_PAY_TBL also begins with the letter E, you could not use E again. Instead, the first letter (E) and the first letter of the second word in the name (PAY) are used as the alias. The selected columns were justified with the corresponding table alias. Note that SALARY was used in the WHERE clause and must also be justified with the table alias.

Joins of Non-Equality

NON-EQUIJOIN joins two or more tables based on a specified column value not equaling a specified column value in another table. The syntax for the NON-EQUIJOIN is

FROM TABLE1, TABLE2 [, TABLE3 ]
WHERE TABLE1.COLUMN_NAME != TABLE2.COLUMN_NAME
[ AND TABLE1.COLUMN_NAME != TABLE2.COLUMN_NAME ]

Cross joins

A cross join performs a full Cartesian product of two tables. That is, it matches every row of one table with every row of another table. You cannot specify a join predicate for a cross join using the ON clause though you can use a WHERE clause to achieve essentially the same result as an inner join.

Cross-joins are fairly uncommon. Two large tables should never be cross joined as this will result in a very expensive operation and a very large result set.

select *

from Sales S cross join Customers C

Cust_Id Item Cust_Id Cust_Name

----------- ---------- ----------- ----------

2 Camera 1 Craig

3 Computer 1 Craig

3 Monitor 1 Craig

4 Printer 1 Craig

2 Camera 2 John Doe

3 Computer 2 John Doe

3 Monitor 2 John Doe

4 Printer 2 John Doe

2 Camera 3 Jane Doe

3 Computer 3 Jane Doe

3 Monitor 3 Jane Doe

4 Printer 3 Jane Doe

Cross apply

We introduced cross apply in SQL Server 2005 to enable joins with a table valued function (TVF) where the TVF has a parameter that changes for each execution. For example, the following query returns the same result as the above inner join using a TVF and cross apply:

create function dbo.fn_Sales(@Cust_Id int)

returns @Sales table (Item varchar(10))

as

begin

insert @Sales select Item from Sales where Cust_Id = @Cust_Id

return

end

select *

from Customers cross apply dbo.fn_Sales(Cust_Id)

Cust_Id Cust_Name Item

----------- ---------- ----------

2 John Doe Camera

3 Jane Doe Computer

3 Jane Doe Monitor

We can also use outer apply to find all Customers regardless of whether they purchased anything. This is similar to an outer join.

select *

from Customers outer apply dbo.fn_Sales(Cust_Id)

Cust_Id Cust_Name Item

----------- ---------- ----------

1 Craig NULL

2 John Doe Camera

3 Jane Doe Computer

3 Jane Doe Monitor

Semi-join and Anti-semi-join

A semi-join returns rows from one table that would join with another table without performing a complete join. An anti-semi-join returns rows from one table that would not join with another table; these are the rows that would be NULL extended if we performed an outer join.

Unlike the other join operators, there is no explicit syntax to write “semi-join,” but SQL Server uses semi-joins in a variety of circumstances. For example, we may use a semi-join to evaluate an EXISTS sub-query:

select *

from Customers C

where exists (

select *

from Sales S

where S.Cust_Id = C.Cust_Id

)

Cust_Id Cust_Name

----------- ----------

2 John Doe

3 Jane Doe

Unlike the previous examples, the semi-join only returns each customer one time.

The query plan shows that SQL Server indeed uses a semi-join:

|--Nested Loops(Left Semi Join, WHERE:([S].[Cust_Id]=[C].[Cust_Id]))
|--Table Scan(OBJECT:([Customers] AS [C]))
|--Table Scan(OBJECT:([Sales] AS [S]))

There are left and right semi-joins. A left semi-join returns rows from the left (first) input that match rows from the right (second) input while a right semi-join returns rows from the right input that match rows from the left input.

We might similarly use an anti-semi-join to evaluate a NOT EXISTS sub-query.

Miscellaneous notes

In all of the above examples, I used a join predicate that compares whether two columns, one from each table, are equal. This type of join predicate is called an “equijoin.” Other join predicates (such as inequalities) are possible, but equijoins are especially common and SQL Server has many more alternatives when optimizing equijoins than when optimizing joins with more complex predicates.

SQL Server has more flexibility over join order and algorithms when optimizing inner joins than when optimizing outer joins and cross applies. Thus, given two queries that differ only in that one strictly uses inner joins while the other uses outer joins and/or cross applies, SQL Server may be able to find a better plan for the query that uses inner joins only.

Read More about Software Testing Tutorials

Saturday, March 15, 2008

Bug Report Guidelines

Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.
Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.
Click here to read more about detail bug life cycle.

Assign To:
If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL:
The page url on which bug occurred.

Summary:
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description:
A detailed description of bug. Use following fields for description field:

  • Reproduce steps: Clearly mention the steps to reproduce the bug.
  • Expected result: How application should behave on above mentioned steps.
  • Actual result: What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.

The report types are typically:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately:If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:
Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button:
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language:
It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion:
No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.


Read More about Software Testing Tutorials

Monday, February 18, 2008

Bug Reporting

  • Blocker: No further testing work can be done.
  • Critical: Application crash, Loss of data.
  • Major: Major loss of function.
  • Minor: minor loss of function.
  • Trivial: Some UI enhancements.
  • Enhancement: Request for new feature or some enhancement in existing one.

Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.
Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.

Bug status description:
These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.

1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.

4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.

9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

Read More about Software Testing Tutorials

Friday, November 30, 2007

Testing Questions and Answers

21
Explain Path Coverage.
This measure reports whether each of the possible paths in each function have been followed. A path is a unique sequence of branches from the function entry to the exit. Also known as predicate coverage. Predicate coverage views paths as possible combination of logical conditions.
22
Explain Race Coverage.
This measure reports whether multiple threads execute the same code at the same time. It helps detect failure to synchronize access to resources. It is useful for testing multi-threaded programs such as in an operating system.
23
Explain Relational Operator Coverage.
This measure reports whether boundary situations occur with relational operators (<, <=, >, >=). The hypothesis is that boundary test cases find off-by-one errors and mistaken uses of wrong relational operators such as < instead of <=. For example, consider the following C/C++ code fragment:if (a < b) statement; Relational operator coverage reports whether the situation a==b occurs. If a==b occurs and the program behaves correctly, you can assume the relational operator is not suppose to be <=.
24
Explain Statement Coverage.
This measure reports whether each executable statement is encountered. The chief advantage of this measure is that it can be applied directly to object code and does not require processing source code. Performance profilers commonly implement this measure. The chief disadvantage of statement coverage is that it is insensitive to some control structures. For example, consider the following C/C++ code fragment:Int* p = NULL;if (condition)p = &variable;*p = 123;Without a test case that causes condition to evaluate false, statement coverage rates this code fully covered. In fact, if condition ever evaluates false, this code fails. This is the most serious shortcoming of statement coverage. If-statements are very common.


25
What is stress testing?
Test conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions.
For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity.
26
What is Security Testing?Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. For example: Firewall Test, Port Scan, Internet Security, database security
27
What is regression testing?Testing repeatedly the same thing is called Regression. This happens when there exist a bug, reported to the Dev.team, fixed and given back to the Tester. Now the tester will test not only the bug fixed but also the other stuff which was right earlier. The reason to do this is, because of the fixing of the bug reported, there is a danger that this might have resulted somewhere else as a bug.So to make sure that when ever the new build is given to the Testing Team, the full cycle of testing will be carried out. That is testing the same which already tested. In other words 'Regression testing'.
28
What is Soak Testing?
Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed. It is important to identify such situations in a test environment.
29
What is the difference between Product Testing and Application Testing?A product is developed software which is generic to all; the changes in the software will be made when the new requests/change requests raised by the client. Testing this type of product is known as product testing. A project is particularly or specifically related to one and only one client. Testing this application is known as project testing.
30
What is Database Testing?Testing the tables, data in tables, relationship between the tables, does the data is saved in a proper way in tables is known as database testing.
31
What is Configuration Testing?Testing whether the applications specified configuration is working properly or not, i.e the configurable details of the application.
32
Difference between UAT and Alpha testing and Beta testing.User Acceptance Testing (UAT): A formal product evaluation performed by a customer as a condition of purchase. The testing can be based upon the User Requirements Specification to which the system should conform. Use Acceptance testing is black box testing. User Acceptance Testing is the last stage of the Software Development Lifecycle. User acceptance testing we validating all the user requirements specified in SRS is met after code freeze. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. Before the software goes live determining if software is satisfactory to an end-user or customer. Alpha testing is done during software development to test changes and new features of the software. The purpose of alpha testing is to check the operation of the code in order to find and fix problems before the code is sent for verification and release. Because this is the first test of code that is still under development, problems are to be expected.Beta testing occurs after development and alpha testing are complete. The purpose of beta testing is to verify the operation of the software in a working environment (on live), after development and alpha testing are complete, but before the software is officially released. Software in beta test status is believed to be fully functional with no known malfunctions (bugs). Beta testing is done concurrently with the verification process.
33
What is BVT?BVT is a Build Verification Test and is normally performed, after the integration of all modules/components with the corresponding backend has been completed taken from the repository using some perl scripts (usually). Also it can be considered to be given for alpha/beta testing.
34
What is TQM?Total Quality Management (TQM) Total = Quality involves everyone and all activities in the company. Quality = Conformance to Requirements (Meeting Customer Requirements). Management = Quality can and must be managed. TQM = A process for managing quality; it must be a continuous way of life; a philosophy of perpetual improvement in everything we do.
35
Explain Walkthrough.
During a project's development, it will frequently be necessary to confirm that the individual elements of the design or work packages have been satisfied. This is design verification. This is also known as design walkthrough. A walkthrough is where the designer walks through the design or code explaining to his peers how the design works. Design verification normally takes place at intermediate stages between formal reviews and will often be a precursor to signing off a work package or a design document. Design verification may include but is not limited to: • Low Level Design • Source Code • Unit Test Plans • Unit Test Scripts • Functional Test Plans Although design verification is a less formal process than design review, actions arising during design verification shall nevertheless be recorded
36
Explain Review
Like other development activities, test strategy, planning and test design are themselves subject to errors and omissions. Therefore the test strategy, planning, specifications, etc. must have a review prior to testing. The formality of such a review will clearly vary with the level of testing applicable. What is important is that someone other than the author of a test document examines it for adequacy, feasibility and trace ability. It is widely accepted that static testing, in the form of inspections (peer review), is a very efficient method of identifying defects in code, with the additional benefit of improving team learning and speeding up knowledge transfer. Formal reviews, rather than inspections, tend to identify more defects but are more costly in terms of time and effort. Therefore any team will need to find the right balance for the product being inspected depending on the associated risk. At the end of each testing phase, a review of actual against expected test results must be undertaken to ensure that testing has been successful.
37
Explain Boundary Value Analysis
This complements equivalence partitioning by looking at the boundaries of the input equivalence classes. Test cases are devised that exercise the module with data chosen at these boundaries and also with data chosen to exercise the module on the boundaries of output data as well. For example, if an input is specified from zero to 255, the equivalence partitioning leads to values of less than 0, between 0 and 255 and greater than 255 as test input. Boundary-value analysis would suggest adding the following values:
-1 0 1
254 255 256
38
Explain Cause Effect Analysis
This requires that one must write sufficient test cases to explore the entire set of output conditions caused by a combination of input conditions, or equivalence classes of input conditions. This approach is necessary where required behavior depends upon a number of related factors or a sequence of events.
39
Explain Equivalence Partitioning
This technique relies on looking at the set of valid inputs specified for a module and dividing it up into classes of data that should, according to the specification, be treated identically. One set of test data is then devised to represent each equivalence class. The premise is that any representative will be as good as any other in finding faults in the handling of that class.
40
Explain the use of test tools.
Software testing tools can provide assistance with a number of testing activities. Examples of the types of assistance which can be provided are:
· Automation of test scripts There is a basic need for all tests to be repeatable. The repetition of tests can be made much easier by the user of test automation tools, which are able to capture and execute system-testing activities. Such activities may take the form of keyboard entry and mouse activity as well as execution of system procedures. These tools can be particularly useful for regression testing, or for stress testing where they can perhaps be used to simulate multiple user activity.
· Fault logging and tracking Faults discovered during testing must be recorded and processed methodically. Software tools can assist with the capture of fault details, assignment of a priority to each, allocation of responsibility for fixing faults, tracking of progress on fixing faults, etc
· Static code analysis A number of tools exist which will analyse program code and report on a number of characteristics, e.g. program structure, conformance with standards, use of comments, etc. These can be used as a pro-active measure to ensure the quality of maintainability of code.

Read More about Software Testing Tutorials

Software Testing Questions and Answers

Testing Question & Answers

1
What is testing?
Testing is an activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.

2
What is Software Quality Assurance?Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

3
What are 5 common problems in the software development process?o poor requirements - if requirements are unclear, incomplete, too general, and not testable, there will be problems. o unrealistic schedule - if too much work is crammed in too little time, problems are inevitable. o inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash. o featurisms - requests to pile on new features after development is underway; extremely common. o miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed.

4
What is a test case?
A set of test inputs, execution conditions, and expected results developed for a particular objective.

5
What is a test plan?
A Test Plan depicts the plan for conducting tests. This usually includes: Test Strategy, Schedules and Resource allocation.

6
Give definitions for Defect, Defect Age and Defect Density.
Defect : Any deviation in the working of the application that is not mentioned in any documents in SDLC can be termed as a defect. Defect Age : The time duration between the defect state from New to Closed Defect Density : No of known defect per KLOC (Kilo lines of Code ) or FP (functional point)

7
What is a bug?
A fault in a program which causes the program to perform in an unintended or unanticipated manner

8
What is the difference between verification & validation?
Validation
Verification
Am I building the right product
Am I building the product right
Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.
The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and performs the selected functions in the correct manner.
Am I accessing the right data (in terms of the data required to satisfy the requirement)
Am I accessing the data right (in the right place; in the right way).
High level activity
Low-level activity.
Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards
Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment
Determination of correctness of the final software product by a development project with respect to the user needs and requirements
Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.

9
What is the difference between QA & QC?
Quality Assurance
Quality Control
A planned and systematic set of activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified requirements.
The process by which product quality is compared with applicable standards; and the action taken when non-conformance is detected.
An activity that establishes and evaluates the processes to produce the products.
An activity, which verifies if the product meets pre-defined standards.
Helps establish processes.
Implements the process.
Sets up measurements programs to evaluate processes.
Verifies if specific attribute(s) are in a specific product or service
Identifies weaknesses in processes and improves them.
Identifies defects for the primary purpose of correcting defects.
QA is the responsibility of the entire team.
QC is the responsibility of the tester.
Prevents the introduction of issues or defects
Detects, reports and corrects defects.
QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.
QC evaluates if the application is working for the primary purpose of determining if there is a flaw / defect in the functionalities.
QA improves the process that is applied to multiple products that will ever be produced by a process.
QC improves the development of a specific product or service.
QA personnel should not perform quality control unless doing it to validate quality control is working.
QC personnel may perform quality assurance tasks if and when required.

10
What is software quality?Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.However, quality is obviously a subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. A wide-angle view of the 'customers' of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization's management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of 'customer' will have their own slant on 'quality' - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.

11
What's an inspection? An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything. Attendees should prepare for this type of meeting by reading thru the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effective methods of ensuring quality. Employees who are most skilled at inspections are like the 'eldest brother' in the parable in 'Why is it often hard for management to get serious about quality assurance?' Their skill may have low visibility but they are extremely valuable to any software development organization, since bug prevention is far more cost-effective than bug detection.

12
Explain Condition Coverage and Condition/Decision Coverage.
Condition coverage reports the true or false outcome of each Boolean sub-expression, separated by logical-and logical-or if they occur. Condition coverage measures the sub-expressions independently of each other. Condition/Decision Coverage is a hybrid measure composed by the union of condition coverage and decision coverage.

13
Explain Data Flow Coverage
This variation of path coverage considers only the sub-paths from variable assignments to subsequent references of the variables. The advantage of this measure is the paths reported have direct relevance to the way the program handles data. One disadvantage is that this measure does not include decision coverage. Another disadvantage is complexity. Researchers have proposed numerous variations, all of which increase the complexity of this measure. For example, variations distinguish between the use of a variable in a computation versus a use in a decision, and between local and global variables. As with data flow analysis for code optimization, pointers also present problems.

14
Explain Decision Coverage.
This measure reports whether Boolean expressions tested in control structures (such as the if-statement and while-statement) evaluated to both true and false.

15
Explain Function Coverage.
This measure reports whether you invoked each function or procedure. It is useful during preliminary testing to assure at least some coverage in all areas of the software. Broad, shallow testing finds gross deficiencies in a test suite quickly.

16
Explain Linear Code Sequence and Jump (LCSAJ) Coverage.
This variation of path coverage considers only sub-paths that can easily be represented in the program source code, without requiring a flow graph. An LCSAJ is a sequence of source code lines executed in sequence. This "linear" sequence can contain decisions as long as the control flow actually continues from one line to the next at run-time. Sub-paths are constructed by concatenating LCSAJs. Researchers refer to the coverage ratio of paths of length n LCSAJs as the test effectiveness ratio (TER) n+2. The advantage of this measure is that it is more thorough than decision coverage yet avoids the exponential difficulty of path coverage. The disadvantage is that it does not avoid infeasible paths

17
Explain Loop Coverage
This measure reports whether you executed each loop body zero times, exactly once, and more than once (consecutively). For do-while loops, loop coverage reports whether you executed the body exactly once, and more than once.

18
Explain Modified Condition/Decision Coverage.
Also known as MC/DC and MCDC. This measure requires enough test cases to verify every condition can affect the result of its encompassing decision.

19
Explain Multiple Condition Coverage.
Multiple condition coverage reports whether every possible combination of Boolean sub-expressions occurs.

20
Explain Object Code Coverage.
This measure reports whether each machine language conditional branch instruction both took the branch and fell through. This measure gives results that depend on the compiler rather than on the program structure since compiler code generation and optimization techniques can create object code that bears little similarity to the original source code structure. Since branches disrupt the instruction pipeline, compilers sometimes avoid generating a branch and instead generate an equivalent sequence of non-branching instructions. Compilers often expand the body of a function inline to save the cost of a function call. If such functions contain branches, the number of machine language branches increases dramatically relative to the original source code.

Read More about Software Testing Tutorials