INTERVIEW QUESTIONS TESTING SOFTWARE DEVELOPMENT LIFE CYCLE DETAILS

Question: What is Diff. between STLC and SDLC?

Answer: Software Development Life Cycle (SDLC): It consists of 4 phases <br>i)Requirements Analysis<br>ii) System Design<br>iii)Implementation<br>iv) Testing<br>i)Requirements Analysis:- In this the customers of the system provide the business requirements for the system. It is the analysts job to extract these requirements from the system and document them with sufficient clarity that the team know what to build to meet the customer needs. Analysts will do the feasibility of the requirements and put it on FDD. <br>ii) System Design:- The architecture and details of how the system will work are created. These are documented by technical architects who produce documents such as UML diagrams. <br>iii) Implementation:- The actual coding of the solution happens in this stage. <br>iv)Testing:- Finally testing happens.<br>The delivered code is tested against the requirements documents to ensure that the system being delivered meets the needs of the customer <br>Software Testing Life Cycle (SDLC): It consists of 4 phases<br>i) Requirements Analysis<br>ii)System Design<br>iii)Implementation<br>iv)Testing<br>i)Requirements Analysis:- Testing begins with the verification of “requirements” documents. Testers need to analyse the requirements documents to ensure that they know exactly what the requirement is and that everyone has the same understanding. Removing ambiguity at this stage will remove bugs from later stages.A commonly used checklist for verifying requirements consists of the following: <br>• Correct Simply put, does the requirement correctly reflect what the user wants?<br>• Complete Ensure no elements are missing from the requirement, does the requirement describe all possible values, what about performance/security/accessibility aspects of a requirement?<br>• Consistent Checking that there are no contradictions within the requirements.<br>• Feasable Can the requirement be delivered given the technology, time and budget constraints.<br>• Testable Is the expected result known and can it be programatically or visually verified? Words like ‘maximise’ or ‘adequate’ can not be verified and should not be used in requirements.<br>• Traceable Is it clear which part of the system this requirement applies to, if it applies to more than one area is this clear?<br>• Unambiguous Look for ambiguous words like ’should’ ‘can’ ‘etc.’ ‘usually’ ‘and/or’ ‘quick’ <br>ii) System Design:-Once the System Design and Requirements are available they can be used to for Test Cases. Each Test Case has a Test Condition and procedure and an expected outcome. During this phase Testers, Designers and Developers should be working together to ensure that everyone understands the solution and the possible risks and weaknesses of the solution. Developers should be thinking about the unit tests they need to perform against the units they are developing, this includes the identification of any stubs or test harnesses that may be needed. Testers can use some of the Test Case Design Techniques to help them identify test cases that should be created. <br>iii)Implementation / Development:- During the development of the solution “unit tests” are executed against each of the units being developed.This is the first oppurtunity to test the application. <br>iv)Testing:- It consists of 3 types<br>a)Integration Testing:- consists of checking the data flow between two or more integrated modules<br>b) Exploratory Testing:-is the simultaneous learning, creating and executing of test cases. In traditional methods the learning and test case creation is done ahead of time working from functional requirements. <br>c) Functional Testing :-is the process of testing a system to verify that it meets the functional requirements.<br>d) Load Testing:- is to check the system under expected load condition i.e How system behaves when ‘concurrent users’ accessing the same application. Testing an application under ‘heavy loads’, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails. <br>e) Performance Testing:- will make sure that product does not take up the much of the system resource and ‘time taken to execute’ the task. Imagine the reaction of the user if save operation takes up more than 5 minutes.and also testing will check that response time is meets the user requirement. There are no industry wide standard response time for web applications although there are some interesting writings on the matter. <br>v)Reliability Testing:- is testing the ability of a system, to handle ‘negative flow’ or ’situations’E.x for example, if printer is not connected to your Application and if you have given Print Command The AUT Should not hang waiting for response from Printer Machine, it should have the facility to give error message and the system should recover to normal functionality. It is also known as recovery testing.vi) Regression Testing:- Regression testing can be defined as the retesting of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made. The principle is that given a tested system and a new version of that system with some change made, a subset of the tests may be sufficient to restore the “tested” status of the system. The value of separating out regression testing as a separate concept from simply re-testing the system completely is that when testing costs are high, being able to get the same verification from less testing is desirable. If the cost of a full system test is low, simply re-testing the system when changes are made is probably the best strategy. The extra work that has to be done to execute a regression test is determining the subset of the full system test required to bring the system back to “tested” status. It is possible, if the changes to the system are extensive enough, that the regression test will in fact be the same as the full system test. A regression test suite is created from selected test cases and scripts. Where possible regression testing should be automated to reduce the time taken to repeat these tests, in some cases the additional time required to automate the tests will outweigh the benefits <br>

Software Development Life Cycle (SDLC): It consists of 4 phases <br>i)Requirements Analysis<br>ii) System Design<br>iii)Implementation<br>iv) Testing<br>i)Requirements Analysis:- In this the customers of the system provide the business requirements for the system. It is the analysts job to extract these requirements from the system and document them with sufficient clarity that the team know what to build to meet the customer needs. Analysts will do the feasibility of the requirements and put it on FDD. <br>ii) System Design:- The architecture and details of how the system will work are created. These are documented by technical architects who produce documents such as UML diagrams. <br>iii) Implementation:- The actual coding of the solution happens in this stage. <br>iv)Testing:- Finally testing happens.<br>The delivered code is tested against the requirements documents to ensure that the system being delivered meets the needs of the customer <br>Software Testing Life Cycle (SDLC): It consists of 4 phases<br>i) Requirements Analysis<br>ii)System Design<br>iii)Implementation<br>iv)Testing<br>i)Requirements Analysis:- Testing begins with the verification of “requirements” documents. Testers need to analyse the requirements documents to ensure that they know exactly what the requirement is and that everyone has the same understanding. Removing ambiguity at this stage will remove bugs from later stages.A commonly used checklist for verifying requirements consists of the following: <br>• Correct Simply put, does the requirement correctly reflect what the user wants?<br>• Complete Ensure no elements are missing from the requirement, does the requirement describe all possible values, what about performance/security/accessibility aspects of a requirement?<br>• Consistent Checking that there are no contradictions within the requirements.<br>• Feasable Can the requirement be delivered given the technology, time and budget constraints.<br>• Testable Is the expected result known and can it be programatically or visually verified? Words like ‘maximise’ or ‘adequate’ can not be verified and should not be used in requirements.<br>• Traceable Is it clear which part of the system this requirement applies to, if it applies to more than one area is this clear?<br>• Unambiguous Look for ambiguous words like ’should’ ‘can’ ‘etc.’ ‘usually’ ‘and/or’ ‘quick’ <br>ii) System Design:-Once the System Design and Requirements are available they can be used to for Test Cases. Each Test Case has a Test Condition and procedure and an expected outcome. During this phase Testers, Designers and Developers should be working together to ensure that everyone understands the solution and the possible risks and weaknesses of the solution. Developers should be thinking about the unit tests they need to perform against the units they are developing, this includes the identification of any stubs or test harnesses that may be needed. Testers can use some of the Test Case Design Techniques to help them identify test cases that should be created. <br>iii)Implementation / Development:- During the development of the solution “unit tests” are executed against each of the units being developed.This is the first oppurtunity to test the application. <br>iv)Testing:- It consists of 3 types<br>a)Integration Testing:- consists of checking the data flow between two or more integrated modules<br>b) Exploratory Testing:-is the simultaneous learning, creating and executing of test cases. In traditional methods the learning and test case creation is done ahead of time working from functional requirements. <br>c) Functional Testing :-is the process of testing a system to verify that it meets the functional requirements.<br>d) Load Testing:- is to check the system under expected load condition i.e How system behaves when ‘concurrent users’ accessing the same application. Testing an application under ‘heavy loads’, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails. <br>e) Performance Testing:- will make sure that product does not take up the much of the system resource and ‘time taken to execute’ the task. Imagine the reaction of the user if save operation takes up more than 5 minutes.and also testing will check that response time is meets the user requirement. There are no industry wide standard response time for web applications although there are some interesting writings on the matter. <br>v)Reliability Testing:- is testing the ability of a system, to handle ‘negative flow’ or ’situations’E.x for example, if printer is not connected to your Application and if you have given Print Command The AUT Should not hang waiting for response from Printer Machine, it should have the facility to give error message and the system should recover to normal functionality. It is also known as recovery testing.vi) Regression Testing:- Regression testing can be defined as the retesting of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made. The principle is that given a tested system and a new version of that system with some change made, a subset of the tests may be sufficient to restore the “tested” status of the system. The value of separating out regression testing as a separate concept from simply re-testing the system completely is that when testing costs are high, being able to get the same verification from less testing is desirable. If the cost of a full system test is low, simply re-testing the system when changes are made is probably the best strategy. The extra work that has to be done to execute a regression test is determining the subset of the full system test required to bring the system back to “tested” status. It is possible, if the changes to the system are extensive enough, that the regression test will in fact be the same as the full system test. A regression test suite is created from selected test cases and scripts. Where possible regression testing should be automated to reduce the time taken to repeat these tests, in some cases the additional time required to automate the tests will outweigh the benefits <br> Source: CoolInterview.com

If you have the better answer, then send it to us. We will display your answer after the approval.

Rules to Post Answers in CoolInterview.com:-

• There should not be any Spelling Mistakes.
• There should not be any Gramatical Errors.
• Answers must not contain any bad words.
• Answers should not be the repeat of same answer, already approved.
• Answer should be complete in itself.

Name :*
Email Id :*
Answer :*
Verification Code	Not readable? Load New Code
Enter the above shown code: *
	Inform me about updated answers to this question