Software Testing in 45 Days

Non Functional Specification based Test Design

2011-07-15T13:45:00.000+05:30

To prepare test scenarios and test cases for functional testing, testers can follow any one of three methods such as functional based or use case based or screen based test design.

But to prepare test scenarios and cases for non functional testing, testers following only one method such as Non Functional Specification based test design.

Examples:

Non Functional Specification 1 (Usability Testing):

Library management software consists of six screens such as employee registrations, employee login, reader registration, books feeding, book issue, books return. These 6 screens are user friendly.

Question: Prepare a test scenario for Usability Testing.

TS 1: Verify spelling of each label in throughout screens of software.

TS 2: Verify Initial letter uppercase of each label in throughout screens of software.

TS 3: Verify meaning of each label in throughout screens of software.

TS 4: Verify uniform line spacing in between label control.

TS 5: Verify line space in between controls as uniform.

TS 6: Verify label font size as similar or not.

TS 7: Verify label font style as similar or not.

TS 8: Verify tool tips meaning in throughout screens of software.

TS 9: Verify icon symbols with respect to provided functionality.

TS 10: Verify alignment of controls in software.

TS 11: Verify arrangement of controls with respect to functionality.

TS 12: Verify grouping of functionality related object in throughout screens of software.

TS 13: Verify keyboard access on each screen of software.

TS 14: Verify meaning of HELP documents.

TS 15: Verify meaning of error messages.

TS 16: Verify shortcuts throughout screens of software.

TS 17: Verify format for date control on screen.

TS 18: Verify color contrast in between controls.

TS 19: Verify scroll bars availability.

TS 20: Verify status bar or progress bar availability while running process in software.

Note: To conduct usability testing, Organizations are maintaining a common check list. Dues to these reason testers are not preparing test scenarios for usability testing in every project.

_____________________________________________________________________________

Non Functional Specification 2(Compatibility Testing):

Library management software consists of six screens such as employee registrations, employee login, reader registration, books feeding, book issue, books return. From customer requirement these 6 functionalities will run on Windows 7, Vista, XP, 2003 server. This is called Compatibility Testing.

Question: Prepare a test scenario for Compatibility Testing.

TS 1: Verify Employee Registration functionality in below platforms.

TS 2: Verify Employee Login functionality in below platforms.

TS 3: Verify Reader registration functionality in below platforms.

TS 4: Verify books feeding functionality in below platforms.

TS 5: Verify book issue functionality in below platforms.

TS 6: Verify book return functionality in below platforms.

Platform Component	Version	Yes/No
OS	Windows 7	Yes
	Windows Vista	Yes
	Windows XP	Yes
	Windows 2003	Yes
	Others	Yes/No

___________________________________________________________________________

Non Functional Specification 3(Configuration Testing):

Library management software developed for a library to use in LAN. In this management software, library employees can use printer connection to make bill for fine amount.

Question: Prepare a test scenario for Configuration Testing.

TS 1: Verify Employee Registration functionality in below configuration.

TS 2: Verify Employee Login functionality in below configuration.

TS 3: Verify Reader registration functionality in below configuration.

TS 4: Verify books feeding functionality in below configuration.

TS 5: Verify book issue functionality in below configuration.

Hardware Component	Type/Vendor	Yes/No
LAN	Token Bus	Yes
	Token Ring	Yes
	Star/Hub Topology	Yes

TS 6: Verify book return (with bill printing) functionality in below configuration.

Hardware Component	Type/Vendor	Yes/No
LAN	Token Bus	Yes
	Token Ring	Yes
	Star/Hub Topology	Yes
Printers	Dot Matrix	Yes
	Ink Jet	Yes
	Laser	Yes

___________________________________________________________________________

Non Functional Specification 4(Performance Testing):

Library management software is developed for a library which has 10 employees. These 10 employees are using this management software for employee registrations, employee login, reader registration, books feeding, book issue, and books return operations.

Question: Prepare a test scenario for Performance Testing.

TS 1: Verify Employee Registration under Load testing.

TS 2: Verify Employee Registration under Stress testing.

TS 3: Verify Employee Registration under Spike testing.

TS 4: Verify Employee Registration under Endurance testing.

TS 5: Verify Employee Login under Load testing.

TS 6: Verify Employee Login under Stress testing.

TS 7: Verify Employee Login under Spike testing.

TS 8: Verify Employee Login under Endurance testing.

TS 9: Verify Reader Registration under Load testing.

TS 10: Verify Reader Registration under Stress testing.

TS 11: Verify Reader Registration under Spike testing.

TS 12: Verify Reader Registration under Endurance testing.

TS 13: Verify Book Feeding under Load testing.

TS 14: Verify Book Feeding under Stress testing.

TS 14: Verify Book Feeding under Spike testing.

TS 16: Verify Book Feeding under Endurance testing.

TS 17: Verify Book Issue under Load testing.

TS 18: Verify Book Issue under Stress testing.

TS 19: Verify Book Issue under Spike testing.

TS 20: Verify Book Issue under Endurance testing.

TS 21: Verify Book Return under Load testing.

TS 22: Verify Book Return under Stress testing.

TS 23: Verify Book Return under Spike testing.

TS 24: Verify Book Return under Endurance testing.

____________________________________________________________________________

Non Functional Specification 5:

Library management software is allowed readers to pay fine amount via Visa, Master, and American Express.

Question: Prepare a test scenario for above inter system requirements.

TS 1 (End to End): Verify fine payment modes while book return:

Payment Mode by connecting to Bank Server.	Yes/No
Vise Server	Yes
Master Server	Yes
American Express Server	Yes
Other Servers	Yes/No

_____________________________________________________________________________

Non Functional Specification 6(Data Volume testing):

From SLA (Service Level Agreement): Library is expecting 1lakh reader’s information, 10lakhs books information and 1crore issue on return transactions to be managed by library management software.

Question: Prepare a test scenario or Data Limits for above Data Volume testing.

TS 1: Verify Reader Registration operation to register 1Lakh readers.

TS 2: Verify Book Feeding Operation to feed 10Lakhs books information.

TS 3: Verify Book Issues & return to store 1Crore transactions.

_____________________________________________________________________________

Non Functional Specification 7(Installation testing):

Library management software is installed into LAN of library. From SLA: the software is easy to install.

Question: Prepare a test scenario on check list for installation testing.

TS 1: Verify setup program execution to start installation.

TS 2: verify appeared screens usability while installation.

TS 3: verify occupied disk space after installation.

Note: Above 3 test scenarios are common to any software installation testing.

____________________________________________________________________________

Note 1: All softwares are not supporting multiple people language to take input and sent output. If software developed in JAVA unique code then testers are responsible for multilanguity testing.

Note 2: Parallel testing is applicable on only product softwares. For application softwares, testers are depending on SRS and SLA to estimate strength and weakness.

Preparing Test Scenarios by using Screen based Test Design

2011-07-10T22:24:00.000+05:30

Screen based Test Designs:

Sometimes testers are writing test scenarios by using Screen based Test Designs instead of Functional requirement specifications (FRS).

Screen 1:

Field Validations:

Username is alphanumeric from 4 to 10 chars.
Password is alphanumeric from 4 to 8 chars.

Question: Prepare a test scenario for the above Screen based Test Designs.

TS 1: Verify User Name Field:

Boundary Value Analysis (BVA Size)
Min	4 Chars		Pass
Max	10 Chars		Pass
Min-1	3 Chars		Fail
Min+1	5 Chars		Pass
Max-1	9 Chars		Pass
Max+1	11 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[A-Z 0-9a-z]+		Special Chars, Blank Field.

TS 2: Verify Password Field:

Boundary Value Analysis (BVA Size)
Min	4 Chars		Pass
Max	8 Chars		Pass
Min-1	3 Chars		Fail
Max-1	7 Chars		Pass
Min+1	5 Chars		Pass
Max+1	9 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[A-Z 0-9a-z]+		Special Chars, Blank Field.

TS 3: Verify Login Operations by clicking OK button:

Decision Table
Fields	Expected Outcome
All are valid	Successfully Login
Any one Invalid	Error Massage
Any one Blank field	Error Massage

TS 4: Verify CANCEL button operations to close window:

Decision Table
Fields	Expected Outcome
All are valid	Window should close
Any one Invalid	Window should close
Any one Blank field	Window should close

TS 5: Verify the HELP button:

Decision Table
Fields	Expected Outcome
All are valid	Open Help Window
Any one Invalid	Open Help Window
Any one Blank field	Open Help Window

TS 6: Verify Minimize Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Minimize
All are Blank field	Window should Minimize
Any one Blank field	Window should Minimize

TS 7: Verify Maximize Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Maximize
All are Blank field	Window should Maximize
Any one Blank field	Window should Maximize

TS 8: Verify Close Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Close
All are Blank field	Window should Close
Any one Blank field	Window should Close

___________________________________________________________________________

Preparing Test Scenarios by using Use Cases Test Design

2011-07-10T19:57:00.000+05:30

Use Cases base Test Design:

Some times testers are also preparing test scenarios based on Use Cases Test Design. Use Cases are more elaborated than Function specification. System Analyst category people are preparing these Use Cases. Every Use Case is in IEEE 830(MS-Excel) format.

Examples:

Use Case 1:

Use CaseID: UC_Login
Use Case description: Library employees can do login to connect to software.
Actors: UserID is an alphanumeric in lower case from 4 to 16 chars long. Password is an alphabet in lowercase from 4 to 8 chars long.
Precondition: Library employees are registered.
Events List:

Fields	Expected Outcome
Enter UserID,Password and then click OK button	For valid User, next window. For invalid user, error message appears
Clicks CANCEL at any time.	Window closed.

Alternative Events: None.
Post Conditions: User can click LOGOUT to close session.
Active Flow Diagram: Gives Flow represents Diagram.
Protype: Gives an Imagination (how it looks) screen shot.
Related Use Cases: UC_Employee_registration, UC_Logout.

Question: Prepare a test scenario for the above Use Case.

TS 1: Verify UserID field:

Boundary Value Analysis (BVA Range)
Min	4 Chars		Pass
Max	16 Chars		Pass
Min-1	3 Chars		Pass
Min+1	5 Chars		Fail
Max-1	15 Chars		Pass
Max+1	17 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[a-z0-9]+		[A-Z]+, Blank field, special characters.

TS 2: Verify Password field:

Boundary Value Analysis (BVA Size)
Min	4 Chars		Pass
Max	8 Chars		Pass
Min-1	3 Chars		Fail
Max-1	7 Chars		Pass
Min+1	5 Chars		Pass
Max+1	9 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[a-z]+		[A-Z0-9]+, Special Chars, Numeric Field, Blank Field.

TS 3: Verify the LOGIN button operations to login:

Decision Table
Fields	Expected Outcome
All are valid	Successfully Login
Any one Invalid	Error Massage
Any one Blank field	Error Massage

TS 4: Verify CANCEL button operations to close window:

Decision Table
Fields	Expected Outcome
All are valid	Window should close
Any one Invalid	Window should close
Any one Blank field	Window should close

____________________________________________________________________________

Use Case 2:

Use CaseID: UC_Login
Use Case description: A valid library employee can issue an available book to reader.
Actors: ReaderID is in a format MM/YY/XXXX. BookID is in a format BOOK_XXX.
Precondition: Books and readers information was already stored.
Events List:

Fields	Expected Outcome
Enter ReaderID and click GO button	For valid reader, BookID should focus. For invalid, Error message
Enter BookID and click GO button	For valid & available,”book issue” message appear. For valid & unavailable,” Book already issued” message. For invalid & available “Invalid BookID” message.

Alternative Events: None.
Post Conditions: Library employee can click LOGOUT after book issued to the reader.
Active Flow Diagram: Given Flow represents Diagram.
Protype: Given an Imagination (how it looks) screen shot.

Related Use Cases: UC_reader_registration, UC_feed.

Question: Prepare a test scenario for the above Use Case.

TS 1: Verify the ReaderID field:

Boundary Value Analysis (BVA Size)
Min	10	Pass
Max	10	Pass
Min+1	11	Pass
Min-1	9	Fail
Max+1	11	Fail
Max-1	9	Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
(([0][1-9])\|([1][0-2]))[_][0-9]{2}[_][0-9]{4} In MM/YY/XXXX format.		[a-zA-Z]+, Special characters except “_”, Blank field

TS 2: Verify ReaderID validation by clicking “GO” button.

Decision Table
ReaderID	Expected Outcome
Valid value	Focus to BookID
Invalid value	Error Massage
Blank field	Error Massage

TS 3: Verify BookID field:

Boundary Value Analysis (BVA Size)
Min	8	Pass
Max	8	Pass
Min+1	9	Pass
Min-1	7	Fail
Max+1	9	Fail
Max-1	7	Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
[B][O]{2}[K][_][0-9]{3} (In a BOOK_XXX format)		[a-zA-Z]+ except B,O,K, Special characters except “_”, Blank field

TS 4: Verify BookID availability by clicking GO button.

Decision Table
ReaderID	BookID	Expected Outcome
Valid	valid & available	“Book issue” message
Valid	valid & unavailable	” Book already issued” message
Valid	invalid & available	“Invalid BookID”
Valid	Blank field	Error message

TS 5: Verify Minimize Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Minimize
All are Blank field	Window should Minimize
Any one Blank field	Window should Minimize

TS 6: Verify Maximize Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Maximize
All are Blank field	Window should Maximize
Any one Blank field	Window should Maximize

TS 7: Verify Close Icon:

Decision Table
Fields	Expected Outcome
All are filled	Window should Close
All are Blank field	Window should Close
Any one Blank field	Window should Close

___________________________________________________________________________

Preparing Test Scenarios Based on Functional Specification Test Design

2011-07-10T19:22:00.001+05:30

To conduct functional testing, Testers are preparing test scenarios with respect to functional specification requirement (FRS).Testers are writing Test Scenarios in IEEE 829 Format (Ms-Word).

Black Box Testing Techniques:

While preparing test scenarios & test cases for testing, Test engineers are following BLACK BOX TESTING Techniques are also called CLOSED BOX TESTING Techniques. They are:

BVA (Boundary Value Analysis )
ECV (Equivalence Class Partitions)
Decision Table (DT)
Orthogonal Arrays.
State Transitional Flows.
Error Guessing.

In above list of Techniques,

BVA is defining boundaries of size/range of Input and output Values.

DT can specify valid & invalid mapping in between Input and output in functionality of software.

Orthogonal Arrays technique can remove decision redundancy (no need to test with similar inputs).

State Transition Flow specifies changes in between functionality to functionality (Login – money transfer – logout).

Error guessing techniques were used by senior testers to write decision depends on their past experience.

Examples:

Functional Specification 1: In a Library Management, library employees are login by user ID & password. User ID will take Alpha numeric in Lower cases. Password will take Alphabets in Lower case from 4 to 8 cases. To close login window at any library employee can use CANCEL button.

Questions: Prepare test scenarios for login modules

TS 1: Verify UserID Field:

Boundary Value Analysis (BVA Size)
Min	4 Chars		Pass
Max	16 Chars		Pass
Min-1	3 Chars		Fail
Min+1	5 Chars		Pass
Max-1	15 Chars		Pass
Max+1	17 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Alpha numeric in lowercase		Alphabets in Uppercase, Special Chars, Blank Field.

TS 2: Verify Password Field:

Boundary Value Analysis (BVA Size)
Min	4 Chars		Pass
Max	8 Chars		Pass
Min-1	3 Chars		Fail
Max-1	7 Chars		Pass
Min+1	5 Chars		Pass
Max+1	9 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Alphabets in lowercase		Alphabets in Uppercase, Special Chars, Numeric Field, Blank Field.

TS 3: Verify Login Operations:

Decision Table
User ID	Password	Expected Outcome
Valid	Valid	Next Window
Invalid	Valid	Error Massage
Valid	Invalid	Error Massage
Invalid	Invalid	Error Massage
Blank field	Valid	Error Massage
Value	Blank field	Error Massage
Blank field	Blank field	Error Massage

TS 4: Verify Login Window cancellation by clicking CANCEL button:

Decision Table
User ID	Password	Expected Outcome
Filled	Filled	Window Closed
Blank field	Filled	Window Closed
Filled	Blank field	Window Closed
Blank field	Blank field	Window Closed

______________________________________________________________________________

Functional Specification 2: In school admin software, school employees are filling details of class name & strength of students in that course. Here CourseID is a 3 digits number, Course Name is a 3 Char upper case alphabets. Classroom strength in between 200 to 300. After filling school employer can click save button.

Questions: Prepare test scenarios for school admin software module.

TS 1: Verify CourseID Field:

Boundary Value Analysis (BVA Size)
Min	3 digits number		Pass
Max	3 digits number		Pass
Min+1	4 digits number		Fail
Min-1	2 digits number		Fail
Max+1	4 digits number		Fail
Max-1	2 digits number		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric values		Alphabets(L/U), Special Chars, Blank field

TS 2: Verify Course Name Field:

Boundary Value Analysis (BVA Size)
Min	3 Chars		Pass
Max	3 Chars		Pass
Min-1	2 Chars		Fail
Max+1	4 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Alphabets in upper cases		Alphabets in lower cases, special characters, blank fields, numeric values

TS 3: Verifying Strength Field:

Boundary Value Analysis (BVA Range)
Min	200 num		Pass
Max	300 num		Pass
Min-1	199 num		Fail
Min+1	201 num		Pass
Max-1	299 num		Pass
Max+1	301 num		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric Values		Alphabets(U/L), special characters, blank fields

TS 4: Verify class room information feeding by clicking SAVE button:

Decision Table
Fields	Expected Outcome
All fields are valid	Next Window
Any one field invalid	Error massage
Any one blank field	Error massage

______________________________________________________________________________

Function Specification 3: In an Insurance Application, users are applying for different types of policies. If a user selects Type - A insurance, then our software focuses to age field. Age field will take greater than 16 years & less than 50 years.

Questions: Prepare test scenarios for users are applying for different types of policies.

TS 1: Verify the selection fields Type - A Insurance policy:

Decision Table
Fields	Expected Outcome
If Insurance field Type – A	Age field focus
Other than Type – A	Age field not focus

TS 2: Verify the age field values:

Boundary Value Analysis (BVA Range)
Min	17 years		Pass
Max	49 years		Pass
Min-1	16 years		Fail
Min+1	18 years		Pass
Max -1	48 years		Pass
Max+1	50 years		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric Values		Alphabets, special characters, blank fields.

_____________________________________________________________________________

Function Specification 4: In Online Banking software, users are connecting to bank servers by login. This login module can take below inputs from users:

Account Numbers prefix – 3 digits number but does not starts with 0 & 1.
Accounts No Suffix – Six digits number.
Password – 5-10 Character Alphabets in lower case.
Area code – 3 digits + Optional.
Purpose – Money transfer, cheque deposit, Mini statement, Bill pay.

After filling above field, user can click ok button to connect to bank server.

Questions: Prepare test scenarios for online banking software.

TS 1: Verify Account Number prefix field:

Boundary Value Analysis (BVA Size)
Min	3 digits		Pass
Max	3 digits		Pass
Min-1	2 digits		Fail
Max+1	4 digits		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric Values but does not starts with 0 & 1		Alphabets, special characters, Numeric Values starts with 0 & 1, blank field.

TS 2: Verify Account Number suffix field:

Boundary Value Analysis (BVA Size)
Min	6 Chars		Pass
Max	6 Chars		Pass
Min-1	5 Chars		Fail
Max+1	7 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric Values		Alphabets, special characters, blank fields.

TS 3: Verify Password field:

Boundary Value Analysis (BVA Range)
Min	5 Chars		Pass
Max	10 Chars		Pass
Min-1	4 Chars		Fail
Min+1	6 Chars		Pass
Max-1	9 Chars		Pass
Max+1	11 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Alphabets in lower cases		Alphabets in Uppercase, Numeric values, Blank field, special characters.

TS 4: Verifying Area code field:

Boundary Value Analysis (BVA Size)
Min	3 Chars		Pass
Max	3 Chars		Pass
Min-1	2 Chars		Fail
Max+1	4 Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
Numeric Values, Blank field		Alphabets, special characters

TS 5: Verify purpose selection like cheque deposit, or money transfer bills pay, mini statement (It is just a drop down list):

TS 6: Verify login operations by clicking submit button to connect to bank server:

Decision Table
Mandatory field	Optional fields (Area code)	Expected Outcome
All are valid	Blank field	Connect to bank servers
All are valid	Invalid	Error massage
All are valid	Valid	Connect to bank servers
Any one Invalid	Valid/Blank field	Error massage
Any one Blank field	Valid/Blank field	Error massage

_____________________________________________________________________________

Using Regular Expressions

Function specification 5: In a library management software library employees are feeding books information. While feeding, employee can fill below details.

Book Title one or more words.
Author name one or more words.
Publishers – alphabets in upper chars as one word.
No of copies – up to 10.
After filling above feeds employee can click FEED button.

Questions: Prepare test scenarios for book feeding operations.

TS 1: Verify Book Title Fields (Default size is 1-256, if size is not mentioned for alphabets):

Boundary Value Analysis (BVA Size)
Min	1 Chars		Pass
Max	256 Chars		Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
Alphabets as one or more word or [\w]+		[\d]+, Special characters Except Blank Space, Blank field

TS 2: Verify Author field (BVA & ECP same as TS 1):

TS 3: Verify Publisher field:

Boundary Value Analysis (BVA Size)
Min	1 Chars		Pass
Max	256 Chars		Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
[A-Z]+		[a-z0-9]+, Special characters, Blank field

TS 4: Verify No. of Copies Filed:

Boundary Value Analysis (BVA Size)
Min	1		Pass
Max	10		Pass
Min+1	2		Pass
Min-1	0		Fail
Max+1	11		Fail
Max-1	9		Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
[\d]+		[a-zA-Z]+, Special characters, Blank field

TS 5: Verify Book operation by clicking FEED button:

Decision Table
Fields	Expected Outcome
All are valid	Book Info Feed Done
Any one Invalid	Error Massage
Any one Blank field	Error Massage

_____________________________________________________________________________

Function specification 6: In one library management software, library employees are storing reader’s info

Reader name one or more words.
Age – 15 to 50 years.
Street – alpha numeric with special character “/”.
City – alphabets in upper case.

After filling above fields, employees can get reader ID as output. This reader ID is in a format MM/YY/XXXX.

Questions: Prepare test scenarios for storing reader’s info.

TS 1: Verify the Reader name field:

Boundary Value Analysis (BVA Size)
Min		1 Chars	Pass
Max		256 Chars	Pass
Min-1		0 Chars	Fail
Min+1		2 Chars	Pass
Max-1		255 Chars	Pass
Max+1		257 Chars	Fail
Equivalence Class Partitions (ECP)
Valid	Invalid
[\w]+	[0-9]+, Special character except blank space, Blank field.

TS 2: Verify Age field:

Boundary Value Analysis (BVA Range)
Min	15		Pass
Max	50		Pass
Min-1	14		Fail
Min+1	16		Pass
Max-1	49		Pass
Max+1	51		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[0-9]+		[a-zA-Z]+, Blank field, special characters.

TS 3: Verify street field:

Boundary Value Analysis (BVA Size)
Min	1 Chars		Pass
Max	256 Chars		Pass
Min-1	0 Chars		Fail
Min+1	2 Chars		Pass
Max -1	255Chars		Pass
Max+1	257Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[A-Z0-9a-z]+		Blank field, special characters excluding “/”.

TS 4: Verify City Name field:

Boundary Value Analysis (BVA Size)
Min	1 Chars		Pass
Max	256 Chars		Pass
Min-1	0 Chars		Fail
Min+1	2 Chars		Pass
Max -1	255Chars		Pass
Max+1	257Chars		Fail
Equivalence Class Partitions (ECP)
Valid		Invalid
[A-Z]+		[0-9a-z]+, Blank field, special characters, blank space

TS 5: Verify ReaderID registrations operation:

Decision Table
Fields	Expected Outcome
All are valid	ReaderID Generates
Any one Invalid	Error Massage
Any one Blank field	Error Massage

TS 6: Verify the Output ReaderID format field:

Boundary Value Analysis (BVA Size)
Min	10	Pass
Max	10	Pass
Min+1	11	Pass
Min-1	9	Fail
Max+1	11	Fail
Max-1	9	Pass
Equivalence Class Partitions (ECP)
Valid		Invalid
(([0][1-9])\|([1][0-2]))[_][0-9]{2}[_][0-9]{4} In MM/YY/XXXX format.		[a-zA-Z]+, Special characters except “_”, Blank field

_____________________________________________________________________________

Regular Expressions

2011-07-10T19:16:00.000+05:30

Regular Expressions are mathematical patterns where Test Engineers are using these in test scenarios & test cases. To represent various types of data, these regular expressions are using with some special symbols.

[ ] - One position

[0-9] – one digit

[a-z] – One char in lower case

[12] – ‘1’ or ‘2’

[xpz] – ‘x’ or ‘p’ or ‘z’

[1][2] – ‘12’ number

[a-z][A-Z] – Two chars, here first is upper case & next is lower

[A-Za-z0-9] – One Alphanumeric Char

[A-Z0-9a-z] - One Alphanumeric

[A-Z][a-z]{3} – One upper char & 3 lower chars

[0-9]{4,10} – Min 4 & Max 10 digits

[0-9]{ ,10} – No to 10 digits

[0-9]{4, } – 4 to infinite digits

[0-9]{ , } – No to infinite digits

[0-9]* - No to infinite digits

[0-9]+ - 1 to infinite digits

[0-9]? – No or one digit

[0-9] or [\d] – one digit

[\d]* - No to infinite digits

[\w] – Word

[\w]+ - one or more words

[.]* Or .* - Any character, any no. of types.

Bug Life Cycle(BLC) and Defect Reports

2011-07-09T02:09:00.001+05:30

Bug Life Cycle(BLC)

What is Bug/Defect?
                                 “A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.”

Bug Life Cycle(BLC):

§         New: When Tester files new bug.
§         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.
§         Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.
§         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.
§         Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by Tracking Team 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.
§         Need more information: If developer is not clear about the bug reproduce steps provided by Tracking Team to reproduce the bug, then he/she can mark it as “Need more information’. In this case Tester needs to add detailed reproducing steps and assign bug back to developer for fix.
§         Reopen: If Testing Team is not satisfy with the fix and if bug is still reproducible even after fix then Tester can mark it as ‘Reopen’ so that developer can take appropriate action.
§         Closed: If bug is verified by the Testing team and if the fix is ok and problem is solved then Testing Team can mark bug as ‘Closed’.
§         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.

Defects Reports (IEEE 829 MS-Word):

                       When a test case was failed, then test engineer prepares a defect report and will forwards to Defect Tracking Team. To prepare a defect report in IEEE format, testers can use MS-Word or MS-Excel.

§               Defect ID: Unique no. or Name for corresponding defect.
§               Defect Description: Summary of Defect
§               Module or Feature: Name of module in which this defect was detected.
§               Test Case ID or Name: Name of Test case which was failed.
§               Defect Status: New or Re-Open.
§               Defect Reproducible (Yes/No): Yes-If defect appears every time when run test more than one time. No- Defects appears rarely when run test more than one time.
§               Defect Severity: The seriousness of defect in terms of functionality.
High: Not able to continue testing until this defect is fixed.
Medium: Able to continue testing but mandatory to fix.
Low: Able to continue testing, but not mandatory to fix.
§               Defect Priority: The importance of defect with respect to Customer (High, Meduim, and Low).
§               Test Environment: Used software and Hardware while detecting this defect.
§               Detected By: Name of the Tester.
§               Detected On: Date and Time.
§               Reported To: DTT
§               Suggested Fix (Optional): Suggestions to fix defect if tester knows.

Defect Tracking Process:
                               After Preparing defect report corresponding tester can forward that defect to tracking team by using MS-Outlook. After receiving defect report from a tester, Defect Tracking Team is conducting a review meeting.

Levels of Test Execution

2011-07-09T00:10:00.000+05:30

Test Execution:

After completion of test design and their reviews, corresponding testing team is concentrating on test execution. In this stage, testing team is following below steps.

Formal Meeting.

Levels of Execution.

Formal Meeting: In general test execution process starts with formal meeting in between developers and testers. In this meeting, PM is also involving along with the Test Lead, Business Analyst and System Analyst.

The main agenda of this formal meeting is that creating negotiation channels in between developers & testers in terms of Build Version Control & Defect Tracking Process.

From Build Version Control process, developers are maintaining multiple versions of SUT (Software under Testing) in Softbase.Here each version number of SUT are distinguishable with the old versions of software.

SERVER

Configuration Repository

Development Base

Softbase

Test Base

From the above pic, Developers are storing SUT versions in Softbase, which is a folder in server computers. Testers are connecting to the server’s Softbase to download or launch corresponding SUT.This process is called as Build Version Control.

After completion of build version control system formation, Project Management is concentrating on Defect tracking Team coordinates with developers & testers during testing.

Levels of Test Execution:

Sanity Testing (Level 0):

Real Testing (Level 1):

Regression Testing (Level 2):

Final Regression Testing (Level 3):

Sanity Testing (Level 0):

After launching or downloading initial SUT (Software under Testing) from Softbase in server, Testing team is conducting Sanity Testing to estimate testability by executing basic functionality test cases on that initial SUT.

During this testing, testers are concentrating on below factors to define testability of SUT.

Understandable: SUT screen are understandable to the testers.
Observable: Functionalities at each screen are observable.
Controllable: Functionalities at screens are controllable by testers by doing tasks.
Consistency: Functionalities at screens are consistent.
Simplicity: Screens of SUT are not complex to operate.
Maintainable: No need to reinstall SUT to operate.
Automatable: Screens of SUT are automatable by available testing tools.

The above 8 factors combination is called as Test Ability. Due to this reason, Sanity Testing is also called as Octangle Testing or Testability Testing or Tester Acceptance Testing or Build Verification Testing.

If an initial SUT is not testable then testing team can reject that build & wait for stable build.

Real Testing (Level 1):

After receiving stable build, testing team is downloading into individual systems in test environment to conduct real testing on responsible modules. While testing, each tester can follow below process.

Collect all test cases related to responsible Modules (Group of related Test Batches).
Take one Test Batch (Group of related Test Cases).
Take one test case in that batch.
Take one step in that test case and then compare the step expected values with SUT actual values. If both are same then go to the next step. In that test case until all the steps was passed. If any step was failed, stop the execution and concentrate on Defect Reporting.
Go to next test case when previous test case was passed. Go to next batch when all test cases are passed in previous batch. Go to next module when all batches were passed in previous module. Go to test closure when all modules of SUT were passed.

Note: The mismatch in between expected value and actual value is called as DEFECT or ISSUE or BUG. If any expected value is not matching with SUT actual value then tester can stop test execution and send Defect Report to Defect Tracking Team.

Regression Testing (Level 2):

The selective retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not created problems with previous versions of the software. Also referred to as verification testing, regression testing is initiated after a programmer has attempted to fix a recognized problem or has added source code to a program that may have inadvertently introduced errors. It is a quality control measure to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity

After receiving release note from developers, corresponding testers can study that release note to understand modification performed by developers and follows below process.

Test Closure & Final Regression Testing(Level 3):

After completion of all test cases execution and major defects closing, Test Lead is conducting a review meeting to estimate completeness & correctness of testing. This review meeting is called as Test Closure.

Defects Density Calculation:

Modules	Percentage Defects
A	20%
B	20%
C	40%
D	20%

Need for Final Regression Testing

Analysis of Deferred Defects:

After completion of test closure review meeting, corresponding testing team is concentrating on Final Regression Testing or Post Mortem Testing or Pre-Acceptance testing.

Identify High Defect Density modules in SUT.
Plan for Final Regression Testing.
Run Test Cases on identified modules to defect Golden Defects (Mostly Medium or Low Severity)
Report to developers to fix as early as possible.
Receive modified and conducts Real Regression Testing to close those Golden Defects.

Acceptance testing:

After completion of Golden defects closing, Testing Team is confident on software Quality. At this time, Project Management is collecting feedback from customers or End Users on software. If feed back is not good then developers change software coding and testers can test those changes by conducting Regression Testing.

Sign Off or Role Off:

After completion of Acceptance Testing, Project Manager can select few testers for release. Test Lead will make Role off remaining testers.

After Tester role off corresponding test lead can prepare Requirement Traceability Matrix (RTM).This matrix defines mapping in between modules & defects via Test Cases. This matrix also called as Final Test Report.

Test Lead can submit above report to PM & Customer site people. And then Test Lead can Role off from current project by PM.

Note: Few Testers are involving in software release and CCB for maintenance.

Software Testing Life Cycle (STLC)

2011-07-07T12:12:00.006+05:30

Software Testing Life Cycle (STLC)

Software testing life cycle or STLC refers to a comprehensive group of testing related actions specifying details of every action along with the specification of the best time to perform such actions. There can not be a standardized testing process across various organizations, however every organization involved in software development business, defines & follows some sort of testing life cycle.

Software Testing Life Cycle consists of six (generic) phases:

Test Planning.
Test Analysis.
Test Design.
Construction and Verification.
Testing Cycles.
Final Testing and Implementation and
Post Implementation.

Test Planning:

This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.

Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.

Test Analysis:

Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.

Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.

Test Design:

After completion of Test planning & Test Analyzing, test lead will release the plan to a selected tester in current project. Those selected testers will receive a test plan & then studies System Requirement Specifications (SRS) to understand project requirements. After completion of SRS walkthrough & required training, testers are concentrating on Test Design.

There are two steps in test design such as:

High Level Test Design (HLTD)
Low Level Test Designs (LLTDs)

High Level Test Design (HLTD): In HLTD, Testers are preparing Test Scenarios. While writing Test Scenarios testers are concentrating on different ways, such as:

Functional Specification Requirements Based.
Use Case Based.
Screens Based.
Non-Functional Specification Requirements Based.

Low Level Test Designs (LLTDs): In LLTD, Testers are preparing Test Cases. Test scenarios a unique test condition but a test case specifies a step by step procedure to test that condition on SUT (Software under Testing).

Click Here for how to write Test Cases & Examples.

Construction and Verification:

In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Test executions are performed and errors (if any) are reported.

Click Here for more info on Stages of Test Executions.

Testing Cycles:

In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases –> Report Bugs –> revise test cases (if needed) –> add new test cases (if needed) –> bug fixing –> retesting (test cycle 2, test cycle 3….).

Final Testing and Implementation:

In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.

Post Implementation:

In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage.

Software Development Life Cycle (SDLC)

Vs

Software Test Life Cycle (STLC)

SDLC (Software Development Life cycle)	STLC (Software Test Life Cycle)
SDLC is Software Development Lifecycle; it is a systematic approach to develop software.	The process of testing software in a well planned and systematic way is known as software testing life cycle (STLC).
Requirements Gathering or Documents Gathering	Requirements Analysis is done is this phase, software requirements are reviewed by test team.
Design	Test Planning, Test analysis and Test design is done in this phase. Test team reviews design documents and prepares the test plan.
Coding or development	Test construction and verification is done in this phase, testers write test cases and finalizes test plan.
Testing	Test Execution and bug reporting, manual testing, automation testing is done, defects found are reported. Re-testing and Regression testing is also done in this phase.
Deployment	Final testing and implementation is done is this phase and final test report is prepared.
Maintenance	Maintenance testing is done in this phase.

Acceptance Testing,Deployment and Maintenance

2011-07-07T10:44:00.001+05:30

Acceptance Testing:

This is also called as Yellow Box Testing.After completion of software testing with respective to customer requirements & expectations,Project Management will conduct an Acceptance testing to collect feedback from real customer or model customer or end users.

There are two ways of Acceptance testing:

Alpha Testing: This testing is only for Project base software.Alpha testing is simulated or actual operational testing by potential 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, before the software goes to beta testing.

Beta Testing: This testing is only for Product base software.Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Software Release & Deployment:

After getting positive feedback from customers,Project management consultant releases a team formation.In this team,project manager can select few developers,few testers and few hardware members along with delivery head team.This release team also known as Onsite team or Delivery Team.

This team will go to customer site and starts launching software.While installation,release team observes below factors.

Complete Installation
Basic Functionality checks.
Input devices handling.
output devices handling.
Secondary storage devices
OS support
Coexistence with other factors.

This release testing is also called as Port Testing,Delivery Testing,Onsite Testing or Green Box Testing.

Maintenance & Support:

During utilization customer site people are facing some problems in software.Sometimes they are expecting enhancing.So to perform changes in software,project management can establish CCB(Change Control Board).In this board development and testing related members are involving.

Software Testing and Types

2011-07-06T23:56:00.000+05:30

Software Testing:

After completion of software integration & integration Testing, programmers can release software billed to Testing team.Testing team will install the software in test environment and then starts testing process.

Software Testing is classified into two levels:

Functional Testing
Non-Functional Testing

Functional Testing:

Functional testing is a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (Not like in white-box testing).It is a mandatory testing topic at software testing level.During this testing,testing team is validating a software with respect to customer requirement by by conducting below subtests.

Behavioral Testing/Control Flow testing.

Input Domain testing.

Error handling testing.

Output/manipulating Testing.

Database Testing.

Behavioral Testing: During this testing,testing team is observing flow of control or navigations on every screen of SUT(software under testing).This testing is also called as GUI Testing.
Input Domain Testing: After completion of control flow observation,testing team concentrating on type&size of each input in SUT.
Error Handling or Negative Testing: During this testing,testing team is operating SUT with invalid data to observe upcoming error message.
Manipulation Testing: Testing team is operating SUT with invalid data to observe upcoming output.
Database Testing: Testing is observing impact of front-end operations on back-end database of SUT.The correctness of new data insertion is called Data Validation and the correctness of changes of existing data is called as Data Integrity.
   During database testing,testing team can concentrating on Data Validation and
Data Integrity.This testing is also called as Back-end Testing.

Notes:
During functional testing, testing team is using Black Box Testing techniques or Closed Box Testing techniques.

In functional testing first four subtopics are related to front end testing & last subtopic is related to backend testing.

Non-Functional Testing:
   After completion of functional testing,testing team is concentrating on non-functional testing to validate software with respect to customer expectations.
   Due to this functional testing is called as Requirement Testing.Non functional testing is called as Expectation Testing.

Usability testing: During this test,testing team is validating software for user friendliness.Here user friendliness means:
Look & Feel.

Short Navigations.

Understandable Help.

Compatibility & Configuration testing: This
testing conducted on the software to evaluate the application's compatibility with the computing environment. Computing environment may contain some or all of the below mentioned elements:
§  Computing capacity of Hardware Platform (IBM 360, HP 9000, etc.)
§   Bandwidth handling capacity of networking hardware
§     Compatibility of peripherals (Printer, DVD drive, etc.)
§   Operating systems (MVS, UNIX, Windows, etc.)
§     Database (Oracle, Sybase, DB2, etc.)
§     Other System Software (Web server, networking/ messaging tool, etc.)
§   Browser compatibility (Firefox, Netscape, Internet Explorer, Safari, etc.)

Intersystem Testing: Also called as End to End testing,Web-services Testing, SOA (Service Oriented Architecture) Testing.Testing team is validating software while sharing resources of other software.

Data-Volume Testing: This testing is also called as Memory Testing or Capacity Testing.During this testing,testing team entering model data into software till the database validation overflows.Finally testing team decides a capacity of database in terms of customers entity.

Performance Testing:
Performance testing is testing that is performed, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage.

Load Testing:
Load testing is the simplest form of performance testing. A load test is usually conducted to understand the behavior of the application under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. If the database, application server, etc. are also monitored, then this simple test can itself point towards any bottlenecks in the application software.

Stress Testing:S
tress testing is normally used to understand the upper limits of capacity within the application landscape. This kind of test is done to determine the application's robustness in terms of extreme load and helps application administrators to determine if the application will perform sufficiently if the current load goes well above the expected maximum.

Endurance Testing (Soak Testing):
Endurance testing is usually done to determine if the application can sustain the continuous expected load. During endurance tests, memory utilization is monitored to detect potential leaks. Also important, but often overlooked is performance degradation. That is, to ensure that the throughput and/or response times after some long period of sustained activity are as good as or better than at the beginning of the test.

Spike Testing:
Spike testing, as the name suggests is done by spiking the number of users and understanding the behavior of the application; whether performance will suffer, the application will fail, or it will be able to handle dramatic changes in load.

Security Testing: It is a process to determine that an information system protects data and maintains functionality as intended. The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, availability, authorization and non-repudiation. Security testing as a term has a number of different meanings and can be completed in a number of different ways. As such a Security Taxonomy helps us to understand these different approaches and meanings by providing a base level to work from.
Multi Languity Testing: During this test,testing team is validating software with various languages as input when that software developed in Java Unicode There are two ways in multi languity testing such as Localization & Globalization.

Advance SDLC Models

2011-07-05T20:56:00.102+05:30

To release quality software to the customers or end users,Organizations are enhancing Traditional Models to Advance SDLC Models.They are follows,

Fish Model.
V-Model.
Agile Model.

Fish Model:

This is a process oriented company's development model. Even though it is a time consuming and expensive model One can be rest assured that both verification and validation is done paralley by separate teams in each phase of the model. So there are two reports generated by the end of each phase one for validation and one for verification. Because all the stages except the last delivery and maintenance phase is covered by the two parallel processes the structure of this model looks like a skeleton between two parallel lines hence the name fish model.

Advantages:
This strict process results in products of exceptional quality. So one of the important objective is achieved.

Disadvantages:
Time consuming and expensive.

V - Model:

V Stands for Verification & Validation.This V-model represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

User Requirement also called as BRS(Business Requirement Specification)

Agile Model:

It is one of the most important Advanced SDLC.This model is suitable for Application software.These model is based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.In this model, Customers or Stakeholders or End users are also involving in software develop & testing process.

Note:Currently small & medium scale organizations are following V-model for project & product development.



1).Documents Testing:
   In general,Software development process starts with the requirements gathering by business analyst.These gathered requirements are stored into a document called as BRS (Business Requirement Specifications)or CRS (Customer Requirement Specifications) or URS (User Requirement Specifications) and corresponding business analyst can review the BRS for completeness & correctness.
   System analyst will go through this BRS and prepares SRS (System or Software Requirement Specifications) and then-after corresponding system analyst can review the SRS for completeness & correctness.
   Designers will study that SRS and then prepare designs.There are two levels of design,such as HLD(High Level Design) & LLDs(Low Level Designs).

   A High Level design provides an overview of a solution, platform, system, product, service, or process.Such an overview is important in a multi-project development to make sure that each supporting component design will be compatible with its neighboring designs and with the big picture.The highest level solution design should briefly describe all platforms, systems, products, services and processes that it depends upon and include any important changes that need to be made to them.A high-level design document will usually include a high-level architecture diagram depicting the components, interfaces and networks that need to be further specified or developed.
   After completion of design documents preparations,corresponding designers can review the design documents for completeness & correctness.Here designers are also called as Technical Architects.

2.Unit Testing:
   After completion of documents preparations,corresponding programmers will start writing program or implementing codes.After completion of every program coding corresponding programmers will test the coding,called as Unit Testing or White Box Testing or Open Box Testing or Clear Box Testing Techniques.
Basic Path Coverage: Developer can use this techniques to confirm whether a program is running or not without any runtime errors by using Cyclomatic Complexity.
Control Structure Coverage: Programmer can use this technique to confirm that whether program is correctly running or not in terms of input & outputs.
Program Technique Coverage: Programmer can use this technique to confirm that whether program is running fastly or not.
Ex:1). 2).
a=10,b=20   a=10,b=20
c=a; a=a+b;
a=b; b=a-b;
b=c; a=a-b;
print a&b print a&b
1.Running fastly but taking extra memory(for c).
2.Running slowly but not taking any extra memory.
Mutation Coverage: After completion of a program testing,corresponding programmer can review that apply test by following below process.

Take a tested program.
Perform changes in that program.
Repeat previous test on the program.
If test passed,continue testing on same program to cover all areas.
If test failed,confirm program testing was completed.

3.Integration Testing:

Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before system testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.
Some different types of integration testing are big bang, top-down, and bottom-up.
a.Top-Down Approach:From this approach,programmers are interconnecting modules without involvement of under-constructive modules.Instead of this under constructive modules,programmers will use temperory code called as STUB.
b.Bottom-Up Approach:

From this approach,programmers are integrating sub modules without involvement of under-constructive main module.In the place of

under-constructive main module,
programmers will use temperory code called as DRIVER.

c.Hybrid Approach:This is a combination of

Top-Down &
Bottom-Up Approaches.
d.System Approach or Big bang Approach: From this approach developers can start integration & integration testing after completion of 100% coding.

Introduction to Software Development Life Cycle(SDLC)

2011-07-04T23:36:00.007+05:30

The System Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. Organizations are following these models to develop a new Applications or Products.

Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.

Types of SDLC models:

Waterfall/Linear
Prototype
Incremental
Spiral

Waterfall/Linear Model:

The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.

Prototype Model:

As a type of SDLC, the Prototype Model slowly builds from a simple concept of what a program is. Little by little the software is updated and tested in a real time environment. Users will be able to test and improve the software as they are created. This goes in a different pattern if you compare it to the regular SDLC pattern, and the feedback is only in the later stage. If there are any changes, it has to go back to the drawing board, wasting more time.

Incremental Model:

Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between. Basic Idea of this SDLC model is to release software by installments.

Spiral Model:

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral life-cycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.Basic Idea of this SDLC model is to release software by version development.

The above mentioned SDLC Models are also called as Ancient or Traditional SDLC Models.In this models,testing is a single stage and developers are involving in this process.Due to lack of openness in thinking and developers are not showing themselves as good testers,this single stage of testing is also not sufficient to release quality software to the customers or end users.

Introduction to Software Testing

2011-07-04T17:00:00.005+05:30

Software Testing:

Software testing is an investigation conducted to provide stakeholders or Customers or End Users with required information and specifications about the quality of the product or service under test.

Software: - A set of executable programs in a computer is called Software. Following are the two types of software’s

Application Software: If software developed for the specific customer requirements, then that software is called an Application base Software or Project.

Product Software: If software developed for overall requirements in market, then that software is called as Product base Software.

Software testing can be stated as the process of validating and verifying that a software program/application/product:

· meets the requirements that guided its design and development;

· works as expected; and

· Can be implemented with the same characteristics.