Java Programming Questions and it's Solution
1.Write a program for Fibonacci Series:
Program:
import java.util.Scanner;
public class Practice {
//Write a program for Fibonacci Series
//This is a program where each numbers are summation of previous two numbers like
public static void main(String args[]) {
Scanner sc = new Scanner(System.in);//Here Scanner class is used to take inputs from user
long x = 0;
long y = 1;
long z;
System.out.print("The maximum value entered by you is: ");
int num = sc.nextInt();
System.out.println("The maximum value entered by you is: " + num);
System.out.println("Expected Fibonacci series is: ");
System.out.print("\t" + x);
System.out.print("\t" + y);
for (int k = 2; k <= num; k++) {// Since the value at position 0 and 1 is already printed hence in for loop we are starting from 3rd position directly
z = x + y;//Since each value is the summation of it's previous two positions
System.out.print("\t" + z);
x = y;//As after each iteration position of x will be replaced/changed by y
y = z;//As after each iteration position of y will be replaced/changed by z
}
}
}
Tips while writing test cases
Below are the general tips to write test cases:
- Every Test Case must start with verify/validate/check
- Test case must cover positive and negative test cases both
- Test case must be traceable via module or testing topics
- Test case must specify what a tester has to perform and the response of the software
- Test case must give the consistent result i.e. different testers should not get the different result
- Test case must be re-usable
- Test case must be divided into sub test cases if there are more than 15 steps or so.
- Test case must have the defect id, if it is being failed
- Test cases prepared by the testers must be reviewed by the test lead
- Test cases must be approved by the customer site people.
Non-Functional Test Design
Non-Functional specification based test design starts only after the completion of the test scenarios and test cases writing (using functional specifications, Use cases or screen of the Software Under Test). In order to prepare the non-functional test scenarios, testers depend on the non-functional specifications in the system request specifications.
 |
| Non-Functional Specification Based Test Design |
From the above diagram, It is clear testers read the non-functional specifications from SRS and then they prepare the test scenarios for- Usability, Performance, Security, Data Volume, Intersystem, Hardware Configuration, Installations, Multilinguality etc. Generally these test scenarios cover the following points:
- Verify spelling of labels in every screens of SUT
- Verify labels int cap in every screens of SUT
- Verify color uniformity throughout the screens of SUT
- Verify font-type uniformity throughout screens of SUT
- Verify font-size uniformity throughout screens of SUT
- Verify alignment of controls uniformity throughout screens of SUT
- Verify uniformity in the spacing among controls throughout screens of SUT
- Verify correctness of functionality grouped controls throughout screens of SUT
- Verify meaning of labels throughout screens of SUT
- Verify correctness of tool tips throughout screens of SUT
- Verify symbol of the icon to match with the provided functionality throughout screens of SUT
- Verify shortcuts throughout screens of SUT
- Verify abbreviations throughout screens of SUT
- Verify meaning of error messages throughout screens of SUT
- Verify OK and Cancel like buttons throughout screens of SUT
- Verify system menu appearance throughout screens of SUT
- Verify existence of scroll bars throughout screens of SUT
- Verify status bar or progress bar throughout screens of SUT
- Verify format of Date, Time and visibility in screens of SUT
- Verify help documents of a software in SUT
Above points are also termed as check list.
Test Design
When the test planning is completed, testers receive this test plan document. With this testers also get System Request Specification document sometimes along with the Business Request Specification document. In case of lack of training testers study these documents to have a good grasp/domain knowledge on the application or current project or the product. When testers understand the documents properly they go for preparation of Test Design document which are of two types:
1) High Level Test Design
2) Low Level Test Design
High Level Test Design
This is the first step in preparation of the test design. In this, testers are responsible for the preparation of the Test scenarios for the relevant modules in the software under test. In order to create the test scenarios, testers are given either of the below:
a) Functional Specification
b) Use Case
c) Screen/Mock-up
d) Non Functional Specification
However preparation of the test scenarios will be common for either/all of the above 4 styles. It includes the below three parts/sections:
1. BVA (Boundary Value Analysis)
2. ECP (Equivalence Class Partition)
3. Decision Table
2. ECP (Equivalence Class Partition)
3. Decision Table
- Here Boundary Value Analysis deals with the size/range of the particular field (inputs and outputs of the application/software/product) like this filed should take minimum 4 characters and maximum 15 characters.
- Here ECP deals with the Type/format of the inputs to the fields like this field (inputs and outputs of the application/software/product) should only characters/special characters/Blank spaces etc. or it should not allow numeric values
- In 'Decision Table' we mention the expected output/outcome for the initial/previous valid and invalid fields of different combinations.It is used to define the positive and negative inputs to validate variations of the functionalities in the software under test.
Orthogonal Arrays- In this concept the repetition of decisions in the decision table is avoided.
Low Level Test Design
When the test scenarios writing is done, testers enhance(here enhancing scenarios means breaking it into further parts ) those test scenarios into test cases. Test scenarios just tell us about the specific test condition but the test cases tells about the step by step procedure to test the scenarios. In general, testers follow IEEE-829 format for writing the test cases.
Format of IEEE-829
1) Test Case Id- This is a unique number or name or sometimes combinations of number and name both which is used for reference
2) Test Case Name- This is the name of the relevant test scenario
3) Feature/Module- This is the name of the parent module for the relevant test case.
4) Priority- This denotes the importance level of the relevant test case like below:
(a) High (Priority- P0) [It is related to the Functional Part]
(b) Medium (Priority- P1) [It is related to the Non-Functional Part (excluding usability)]
(c) Low (Priority- P2) [It is related to the Usability]
5) Test Suite Id- It is the id for the parent of the niche test cases or we can say this is the name of the batch in which there are more than one test case.
6) Test Set-up- This represents the required conditions to follow the above 5 steps and to start the test execution.
7) Test Environment- This represents the required software and hardware in order to run the test cases.
8) Test Procedure- This is the step by step procedure in order to run the current test case(s).
Low Level Test Design
When the test scenarios writing is done, testers enhance(here enhancing scenarios means breaking it into further parts ) those test scenarios into test cases. Test scenarios just tell us about the specific test condition but the test cases tells about the step by step procedure to test the scenarios. In general, testers follow IEEE-829 format for writing the test cases.
Format of IEEE-829
1) Test Case Id- This is a unique number or name or sometimes combinations of number and name both which is used for reference
2) Test Case Name- This is the name of the relevant test scenario
3) Feature/Module- This is the name of the parent module for the relevant test case.
4) Priority- This denotes the importance level of the relevant test case like below:
(a) High (Priority- P0) [It is related to the Functional Part]
(b) Medium (Priority- P1) [It is related to the Non-Functional Part (excluding usability)]
(c) Low (Priority- P2) [It is related to the Usability]
5) Test Suite Id- It is the id for the parent of the niche test cases or we can say this is the name of the batch in which there are more than one test case.
6) Test Set-up- This represents the required conditions to follow the above 5 steps and to start the test execution.
7) Test Environment- This represents the required software and hardware in order to run the test cases.
8) Test Procedure- This is the step by step procedure in order to run the current test case(s).
Test Plan Format
(1)Test Plan ID- It is a unique number or name for future reference.
(2)Introduction- It has description about the current project.
(3)Features or Modules- It has list of modules in the current project.
(4)Features to be tested- It has the number of modules which are to be tested in the current project.
(5)Features not to be tested-It has the number of modules which are not to be tested in the current project.
(6) Test Approach/Strategy- It is generally just an attachment provided by the Project Manager.
(7)Test Environment- It consists of the required hardware and software for testing of the current project.
(8)Entry Criteria- These are the criterias in order to start the test execution which includes:
(2)Introduction- It has description about the current project.
(3)Features or Modules- It has list of modules in the current project.
(4)Features to be tested- It has the number of modules which are to be tested in the current project.
(5)Features not to be tested-It has the number of modules which are not to be tested in the current project.
(6) Test Approach/Strategy- It is generally just an attachment provided by the Project Manager.
(7)Test Environment- It consists of the required hardware and software for testing of the current project.
(8)Entry Criteria- These are the criterias in order to start the test execution which includes:
- Test cases is prepared and reviewed
- Test environment is established
- Software under test has come from the developers
- Show stopper in SUT (Or Deadlock)
- Test Environment abandoned
- More defects in pending (Quality Gap)
- All Modules Tested
- Time exceeded
- All Major Defects closed
(11)Test Deliverables- These are the list of documents to be prepared by testers in testing. For example:
- Test Scenarios
- Test cases
- Automation Programs
- Test Logs
- Defect Reports
- Status Reports
(13)Responsibilities- This includes the work allocation to the selected testers in terms of modules or testing topics. It just represent 'Who to Test'.
(14)Schedule- It includes the Date and Time for the testing. It represents 'When to test'
(15)Risks and Assumptions- It consists of the lists of previously analysed risks and solutions to overcome them.
(16)Approvals- It includes the signature of the test lead and the project manager.
Click here to know all about test Test Plan
Click here to know about Test Initiation or Commencement
Click here to know about Test Design
Click here to know all about test Test PlanClick here to know about Test Initiation or Commencement
Click here to know about Test Design
Test Planning
After completion of the test strategy preparation, PM (Project Manager) can sign in a Test Lead. The test lead can study the test strategy document and can start preparation of the test plan document.
(a) Team Formation- Test lead can start test planning process with testing team formation. While formation of the team, test lead depends on the below factors:
 |
| Test Plan |
(a) Team Formation- Test lead can start test planning process with testing team formation. While formation of the team, test lead depends on the below factors:
- Project Size (Number of Functionalities)
- Test Duration (Number of Working Days)
- Available Testers on bench
- Available resources in test environment
Case Study
 |
| Team Formation |
(b) Identifying Tactical Risks- After completion of testing team formation ,test lead concentrates on risk identification which includes-
- Lack of Domain Knowledge to Testers
- Lack of Documentation
- Lack of Time
- Lack of Resources
- Delays is Delivery
- Lack of developer's seriousness
- Lack of Communication
(c) Preparation of Test Plan- After completion of testing team formation and risk analysis, test lead starts preparation of test plan document in IEEE (Institute of Electrical and Electronics Engineering) 829 format.
Click here to know about the 'Test Plan Format'
(d) Review Test Plan- After completion of test plan document preparation test lead conducts a review meeting along with project manager, business analyst, system analyst and selected testers for the current project. In this review meeting test lead performs the test changes in the test plan if needed (it depends upon the feedback)
Learn Next- Test Design
(d) Review Test Plan- After completion of test plan document preparation test lead conducts a review meeting along with project manager, business analyst, system analyst and selected testers for the current project. In this review meeting test lead performs the test changes in the test plan if needed (it depends upon the feedback)
Learn Next- Test Design
Test Initiation or Commencement
Software testing process starts when SRS is baselined. In software testing process, test initiation is the first stage. In this stage project manager or test manager category people prepare test strategy or test methodology document which specifies an approach to be followed by the testing team. There are three types of strategy in testing:
- Exhaustive Testing
- Planned Testing
- Ad-hoc Testing
From software testing principle, exhaustive testing is impossible. Due to this reason, test management concentrate on planned testing or ad-hoc testing methodologies. Ad-hoc testing is followable when testing team have some risks. When there are no risks testing team favors planned testing/ Formal testing/Optimal testing. From this planned testing, project manager or test manager prepare a test strategy document like below:
- Scope and Objective
- Business Issues
- Test Responsibilities in Matrix
- Roles and Responsibilities
- Status of Communication
- Test Automation and Testing tools
- Defect Reporting and Tracking
- Test Measurement and Matrix
- Test Management
- Risks and Assumptions
- Training Plan
Scope and Objective- In this importance of the current project is described
Business Issues- In this budget allocated for the testing project is mentioned like below:
Business Issues- In this budget allocated for the testing project is mentioned like below:
 |
| Budget Allocation |
Test Responsibilities in Matrix (TRM)- This matrix specifies the list of responsible testing topics in software testing.
Roles and Responsibilities- It consists of the jobs in the testing team and each job requirements like below:
Status and Communication- In every two jobs in testing team are co-ordinated via different channels. For example Personal Meetings, Offline Meetings, Online Chatting, Video Conferencing and internal communicator etc.
Test Automation and Testing Tools- In this need for test automation in current project and available testing tools in the company is mentioned.
Defect Reporting and Tracking- In this required negotiation channels in between developers and testers while reporting and tracking of defects is mentioned.
Test Measurement and Metric- Measurement is a basic unit and Metric is a compound unit. In order to estimate the testing process status, testers use a set of measurement and metric.
Test Management- Testing team need a sharable location to store all testing deliverables for future called as test base.
Risks and Assumptions- In this List of all risks (which might come in future) and assumptions (to overcome those risks) is mentioned.
Training Plan- Testing team need training on the customer requirements in current project. In this training, testers are trained by BA,SA and SME
Click Here to know about Test Planning
Click Here to know about Test Plan Format
Click here to know about Test Design
 |
| Test Responsibilities in Matrix |
Roles and Responsibilities- It consists of the jobs in the testing team and each job requirements like below:
 |
| Roles and Responsibilities |
Status and Communication- In every two jobs in testing team are co-ordinated via different channels. For example Personal Meetings, Offline Meetings, Online Chatting, Video Conferencing and internal communicator etc.
Test Automation and Testing Tools- In this need for test automation in current project and available testing tools in the company is mentioned.
Defect Reporting and Tracking- In this required negotiation channels in between developers and testers while reporting and tracking of defects is mentioned.
 |
| Defect Tracking Team |
Test Measurement and Metric- Measurement is a basic unit and Metric is a compound unit. In order to estimate the testing process status, testers use a set of measurement and metric.
Test Management- Testing team need a sharable location to store all testing deliverables for future called as test base.
 |
| Test Management |
Risks and Assumptions- In this List of all risks (which might come in future) and assumptions (to overcome those risks) is mentioned.
Training Plan- Testing team need training on the customer requirements in current project. In this training, testers are trained by BA,SA and SME
Training is optional to the testers if the testers have experience in the current project. The domain of the current project may be Banking, Insurance, Finance, Sales, Telecommunications, Health Care, eCommerce, e-learning etc.
Click Here to know about Test Planning
Click Here to know about Test Plan Format
Click here to know about Test Design
Software Testing Process
 |
| Software Testing Process |
Integrating SDLC and Software Testing Process:
 |
| Integrating SDLC and Software Testing Process |
- When SRS is baselined , project management recruit programmers and testers into current project.
- Project or product planning prepared by PM is more detailed. But testing team prepare separate test planning as well.
- Testing team start writing test cases (In order to start writing test cases testing team study the SRS)and after that they detect the defects after getting the build from the development team.
Learn about-
Review Techniques
Review Techniques are also called as document testing techniques. These techniques are used by BA (Business Analyst), SA (System Analyst) and designer in order to verify BRS (Business Request Specification), SRS(System Request Specification) and design documents (respectively). While reviewing they follow three techniques which are:
 |
| Review Techniques |
- Walkthrough
- Inspection
- Peer Review
Walkthrough- It is the verification of a document from first to last for correctness and completeness.
Inspection- In this technique, a document is searched for a specific factor.
Peer Review- It is the comparison of two similar documents to estimate correctness and completeness.
The above review techniques are also called as static testing techniques.
The combination of White Box, Black Box, Yellow Box and Green Box testing techniques is called dynamic testing techniques.
Maintenance or Support
 |
| Change Control Board |
During utilization of software, customer side people send software change request (SCR) to the companies. Project management manages the Change Control Board (CCB) to receive such requests. This CCB consists of developers and testers to perform the change in software.
 |
| Change Control Board |
Enhancement(s)-
 |
| Enhancements |
- Perform Changes
- Test Changes
- Release software patch to customer site
Now again the maintenance is again partitioned into two parts which are-
1) Enhancive Maintenance
2) Adaptive Maintenance
 |
| Missed Defects |
CCB conducts root cause analysis order to identify the areas to be change in software to correct-
- Perform Changes
- Test Changes
- Release patch to customer site
- Improve capability of both testers and developers(People Improvement) and process for upcoming project(s)(Process Improvement). This is called as corrective maintenance.
Release Testing or Port Testing
After completion of acceptance testing, project management concentrate on release team formation along with few testers, few developers and few hardware engineers. This release team is also called as onsite team or delivery team and the lead of the team is called as Delivery Head. This team go to customer site and launch the software after observing the below factors:
- Complete Installation
- Overall Functionality
- Input device handling(keyboard, mouse etc)
- Output device handling(Fax, monitor, printer etc)
- Secondary storage devices handling like CD, Pendrive, Hard disk, Floppy Drive etc.
- Operating System support
- Co-existence with other softwares in customer site
After completion of software launching and release testing, release team provide training to customer site people on that software. After of training release team return to their own organisation.
 |
| Release Testing |
Acceptance Testing
After completion of software testing, project management concentrates user acceptance to collect feedback from customer site people i.e. end users. There are two kinds of acceptance testing which are alpha testing and beta testing
Alpha Testing:
Alpha Testing:
- Is suitable for software application
- Is conducted by real customer site people
- Is performed in the same organisation
Beta Testing:
- Is suitable for software products
- Is conducted by modal customers
- Is performed in modal customer site
Compliance Testing
In this testing , testing team performs testing software under test with respect to their company standards. Such type of testing is known as compliance testing or standards testing. For example:
ISO (International Standard Organisation)
CMM (Capability Maturity Model)
SIX SIGMA
ISO (International Standard Organisation)
CMM (Capability Maturity Model)
SIX SIGMA
 |
| Compliance Testing |
Parallel Testing or Competitive Testing
In this testing, testing team compare software under test(SUT) with similar products in market or with previous version of SUT in order to identify weaknesses and strengths. This testing is also called as comparison testing. This testing is applicable for software products only.
 |
| Competitive testing or comparison testing |
Multilanguity Testing
During this test, testing team validate software under test by entering inputs in various languages when software is developed in JAVA UNICODE
Learn about-
 |
| Multilanguity Testing |
Learn about-
- Parallel Testing or Competitive Testing
- Acceptance Testing
- Release Testing or Port Testing
- Maintenance or Support
- Review Techniques
Performance Testing
Performance means speed in processing of a software. In order to customer side people/client, companies try to improve speed of a software. This testing can be categorized into following parts:
- Load
- Stress
- Spike
- Endurance
1. Load Testing- The execution of a software under test under customer expected configuration and customer expected load (number of concurrent users) to estimate speed in processing is known as load testing.
2. Stress Testing- The execution of a software under test under customer expected configuration and more than customer expected load (number of concurrent users) to estimate peak load is known as stress testing.
3. Spike Testing- The execution of a software under test under customer expected configuration and unexpected heavy load (number of concurrent users) to estimate reliability is known as spike testing or soak testing.
4. Endurance Testing- The execution of a software under test under customer expected configuration and more customer expected continuous load (number of concurrent users) to find out the memory leakages is known as stress testing or durability testing.
The combination of above four testing topics are costly to conduct but mandatory for multi user softwares.
Non-Functional Testing
After successful completion of functional testing, testing team concentrate on non-functional/structural testing to validate characteristics or attributes of software under test like usability (easy to use), compatibility (running on various platforms/operating systems), performance (speed), security etc.
(a) Usability Testing: During this kind of testing, testers validate software under test screens in some factors like look and feel, ease of use, short navigation etc.
(b) Compatibility Testing: This testing is also called as portability testing. In this testing, the testing team validate software under test to configure that it runs on various platforms or not. Here platform means operating system, browsers and other system software.
(c) Configuration Testing/ Hardware Compatibility Testing: During this test, testing team validate software under test to confirm that whether it supports different technology hardware or not. for example printers, fax , networks etc.
(d) Inter system testing: In this , the testing team validate software under test to confirm whether it shares the resources of another software or not.
the above system is also known as 'End to End Testing' or web services testing or service oriented application testing
(e) Data Volume Testing: During this test, testing team calculate the capacity of database in software under testing. This testing is also called as capacity testing or memory testing. In this testing, testers insert sample data to database of software under test until database violation error (with respect to database overflow) occurs.
(e) Performance Testing
(f) Multilanguity Testing or Foreign Language Testing
(g) Competitive testing, comparison testing, parallel testing
(h) Compliance Testing
(a) Usability Testing: During this kind of testing, testers validate software under test screens in some factors like look and feel, ease of use, short navigation etc.
(b) Compatibility Testing: This testing is also called as portability testing. In this testing, the testing team validate software under test to configure that it runs on various platforms or not. Here platform means operating system, browsers and other system software.
(c) Configuration Testing/ Hardware Compatibility Testing: During this test, testing team validate software under test to confirm that whether it supports different technology hardware or not. for example printers, fax , networks etc.
(d) Inter system testing: In this , the testing team validate software under test to confirm whether it shares the resources of another software or not.
 |
| Inter system Testing |
(e) Data Volume Testing: During this test, testing team calculate the capacity of database in software under testing. This testing is also called as capacity testing or memory testing. In this testing, testers insert sample data to database of software under test until database violation error (with respect to database overflow) occurs.
 |
| Data Volume Testing |
(e) Performance Testing
(f) Multilanguity Testing or Foreign Language Testing
(g) Competitive testing, comparison testing, parallel testing
(h) Compliance Testing
System Testing or Software Testing
When software is ready after Integration Testing, a separate testing team concentrate on software testing with respect to customer's requirement and expectations.
Functional Testing:
Testing team validates a software with respect to customer's requirements. During this test testing team applies below sub tests on a software-
 |
| Software Testing or System Testing |
Functional Testing:
Testing team validates a software with respect to customer's requirements. During this test testing team applies below sub tests on a software-
- Behavioral Testing
- Error Handling Coverage/Testing
- Input Domain Testing
- Output Testing/Manipulations Testing
- Database Testing
(a) Behavioral Testing- This testing is also called as control flow testing or control structure testing. During this testing, testers validates correctness of flow in screens of SUT (Sofware Under Test) for example: Top to bottom and bottom to top.
(b) Error Handling Coverage/ Testing- During this test testers validate Software under test by operating in a wrong way. In this testing, testers test the appearance of error messages/ alert messages.
(c) Input Domain Testing- In this testing , testers validate the size and type of the inputs in the software under test.
(d) Output Testing/ Manipulation Testing- In this testing, testers validate the correctness of output/outcome in software under test.
(e) Database Testing- This testing is also called as Back-end Testing. During this test, testing team validate the correctness of the front-end operation's impact on back-end data base in terms of data validation and data integrity. Correctness of the new data insertion is called as 'Data Validation' and the correctness of the changes in the existing data is called as data integrity.
In the above functional testing, the initial four types are categorized as 'Front-end' Testing whereas the last one is categorized as Back-end testing.
Learn Next- Non-Functional Testing
Learn Next- Non-Functional Testing
Integration Testing
Integration Testing is also called as 'Interface Testing'. After writing the code and finishing the unit testing (of the different - different modules), programmers focus on interconnection of those programs (modules).
In order to integrate the programs/modules the programmers use one of the following methods/approaches:
The integration of the main module with some of the sub- modules is called as top down approach. In the place of under constructive sub modules, programmers use temporary programs which is called as 'stubs'.
Bottom Up Approach:
The Integration of sub-modules without interconnecting with main module is called as Bottom Up approach. In the place of under constructive main module programmers use a temporary program which is called as calling 'driver' or 'calling' program.
Hybrid Approach:
This approach is also called as 'Sand witch' approach. The combination of top down and bottom up approach is called as hybrid approach.
System Approach or Big Bang Approach:
In this approach Integration Testing starts only after the 100% completion of the coding. This the only reason that in this approach stubs or drivers are not required.
Learn Next- System Testing or Software Testing
 |
| Integration Testing |
- Top Down Approach
- Bottom Up Approach
- Hybrid Approach
- System Approach or Big Bang Approach
The integration of the main module with some of the sub- modules is called as top down approach. In the place of under constructive sub modules, programmers use temporary programs which is called as 'stubs'.
 |
| Top Down Approach |
Bottom Up Approach:
 |
| Bottom Up Approach |
Hybrid Approach:
This approach is also called as 'Sand witch' approach. The combination of top down and bottom up approach is called as hybrid approach.
 |
| Hybrid Approach |
System Approach or Big Bang Approach:
In this approach Integration Testing starts only after the 100% completion of the coding. This the only reason that in this approach stubs or drivers are not required.
Learn Next- System Testing or Software Testing
Unit Testing
After coding, programmers check/validate completeness and correctness of the program which is called as unit testing or open box or clear box testing techniques. It includes following points:
- Program Working
- Program Correctly Working
- Program Fastness
Unit Testing is categorized into the following parts:
- Basic Path Coverage
- Control Structure
- Program Technique Coverage
- Mutation Coverage
Basic Path Coverage:
In this technique, programmer runs the program more than one time to cover run time errors and syntax errors in all areas of programs. To find the number of paths in a program we can follow 'Cyclomatic Complexity' like if number of paths is 6 then we have to run the program for 6 times to cover all areas of code in a program.
Control Structure Coverage:
After confirmation of the program execution (i.e. program is running without throwing any run time error or syntax error), then programmers concentrate on correctness of input(s) and output(s) of that program. like debugging the code (i.e. running the program line by line)
Program Technique Coverage:
In this technique, programmers calculates the execution speed of the program. If the programmer finds the execution time as unacceptable then he/she may change the program structure without disturbing the functionality.
Mutation Coverage:
After completion of program technique coverage, programmers check the correctness of testing on that program by performing changes in different areas of that program. Here mutation means 'Change in a program'
Subscribe to:
Posts (Atom)