SOFTWARE QUALITIES 1. Meet Customer Requirements (MCR)
2. Meet Customer expectation (MCE) 3. Cost Of Purchase (CP)
4. Time To Release (TR)
Meet Customer Requirements and Meet Customer Expectation is called Technical and Cost of Purchase and Time to Release is called non technical.
Definition:
1. Meet Customer Requirements (MCR) :- MCR in term of functionality
2. Meet Customer expectation (MCE):- In term of performance/usability/capability etc...
3. Cost Of Purchase (CP):- By customer
4. Time to release (TR):- By development organization.
SOFTWARE DEVELOPMENT PROCESSING REQIREMENT GATHERING
ANALAYSIS AND PLANING DESIGN
CODING TESTING
RELEASE & MAINTAINENCE SOFTWARE DEVELOPMENT PROCESSING MODELS
1. WATER FALL MODEL :when customer requirements are clear and constant
2. PROTO TYPE MODEL: When customer requirements are in ambiguity, the S/W organization develop sample model, which goes first to develop real S/W.
3. SPIRAL MODEL: Spiral model when the requirements are enhancing.
4. AGILE MODEL: Agile model when the customer requirements suddenly changing.
Note 1:-All S/W development models are derived from water fall model or linear sequential model.
Note 2: Above all S/W development models are maintaining single stage of testing and that too by same development people.
SOFTAWARE QUALITY ASSURANCE & SOFTAWARE QUALITY CONTROL SQA: The monitory and measuring the strength of development process is called SQA.
SQC: The validation of the S/W product with respect to the customer requirements and expectation called SQC.
BRS: BRS is defining the requirements of the customer to be developed as new software. This document is also known as CRS/URS.
SRS: Software requirements specification is defining functional requirements to be developed and system requirements to be used.
REVIEW: Determining the complete ness and correctness of documents by responsible people through Walkthrough, Inspection and peer-review is REVIEW.
Walkthrough: Checking from first line to last line Inspection search and faker
Peer-review: Comparing one Document with another document for each point word to word.
HLD: Designing the overall architecture of system from root module to leaf module.
Ex: Login ATM, Chat. HLD is also known as architectural design or external design.
LLD: LLD defines the internal architectural correspondence model (or) functionality. LLD is also known as internal design documents.
PROTO TYPE: A simple model of software is called proto type. It’s consists of interface (screen) with out functionality.
PROGRAMME: It indicates the set of executable statements. Statements in performing process and displaying outputs.
MODEL (OR) UNIT: - It’s a combination of programmer and S/W.
WHITE BOX OR GLASS BOX OR OPEN BOX TESTING TECHNIQUES: This is a program basis testing techniques. This technique also known as glass box or open box testing. Those responsible use this technique to verify the internal structure of corresponding program.
BLACK BOX TESTING: It’s a system level testing techniques. Those responsible use this technique to validate external functionality.
BUILD: An .exe executable form of system is called build. OR a finally integrated all modules set is call build.
V-MODEL: V-Stands for verification and validation. This model defines conceptual mapping in between develop man stage and testing stages.
V-model consists of multiple stages of developing process. Each embedding with multiple stages of testing process. From this model maximum organization are maintaining separate testing team only for system testing pass. B’coz this stage is a bottle neck stage of Software
development. After system testing the organization is planning to release S/W to customer site.
2 3 4
6 1
5
2A 3A 4A 7
1. Required gathering
2. Analysis 2A. Review
3. Design 3A. Review
4. Coding 4A. White box testing
5. System testing (or) black box testing 6. Main
7. Test S/W changes.
1, 2, 2A, 3, 3A Verification (or) SQA 4, 4A, 5, 6, 7 Verification (or) SQC
I. REVIEW IN ANALYSIS
Generally software development process starts with requirements gathering and analysis. In this phase business analysts develop BRS/SRS document. For complete ness and correctness of document the same business analyst conducts a review. In the review these are considered.
BRS & SRS
Are they right requirement?
Are they complete requirement?
Are they achievable requirement?
Are they reasonable requirement?
Are they testable requirement?
II. REVIEWS IN DESIGN
After completion of analysis & Review, Designers develop HLD & LLD’S. To verifying completeness and correctness those document, the same designer conducts review meeting. In this review, they concentrate on below factors.
HLD & LLD’S
Are they understandable design?
Are they designing right requirements?
Are they designing complete requirements?
Are they following able design?
Are they handling errors?
III .UNIT TESTING
1. Basis Path Testing: - Programmer is verifying whether a programmer is running or not. In basis path testing, programmer are following the below procedure to test complete programme.
Draw flow diagram for that programme
Calculate no of independent paths in that programme (geometric complexity).
Run that programme more than are time to cover all independent paths in that programme.
2. Control Structure Testing: - Programmers concentrate on the correctness and completeness of the corresponding programme outputs. They are checking every statement including ‘if’
conditions for ‘loops, memory allocations.
3. Program Technique Testing:- Programmers verify the execution speed of corresponding program. In this testing, programmer is taking the help of ‘monitors’ and “properties”. If the program speed is not good, then programmers are performing changes in structure of the programme without disturbing the functionality.
4. Mutation Testing:-
Test Test Test
Passed passed passed/fail
Mutation means a change is program. Programmers perform willing changes in programs and perform test separately. In this test programmers verify completeness and correctness of test on program.
TESTING TERMINOLOGY
1. Testing Strategy: It’s a document and it does define the required Testing approach to be followed by testing people.
2. Test Plan: It’s a document and its provides work allocation and in terms of schedule
3. Test Case: It does define test condition to validate functionality in term of completeness and correctness.
4. Test Log: It’s defining the result of test case in term of passed (or) fail of execution of testing case application build.
5. Error-Defect (Issue) -& Debug: a). A mistake in a coding is called ERROR b) This mistake found by Test engineer, during Testing called DEFECT/ISSUE. C). this defect/issue review &
Accepted by development team to release is called BUG.
6. Re-Testing: It’s also known as data driven (or) iterative testing. Test engineers repeat the same test on same application build with multiple I/P values. This type of test repetition is called Re- Testing.
7. Regression: The Re-execution of scheduled test cases on modified build to ensure, bug-fix work without any side effect is called regression test.
- - - -
- - Change - -
- - Change -
System testing process:-
S/W development process along with the S/W testing process.
Requiring Gathering (BRS)
Analysis & project planning (SRS& project plan/Test side plan)
Design & review (HLD, LLD) Test initiation
Coding & unit testing (WB) Test planning
Integration Testing Test Design
Initial Build
Test Execution Test reporting
Test cases
User Acceptance Test
Sign off Test
initiatio n
Test planning
Test
design Test
execution Test closer
Test reporting
SYSTEM TEST INITIATION
Generally the every organization system testing process is a starting with test initiation.
In this face project manager (or) test manager pepare test strategy documents. This document defines requires testing approach to be followed by testing team.
A) Components in test strategy:
1. Scope & objective; the important of testing & their mail stones.
2. Business issues; cost allocation in between development process and testing process.
3. Test approach; list of test factors of test issues to be applied by testing team on
corresponding S/W build. This selection is depending on requirement is that S/W build scope of the requirements and risk involve in our project testing.
4. Roles & responsibilities; The names of the job in testing team & their responsibilities.
5. Communication & status Reporting; This required negotiation between every two consecutive jobs in our testing team.
6. Test automation and Testing tools; The purpose of automation & available tools in our organization.
7. Defect Reporting & Tracking; The required negotiation between this testing team &
development team to review and resolve defect during testing.
8. Testing Measurements and machines; To estimate quality, compatibility & status testing team uses a set of measurement & metrics.
9. Risks & Assumptions; The exemptions list of problems this solution to overcome.
10. Change & Configuration management;
11. Training Plan; The required number of training session for testing team. To understand customers requirement (or) business logics.
Development
data box Test data
box
S/W coding
12. Test deliverable; Names of test document to be prepared by testing team during testing. Ex:
Test plans, cases, log, defect reports and same reports.
13. Test factors & testing issues; To define quality S/W, Testing team use 15 issues (or) topics.
These all topics are not mandatory in every project.
I. Authorization:- validity of users
II. Access Control:- Permission of users use specific functionality III. Audit trail: The correctness of metadata mean data about data IV. Continuity of processing:- Integration of processing
V. Data Integrity: - correction of me /P value: - compose mail (interim of size & Time).
VI. Correction of O/P value and Manipulation:-
VII. Coupling: - coexisting with other S/W to share common resources.
VIII. Ease-of-use : User friendly screen
IX. Ease of Operation: Installation, an installation dumping, downloading, upload.
X. Portability: Run on different platforms XI. Performance: Speed of processing
XII. Reliability: Recover from abnormal situation
XIII. Service Levels: Orders of functionality are services to give to customer side people.
XIV. Maintainable: whether our s/w is time serviceable to customer site people (or) not.
XV. Methodology: Testing factor on whether on testing team following predefined approach properly (or) not?
TEST PLAN
Test factors Vs Test Technique
Test factor indicate testing issue topic. This test engineer’s topic in our project testing team is following ECT of testing techniques
1. Authorization: security testing 2. Access control: security testing 3. Audit trial: Functionality testing
4. Continue of processing: Integrating (Programmer) 5. Data Integrity: I/P Domain testing
6. Correctness of proceeding of O/P value and manipulation: Functionality testing 7. Coupling: Inter system testing
8. Ease of use: user inter face testing/ manually support testing
9. Ease of operating: Insulation testing
10. Portability compatibility / configuration testing 11. Performance : load/stress/data volume testing 12. Reliability : Recover/stress testing
13. Service levels: S/W changes/ regression testing (by CCB) 14. Maintainable: Compliance testing
15. Methodology: Compliance testing
Whether the project team is following our enhancement standards.
Case study: - Test factor
15 (Project requirement) -4
11 (Scope of Requirement) +1
12 (Risks in Testing) -3
9 (Finalize Factor/Issue).
In Above example the project manager/ Test manager finalized 9 testing topics are issues to be applied by testing team On S/W Build.
IV. INTEGRATION TESTING
After completion of program development and unit testing, programmers are connecting them to form a complete software field. In this integration of programs, programmers verify interfaces in between every 2 programs or modules.
They are four types of approaches to interactive modules such as
1. Top-Down Approach: In this model programmers interconnect main module to sub modules. In the place of under constructing sub modules, programmer use temporary programs, called as
“stubs (or) called programs.
2. Bottom-Up Approach: - In this programmers interconnect sub modules without using under construction main module. In place of that under construction main module programmers use the temporary programme called driver or calling program.
3. Hybrid Approach: - In this approach we combine from top-down and bottom-up approaches also known as Hybrid approach. Or approach.
Main
Sub 1 Sub
2
Stub
Sub 1
Sub 2
Driver
Main
Mai n
Driver
Sub 1
Sub
2 Sub
3 Stub
4. Big-Ban Approach: - In this model programmers interconnect programs after completion of complete coding.
V. SYSTEM TESTING
After completion of integration testing, development people release S/W build to the separate testing team. This separate testing team is validating the S/W build with respect to customer requirements. In this level of testing the separate testing team uses block-box testing technique.
These techniques are classifying into three categories.
1. Usability / Accessibility Testing 2. Functional Testing
3. Non-Functional Testing
1. Usability / Accessibility Testing: Generally the system test executing is starting with usability test. During this test, test engineers validate user-friendliness of every screen in application build.
This Usability testing two consists of Sub-Techniques A) User- Interface Testing:
During this test, Test engineers are applying below 3 factors for every screen of our application window.
Screen of Build Ease of Use Look & Feel Speed in Interface.
1. Understandable Screen 2. Attractive
3. Less no events of to completed task Ex: Short Navigation.
B): Manual Support Testing: During this Test, Test engineers study help of application build to estimate context sensitiveness. Generally, technical writers of company develop user manuals before the releasing the S/W to customer. Due to this reason the manual supporting testing is coming into picture at the end of the system testing.
USABILITY TESTING Receive S/W from developers
UI Testing
Functional & Non-Functional Testing Manual Supporting Testing
2.
Functional Testing.
It’s monitory testing level in system testing. During functional testing, test engineer concentrate to meet customer requirements.
Functional testing is classified into two sub testing techniques.
A) Functionality Testing:-
1) GUI Coverage or Behavioral 2) Error- Handling-Coverage 3) I/P domain Coverage
4) Manipulation Coverage or O/P Coverage 5) Back-End Coverage
6) Order of Functionality Coverage
During this test, test engineer verify whether functionality is working correct or not. In this testing, test engineer construct below coverage’s.
GUI: Changing properties of screen Objects before.
E-H.C: Verify the prevention of wrong operations.
I/P-D-C- verify the size and type of every I/P object values.
M/C: Correctness of O/P.
B-E: The I/P of front-end operations on B/E tables.
O.F.C.:
B.) Sanitation Testing: Is also known as GARBAGE Testing. During this test, test engineers find test functionality of application build with respect to customer.
3
. Non-Functionality Testing: During non-functionality testing, testing team concentrates on extra characteristic of S/W build to customer.
A) Compatibility Testing: It’s also known as portability testing. During this testing, Test engineers’
validate whether the application build is running on customer expected platform or not?
Platform means that O/S, compilers, browsers and other system S/W.
B) Configuration Testing: Is also known as H/W compatibility testing. During this test, test engineer test remaining application builds with various technologies. H/W devices to estimate H/W compatibility.
Example: Technical Printers, Technical Networks, Technical Topologies.
C) Recovery Testing: Error-Handling is also known as reliability resting. During this test, test engineer validate whether, application build is changing from, abnormal status to normal status are not?
D) Inter System Testing: It’s also known as interring operator ability End-to-End testing. During this test, test engineers validate, whether our application Co-exists with other S/W application to share common resources.
E) Security Testing: It’s also known as penetration testing. During this test, test engineers validate below 3 factors.
1. Authorization 2. Access control
3. Encryption/decryption.
In authorization testing, test engineers validate whether application accepting users and reject invalid users are not?
In access control testing test, test engineers validate permission of users, for utilize of application
Then En/De testing, test engineers are trying to trace CIPHER test to original test.
Security testing authorization and access control test are reasonable to application, but En/De is conducted by separate test security testing people.
F) Data volume Testing: It’s also known as storage testing or memory testing. During this test, test engineer find peek limit data handled by our application build. Example: Ms-Access Technologies, data bases, Supporting as a 2 GB. Data base Max.
I) Load Testing: No of users using the software at same time. Ex: websites, yahoo—G-mail.
Load means that no of concurrent users which are accessing, application at the same times.
Execution of application on customer expected configuration is called Load Testing.
H) Stress Testing: The performance of application on customer expected configuration and whichever load levels to estimate stability is called S/T.
I) Installation Testing: During this test, testing team practice, on Initial S/W. During this initial testing, testing team is taking S/W build and supporting S/W to run our application build at customer side.
J) Parallel Testing: It is also known as comparative are competitive testing. During this, test, test engineer compare S/W with old version of same S/W and with other company similar product to estimate competitiveness. This testing applicable to S/W product only.
VI) USER ACCEPTANCE TESTING
After completion of testing system, the project management concentrates on user acceptance testing to collect feed back from real customer or model customer. There are 2 ways to conduct user
acceptance test.
α- ALPHATESTING β-BETA TESTING
Real customer by model customer
At Development site at model customer
S/W application For S/W product
After completion of user acceptance testing, project management concentrate on S/W release VII) MAINTAINS (OR) SUPPORT TESTING
Project management declares release team with developers and test engineers and H/W engineers.
This release team conducts part testing (or) deployment testing (or) release testing. During this test release team observe below factors.
Complete installation
Our all functionality
I/P devices handling
O/P device handling
Secondary storage devices handling
O/S error handling
Co-Existence with other S/W application
After completion of above observations, release team gives training on customer software and coming back.
During utilization of the S/W, customer side people send change requests to Organization. This responsible team of organization handles changes. This responsible team is also known as Change Control Board (CCB).
CHANGE REUQEST
ENHANCEMENT MISSED EFFECT
IMPACT ANALYSIS IMAPACT ANALYSIS
PERFORM S/W CHANGES PERFORM S/W CHANGES
TEST S/W CHANGES TEST S/W CHANGES
IMPROVE TEST EFFICIENCY INTRODUCTION OF THE TESTING
CASE STUDY
Testing Phase Testing Technique Responsibility
Testing in analysis Review Business analysis
Testing Design Review/ Proto type Designers/ Archives
Unit Testing White box Testing Techniques Programmers Integration Testing Top-down/Bottom-Up/Hybrid/
Big-bang/
Programmers
System Testing Black Box Testing Test engineers
User Acceptance Testing Alpha/ Beta Testing Really /Model customers Port Testing Complete installation over all
functionality
Release Team
Test S/W Changes in Maintains Regression Testing CCB( Change Control Board) Planned Testing Verses Ad-Hoc Testing
Generally every testing process is planned to conduct complete system testing with respect to project requirements. Testing team may not be able to conduct complete testing due to risks or challenges.
Ex: lack of times, knowledge, recourses…ECT, lack of Document.
AD-HOC: Due to above risks testing team plans to follow informal testing methods.
A) Monkey Testing: During this style of testing, testing people concentrate on main activities on S/W. Due to lack of time for testing. This style of testing is also knowledge Chinpanji (or) Random testing.
B) Buddy Testing: In this style of testing, test engineers are grouped with developers, due to lack of time for testing. Buddy means group, of a programmer & a tester .
C) Exploratory Testing: Generally the testing team conducts system testing depending on functionality and system requirements as in SRS. If the SRS is in complete with requirements, then test engineer depend on past experience, discussion with others, similar projects, browsing ECT to collect complete requirements. This style of testing is called Exploratory Testing.
D) Pair Testing: In this style of testing junior test engineers are grouped with senior test engineers to share the knowledge of testing. This style of testing is called PAIR Testing.
E) De-bugging: The development people add bugs into coding and release to testing team. This type of defect seeding/feeding is useful to estimate efficiency of testing team. It’s also known as defect seeding/feeding.
TESTING PLANNING
After completion of test strategy finalization, the test lead categorizes people and develops test plan.
In this stage the test lead categorizes people and develops system test plan & divide that plan into module test plan. The plan defines ‘What to test’, ‘How to test’, ‘When to test’, and ‘Who to test’.
To develop this plan test lead categorizes people as below Project plan
Testing team formation Develop document (SRS) Identify tactical Risks
Prepare test plan Test plan Test strategy Review test plan
A)
Testing Team formation: Generally test planning task starts with testing team formation. In this stage test lead depends on below factors.
Project Size
Lines of columns (or) Functionality Availability of Test engineer Test time/duration
Test/ environment Case Study 1.
Client server, website, ERP--- 3 to 5 months of system technique System S/W (networking, mobile) 7 to 9 months of system technique Machine Criteria S/W (SAT) 12 to 15 months of system technique
B) Identify technical risks: After completion of testing team formation test lead concentrates on risk analysis & exception with that of formed testing team.
Example:
Risk 1: Lack knowledge of testing engineers that project domain.
Risk 2: Lack of time
Risk 3: Lack of Document’s
Risk 4: Delays in delivery
Risk 5: Lack of development process Resource Risk 6: Lack of Resources.
Risk 7: Lack of communication.
C) Prepare Test plan: After completion of team formation & risks analysis, test lead concentrates on test plan document. In this stage test lead uses IEEE 829 test plan document format.
Formats:
1. Test plan ID: The title of test plan document for format reference.
2. Introduction: About project.
3. Test Item: List of modules in project.
4. Feature to be tested: List of modules (or) Function to be tested.
5. Feature not to be tested: List of modules, which are already tested in previous version 6. Approach:-List of testing technique to be applied on modules ( from test strategy) 7. Test deliverables: Required testing document to be prepared by testing team.
8. Test environment: Required H/W, S/W to test modules.
9. Entry criteria: Test engineer are able to start test execution after creating as a. Test cases develop & review
b. Test environment established
c. S/W build received from development.
10. Suspension criteria: Same times test engineer stop test execution. Due to a. Testing environment is not working.
b. Reported defects are more at development side. (Quality Gap) 11. Exit criteria: It defines test execution process exit point.
a. All requirement are tested b. All major burgs resolved
c. Final build is stable with respect to customer required.
What to test 3, to 5
How to test 6 to 11
Who to test 12 to 13
When to test 14
12. Staff & training needs: Selected test engineers name & required no of training sessions 13. Responsibilities: The match between the names of test engineer & requirements.
14. Schedule( dates and time): Date and time of Project
15. Risks & exemption: List of analysts and their exemptions to overcome.
16. Approach: Signature of project manager (or) test manager and test lead.
D) Review Test Plan: After completion of test plan document preparation, test lead conducts review meeting, to estimate completeness and correctness of document. In this review the Testing team members of that project also involve.
In the preview meeting the testing people depend on below factors.
a. Requirement based coverage (what to test).
b. Testing technique based coverage(How to test) c. Risks based coverage (Who and when to meet).
TEST DESIGN
After completion of test planning the corresponding selected test engineers concentrate on test design, test execution, and test reporting.
Generally the selected test engineers design test cases for every project. In test design every test engineer studies all the requirements of the project and prepares test cases for selected requirement only with respect to test plan. In this test design, test engineers use three types of test case design methods to prepare test cases for responsible requirements.
1. Function and systems specification based test design.
2. Use cases based test case design.
3. Application build test case design based.
TEST CASE DEFINITION:
Every test case defines a unique test condition, and then every test case is self standing and clear. To ensure understandability test engineers, start every test case with verify or check English words.
Every test case is traceable with requirements.
Functional and System Specification Bases Test Case Design BRS
SRS Test cases
(Functional system requirement) HLD & LLD
Coding .Exe Build
From the above diagram test engineers prepare the maximum test cases depending on functional and system requirement as in SRS. In this type of Test cases, Test engineer follow below approach.
Step 1: Collect functional & system specification of requirements.
Step 2: Select specification from that list 2.1: Identify entry point.
2.2: Identify I/P required.
2.3: Study normal flow.
2.4: Identify O/P & Out comes 2.5: Identify exit point.
2.6: Identify alternative flow & exception. (Rules).
Step 3: Prepare test case titles, or test scenarios.
Step 4: Review Test cases for Completeness & Correctness.
Step 5: Prepare complete documents for every test case title.
Step 6: Go to Step 2 & until specifications are met and test cases Functional & Specification-1
A login process involves user ID & password authorization. Use ID is accepting alpha numeric in upper case of 4 to 16 characters along.
The password is accepting alphabets in upper case of 4 to 8 characters.
Prepare Test Case Titles (Or) Scenarios Test case 1:
Verify user ID Value
Boundary value Analysis’s Equivalence Class Participation
BVA (Size) (ECP)/ Type
Min- 4 char –pass Valid Invalid
Max-16 char—pass a-z A_Z
Min-1, 3 char—fails 0-9 Special characters
Min +1, 5 char—Pass Blank filed
Max-1, 15 char-pass Max+1, 17 char—Fail
Test case 2:
Verify password value
Boundary value Analysis’s Equivalence Class Participation
BVA (Size) (ECP)/ Type
Min- 4 char –pass Valid Invalid
Max-8 char—pass a-z A_Z
Min-1, 3 char—fails Special characters
Min +1, 5 char—Pass Blank filed
Max –1 7 char-pass 0-9
Max+1, 9 char—Fail Test case 3:
Verify login Operation Decision Table
Use ID Password Criteria
Valid valid pass
Valid Invalid fail
Invalid valid fail
Valid blank fail (from validation)
Blank valid fail (from validation)
Functional specification 2
An insurance application apply for different types of policies when a user selects the type, insurance system asks age of that user. The age value should be greater than 16 years and should be less than 80 years prepare test case titles and scenarios.
TC 1: Verify the selection of insurance type.
TC2: Verify, focus on age when user selects insurance.
TC3: Verify age value
BVA on range ECP in type
Valid Invalid
Min 17 pass Max 79 pass Min-1, 16 fail Min+1,18 pass Max+1, 80 fail Max-1, 78 pass
0-9 a-z
A-Z
special characters blank field
Functional specification 3
A door opened when a person comes in front of the door and the door closed when that person comes inside. Prepare test case title for this scenario.
TC 1: verify door open
Person Door Open
Present Present Absent Absent
Open Closed
Open Closed
Pass Fail Fail Pass
TC2: Verify door close (operation)
Person Door Criteria
Inside
Inside Closed
Open Pass
Fail
TC3: verify door operation when that person is standing in the middle of the door.
Person Door Middle
Present Present Not present Not present
Open Closed
Open Closed
Pass Fail Fail Pass
Functional specification 4 A computer shut down operation prepare test case title or scenario.
TC1: verify shutdown option section using start menu.
TC2: verify shutdown option section using Alt+ F4.
TC3: verify shutdown operation.
TC4: verify shutdown operation when a process is in running.
TC5: verify shutdown using power ON/OFF.
Functional specification 5
In a shopping application users purchase different types of items. In purchase order, system is allowing users select item number and enter quality up to 10, purchase order returns total amount along with one item price. Prepare test cases or scenario
TC1: verify the selection of item numbers TC2: verify quantity value
TC3: verify calculation such as total equal price X-given quality.
Functional specification 6 Washing machine operation: prepare test case titles or scenario TC1.verify power supply
TC2.verify door open
TC3.verify water filling with detergent TC4.verify cloths filling
TC5.verify door closing
TC6.verify door closing due to cloths overflow TC7 verify washing settings
TC8 verify washing operation
TC9 verify washing operation with low voltage.
TC10 verify washing operation with cloths overload inside
TC11 verify washing operation with door open in middle of this process TC12 verify washing operation with lack of water
TC13 verify washing operation with water leakage TC14 verify washing operation with in proper setting TC15 verify washing operation with machine problem.
BVA ECP(type)
Valid Invalid Min 1pass
Max 10 pass Min-1, 0, fail Min+1, 2 pass Max-1, 9 pass Max+1,11 fail
0-9 a-z
A-Z Special characters Blank field
Functional specification 7
In an e_banking application, users are connecting to bank server through internet connection. In this application users are filling below fields to connect to bank server.
Password 6 digit numbers.
Area code 3 digit numbers.
Prefix 3 digit numbers but doesn’t start with 0 and 1.
Suffix 6 digit alpha numeric.
Commands cheque deposit , money transfer, mini statement, and bill pay Prepare tests cases title or scenarios.
TC1: verify password value
BVA on size ECP type
valid Invalid Min=max=6 digits
Min-1,5 –fail Min+1,7—fail Max+1,7 fail Max-1, 5 fail
0-9 a-z
A-Z Special character Blank fields TC2: verify area code value.
BVA on size ECP type
valid Invalid Min=max=3 pass
Min-1,2 –fail Min+1,4-fail Max+1,2 fail Max-1, 4 fail
0-9 blank field
a-z A-Z Special character Blank fields TC3: verify prefix value
BVA on size ECP type
valid Invalid Min 200, Max 999
Min-1, 199-fail Min+1,201-pass Max+1, 1000-fail Max-1, 998-pass
0-9 a-z
A-Z Special character Blank fields TC4 verify suffix value.
BVA on size ECP type
valid Invalid Min=max=6 pass
Min-1,5 fail Min+1, 7 fail Max+1,7 fail Max-1, 5 fail
0-9 a-z A-Z
Special character Blank fields
TC5: verify connection to bank server
TC6: verify solution of commands such as cheque deposit, money transfer, mini statement and bill pay
Fields value Criteria
All are valid values Anyone is invalid
value Anyone is blank expect area code All are valid values
and area code is blank
Pass Fail Fail Pass
Functional specification 8 A computer restart operation prepares test case tittles or scenario.
Functional specification 9 Money withdrawal from ATM machine. Prepare test case titles.
1. Verify card insertion
2. Verify card insertion is wrong angle or improper angle 3. Verify card insertion with improper account
4. Verify PIN number entry
5. Verify operation when you enter wrong pin number 3 times 6. Verify language selection
7. Verify account type selection
8. Verify operation when you selected invalid account type with respect that inserted card.
9. Verify withdrawal option selection 10. Verify amount entry
11. Verify withdrawal operation correct amount, right receipt and able to take back the card.
12. Verify withdrawal operation with wrong demonstrations in amount
13. Verify withdrawal operation when our amount greater than possible amount 14. Verify withdrawal operation due to lack of amount in ATM.
15. Verify withdrawal operation when our amount is greater than day limit
16. Verify withdrawal operation whenever current transaction number greater than day limit on number of transaction.
17. Verify withdrawal operation when we have network problem 18. Verify cancel after insertion of card
19. Verify cancel after entry of pin number.
20. Verify cancel after selection language.
21. Verify cancel after selection of correct type.
22. Verify cancel after entry of amount.
Test case documentation: After completion of test case scenarios selection, test engineers document the test cases with complete information. In this test case document test engineers use IEEE 829 formats.
('Institute of Electrical and Electronics Engineers').
Test case Formats:
1. Test case ID: unique number or name
2. Test case name: the title or scenario of corresponding test case 3. Featured to be tested: corresponding module or function or service
4. Test suite ID: The name of test batch, in this batch our test case is a member
5. Priority: The importance of test case in terms of functionality Po: basic functionality, P1, general functionality P2: cosmetic functionality
6. Test environment Require H/W and S/W to execute this test case and application build.
7. Test effort: Expected time to execute the test case on build Example: 20 min is our average time 8. Test duration: approximate date and time
9. pre condition or test setup: necessary task to do before start this test case execution 10. Test procedure or data matrix: A step by step.
Step no Action I/P required expected Actual Result Dept.ID Above table first 4 columns call test design and another 3 columns call test execution.
Data matrix:
11. Input ECP(type) BVA(Size)
Object Valid Invalid Min Max
11. Test cases pass or fail criteria: when this case is passed and when this case is failed.
Note 1: Above 11 fields test case format is not mandatory because some field values are common to max test cases and some fields values are is to remember or derive
Note 2: Generally the test cases cover objects and operations. These test cases cover objects values, then test engineers’ prepare data matrix.
Note3: If test case covers operation or execution then test engineers prepare test procedures from base state to end state.
Functional specification 10
A login is process is allowing a user id and password to authorise users. User id is taking alpha numeric in lower case from 4 to 16 long. The password object is accepting alphabets in lowercase from 4 to 8 characters long. Prepare test case document
Document 1
1. Test case ID: TC_login_arjun_1 2. Test case name: verify user ID 3. Test suite ID: TS_Login
4. Priority: Po
5. Pre condition user id object taking values from key board 6. Data matrix:
I/P Object ECP (type) BVA (size)
Valid Invalid Min Max a-z
0-9 A-Z
Special blank
4
man 16
sasidhar
Document 2
1. Test case ID: TC_login_arjun_2
2. Test case name: verify user ID 3. Test suite ID: TS_Login
4. Priority: Po
5. Pre condition password, object is taking values from Key board.
6. Data matrix
I/P Object ECP (type) BVA (size)
Valid Invalid Min Max
a-z 0-9
A-Z Special blank
4
man 8
sasidhar
Document 3
1. Test case ID: TC_login_arjun_3 2. Test case name: verify login operation 3. Test suite ID: TS_Login
4. Priority: Po
5. Pre condition password, object is taking values from Key board.
6. Test procedure
Step no Action I/P required Expected
1 Focus to
login window
None User id object
focused 2 Fill fields User ID &
password
‘OK’ button
3 Click ‘OK’ Valid-valid
Valid-invalid Invalid-valid Value-blank Blank-password
Next window Error message
--do—
--do—
--do—
2. USE CASES BASED TEST CASE DESIGN
Use cases Based: The other method for test case selection is use cases based test case design. This method is preferable for out sourcing testing companies. Generally max testers preparing TEST CASE depending functional system specifications in corresponding project SRS, some times the testing people prepare test cases depending on use cases also. Use cases are more elaborative and understandable than functional and systems specifications.
BRS
Depends
SRS Test cases
HLD LLD’S
CODING (BUILD)
From the above diagram, testing team receives use cases from project management to prepare test cases.
Every use case is describing functionality with all required information. Every use case follows a standard format unlike theoretical functional specification.
FORMATS:
1. Use case name: The name of use case for future reference.
2. Use case description: Summary of functionality
3. Actors: Name of actors, who participate in corresponding function
4. Related use cases: Name of selected use cases, which have dependency with other use cases 5. Pre conditions: List of necessary tasks to do before start this functionality testing
6. Activity flow diagram: The graphical notation of corresponding functionality.
7. Primary scenario: A step by step action to perform corresponding functionality 8. Alternative scenario: Alternative list of actions to perform same functionality 9. Post conditions: It specifies the exist point of corresponding functionality 10. User Interface makeup: Model screen or proto type
11. Special requirement: List of rules to be followed if possible from the above use case format;
project management provide all functionality documents with complete details. Depending on that use cases, test engineers prepare test case titles and then documentation using IEEE 829 format.
3 APPLICATION BUILD BASED TEST CASE DESIGN
Generally the test engineers prepare test cases depending on functional and system specifications or use cases. After completion of maximum test cases selection, test engineers prepare some test cases depending on application build, which received from development team these new test cases concentrate on usability of the screens in an application. These test cases cover ease of use, look and feel, speed in interface, and user manual correctness.
Example of Test cases:
Verify spelling in every screen
Verify contrast of each object is every screen
Verify alignment of object in every screen
Verify column commonness in all screens
Verify font commonness in all screens
Verify size commonness in all screens
Verify functionality grouped objects in screens
Verify borders of functionality grouped objects
Verify tool tips Extinguisher: messages about icons in screens
Verify the place of multiple data objects in screen Extinguisher: list boxes, table grids, active X control menus and data windows.
Verify scroll box
Verify labels of objects in every screen as init ’Cap’
Verify key board accessing in one application build
Verify abbreviation in all screens Extinguisher: short cuts
Verify information repetition in screens Ex: Date of birth (dd/mm/yyyy, mm/dd/yyyy).
Verify help document (help menu contents in our application menu).
Note: Generally the test engineers prepare maximum test cases depending on functional and system specifications in SRS. The remaining test cases are prepared using application build because the functional and system specifications don’t provide complete information about every small issue in our project. Some times the testing people use Use cases instead of functional and system
specification in SRS.
Review Test Cases: After completion of test cases selection and documentation, test lead conducts review meeting along with test engineers. In this review test lead concentrates on completeness and correctness of test cases. In coverage analysis, test lead considers 2 types of factors.
Requirement based test cases coverage to conduct test cases
Testing techniques based test cases coverage after completion of this review meeting test engineers concentrate on test execution.
IV.TEST EXECUTION
In test execution, test engineers concentrate on test cases execution, defect reporting and tracking. In this stage the testing team conduct a small meeting with development team for version controlling and establishment of test environment.
Development Initial builds Testing (sanity/smoke) Stable build Level 0
Bug fixing Defect reporting Level 1 (Comprehensive/ exclusive)
Bug resolving Modified build Level 2 (Regression)
(Master build) Level 3(Final regression / post mar testing) 1. Version control: During test execution developers assign unique version numbers to software
builds after performing required changes. This version numbers system should be understandable to testing people. For build version controlling the development people use version control software’s. Example: VSS (visual source save).
LEVELS OF TEST EXECUTION Vs TEST CASES Selected test cases for
Level 0 Basic functionality Software Test case
Builds
Defect
Level 1 Total functionality
Level 2 Selected test cases W.R.T. Modification Level 3 Selected test cases W.R.T. Bug density
Note: Level 0 on Initial build Level 1 on stable build Level 2 on modified build
Level 3 on master build & Golden build is released to customer Level 0
Generally testers start test execution with level 0 testing. It’s also known as sanity or smoke or octangle or tester acceptance or build verification or testability.
In testing level test engineers concentrate on below 8 factors through operating corresponding initial build.
1. Sanity or smoke test or Understandable 2. Operatable
3. Observable 4. Controllable 5. Consistency 6. Simplicity 7. Maintainable 8. Automat able Level 1 :( comprehensive testing):
After receiving stable build from development team, test engineers execute all test cases sequentially either in manual or in automation. In manual test execution, test engineers compare test cases specified expected values & build specified actual value. In test execution test engineers prepare test log . This document consists of 3 types of entries.
1. Passed: all excepted values of the test case are equal to all actual value build.
2. Failed: Any one expected value is variation with in anyone actual value builds.
3. Blocked: dependent Test case execution postponed to next cycle. Due to wrong parent functionality.
Level 2 regression testing):
During level1 comprehensive testing, testing people report miss matches in between test cases expected and build actual to development team as defect report. After reviewing and resolving the defect the developer releases note. The responsible test engineers study the release note and try to understand modification in modified build, and then the test engineers concentrate on regression testing to ensure that modification.
All test cases in QUE Execution SKIP
BLOCKED
Passed
Partial (PASS/FAIL)
FAIL CLOSE
Level 0
Level 1
Check in Level 2 Check out (Regression)
From the above diagram test engineers conduct regression testing on modified build which are modified in release note. Study release note and consider severity of resolved bug.
High Medium Low
All P0 All P0 Same P0
All P1 Max P1 Same P1
Max P2 TC Same P2 TC Same P2 TC
Case 1: The development team resolves bug severity as high, then test engineers re-execute all Po, All P1, and carefully select max, P2 test cases. On modified build with respect to, modification mentioned in release note.
Case 2: If the development team resolves bug severity as medium, then test engineers execute all Po, carefully selected all P1, and some of P2, test cases, on modified build W.R.T Modification mentioned in release note.
Case 3: If the development team resolves bug severity as how, then test engineers are re-executing some Po, P1, P2, test cases are that modified build W.R.T. to mention is release.
Case 4: If the test team modified build due to sudden changes in customer requirements, and then test engineers re-execute all Po allP1, carefully selected max P2, test cases on modified build W.R.T.
modification mentioned in release notes.
V.TEST REPORTING
During level-1 and level2 test execution test engineers report miss-matches is between test cases expected values and build actual values as defect report to development team. In test reporting development receive defect report from testing team in standard format. This format is followed by every test engineer during test execution to report defects.
IEEE 829 defect report format:
1. Defect ID: unique number or name for future reference
