Difference between SDLC and STLC

# 1 Waterfall model comes uder SDLC while V model comes under
STLC,in waterfall model testing is done after completion of
project but in v model testing starts from first phase i.e
from requirement.In Waterfall model no correction or
changes is done and in v model after acceptance testing the
changes can be done.




# 2 water fall model goes in step by step means can't back to
the prevoius step...generally used in development of a
SDLC..
while V model belongs to the STLC that is a part of
SDLC .

difference between product based company and service/project based company

Product - impact on groups(Requirement gathered from market
study)
Project - impact on users(requirement from users)

Product based company:
The company which will have their own products .These products are used by the other companies by paying money to this companies.


Service Based Company:
These companies depend on the clients.Means that,they will develop a product or an application for the other companies. Ex:Sapient corporation,Accenture,TCS etc....

Difference between Sessions and Cookies

The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.
A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie. The trouble is that a user can block cookies or delete them at any time. If, for example, your website's shopping cart utilized cookies, and a person had their browser set to block them, then they could not shop at your website.
Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit

Session Cookies and Persistent Cookies

Also called a transient cookie, a cookie that is erased when the user closes the Web browser. The session cookie is stored in temporary memory and is not retained after the browser is closed. Session cookies do not collect information from the user’s computer. They typically will store information in the form of a session identification that does not personally identify the user.

Persistent Cookies

Also called a permanent cookie, or a stored cookie, a cookie that is stored on a user’s hard drive until it expires (persistent cookies are set with expiration dates) or until the user deletes the cookie. Persistent cookies are used to collect identifying information about the user, such as Web surfing behavior or user preferences for a specific Web site.

High Level Test Cases and Low Level Test Cases

Answer
# 1 Before I am going to explain you about high level
Testcases,I would like to share with you,what testcases we
will cover under high livel test cases and low level test
cases respectively.

Write all the testcases under high level TC,which can be
covered the main functionalities like
creation,edition,deletion,etc....as per prescribed in the
screen.
Wrtie all the testcases under low level TC,which can be
covered the screen,like input fields are displayed as per
the requirements,buttons are enabled or disabled,and
testcase for low priority functionalities.

Example a screen contains two edit boxes login and password
and a pust buttons OK and Reset and check box for the
label "Remember my password".Now let us write high level TC
and low level test cases.

HIGH LEVEL TC
--------------
1.Verify that User is able to login with valid login and
valid password.
2.Verify that User is not able to login with invalid login
and valid password.
etc...
..
..
3.Verify that Reset button clears the filled screen.
4.Verify that a pop up message is displayed for blank login.
etc...
etc..

LOW LEVEL TC
--------------
1.Verify that after launching the URL of the application
below fields are displayes in the screen.
1.Login Name 2.Password.3.OK BUTTON 4.RESET button etc..
5.check box,provided for the label "remember my pwd" is
unchecked.
2.Verify that OK button should be disabled before selecting
login and passwrod fields.
3.Verify that OK button should ne enabled after selecting
login and password.
4.Verify that User is able to check the check box,provided
for the label "remember my pwd".
etc..etc...

In this way,we can categorise all the testcases under HIGH
LEVEL and LOW LEVEL.

Traceability Matrix

Requirement Identifiers Reqs Tested REQ1


UC

1.1 REQ1

UC

1.2 REQ1

UC

1.3 REQ1

UC

2.1 REQ1

UC

2.2 REQ1

UC

2.3.1 REQ1

UC

2.3.2 REQ1

UC

2.3.3 REQ1

UC

2.4 REQ1

UC

3.1 REQ1

UC

3.2 REQ1

TECH

1.1 REQ1

TECH

1.2 REQ1

TECH

1.3

Test Cases 321 3 2 3 1 1 1 1 1 1 2 3 1 1 1

Tested Implicitly 77

1.1.1 1 x

1.1.2 2 x x

1.1.3 2 x x

1.1.4 1 x

1.1.5 2 x x

1.1.6 1 x

1.1.7 1 x

1.2.1 2 x x

1.2.2 2 x x

1.2.3 2 x x

1.3.1 1 x

1.3.2 1 x

1.3.3 1 x

1.3.4 1 x

1.3.5 1 x

etc…

5.6.2 1 x

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.

For instance a requirements traceability matrix is used to check to see if the current project requirements are being met, and to help in the creation of a Request for Proposal, various deliverable documents, and project plan tasks.[1]

Common usage is to take the identifier for each of the items of one document and place them in the left column. The identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column. This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if one must be made. Large values imply that the relationship is too complex and should be simplified.

To ease the creation of traceability matrices, it is advisable to add the relationships to the source documents for both backward traceability and forward traceability. In other words, when an item is changed in one baselined document, it's easy to see what needs to be changed in the other.

Forward Traceability and Backward Traceability.

E.g. If a requirement is changed then related test case need to be changed.

Forward traceability means mapping requirements with test cases whereas backward traceability means mapping testcases with requirements.

Mapping take place from from requirements to end products is Forward Traceability

Mapping take place from end product back to requirements is Backward Traceability



Using both the Forward and Backward Traceability is called Bidirectional Traceability. When the requirements are managed well to testcases and testcases to defects and vice versa. This helps nothing is missed in testing process....Bidirectional traceability needs to be implemented both forward and backward i.e. from requirements to end

Test Coverage Matrix

Test coverage matrix is a checklist which ensures that the functionality of the given screen(unit) is checked in all possible combinations (positive and negative) which have not been covered in test cases. Test coverage matrix is usually prepared for a screen having large number of controls (textboxes dropdowns buttons etc) usually test coverage matrix is prepared in a spread sheet having all the controls (textboxes dropdowns buttons etc) in the columns and then all possible entries in those fields in the rows with an ''yes'' or ''no'' in the rows against the controls listed in the columns. For example consider a ''login'' screen wherein we have ''username'' and ''password" textfields.




While preparing test coverage matrix the first column will be ''s.no'' and the second will be ''username" and ''password" will be the third field followed by ''ok'' and ''cancel'' button. Then in the first row for s.no 1 enter ''yes'' for both ''user name'' and ''password'' columns ''yes'' implying that a value is entered in that field. In the second row enter ''yes'' and ''no'' and in the third row ''no'' and 'yes'' and so on.



The complexity increases with the number of controls in the screen. Each of the row is considered as one condition and executed while testing. This is how we prepare test coverage matrix.







Sr. No. Username Password Ok Cancel

1 Yes Yes

2 Yes No

3 No No

4

5

6

7