Smoke Testing: Software Testing done to ensure that whether the build can be accepted for through software testing or not. Basically, it is done to check the stability of the build received for software testing.
In computer programming and software testing, smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. In this case, the smoke is metaphorical.
Smoke testing is done by developers before the build is released to the testers, or by testers before accepting a build for further testing. Microsoft claims[1] that after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.
n software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.
In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a "shallow and wide" approach to the application. The tester "touches" all areas of the application without getting too deep, looking for answers to basic questions like, "Can I launch the test item at all?", "Does it open to a window?", "Do the buttons on the window do things?".
The purpose is to determine whether or not the application is so badly broken that testing functionality in a more detailed way is unnecessary. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.
Sanity testing: After receiving a build with minor changes in the code or functionality, a subset of regression test cases are executed that to check whether it rectified the software bugs or issues and no other software bug is introduced by the changes. Sometimes, when multiple cycles of regression testing are executed, sanity testing of the software can be done at later cycles after through regression test cycles. If we are moving a build from staging / testing server to production server, sanity testing of the software application can be done to check that whether the build is sane enough to move to further at production server or not.
In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that the system or methodology works as expected, often prior to a more exhaustive round of testing.
In software development, the sanity test (a form of software testing which offers "quick, broad, and shallow testing"[1]) determines whether it is reasonable to proceed with further testing.
Software sanity tests are commonly conflated with smoke tests.A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable.
A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test. In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests and unit tests on an automated build as part of their development process.
The Hello world program is often used as a sanity test for a development environment. If Hello World fails to compile or execute, the supporting environment likely has a configuration problem. If it works, the problem being diagnosed likely lies in the real application being diagnosed.
Difference between Smoke & Sanity Software Testing:
* Smoke testing is a wide approach where all areas of the software application are tested without getting into too deep. However, a sanity software testing is a narrow regression testing with a focus on one or a small set of areas of functionality of the software application.
* The test cases for smoke testing of the software can be either manual or automated. However, a sanity test is generally without test scripts or test cases.
* Smoke testing is done to ensure whether the main functions of the software application are working or not. During smoke testing of the software, we do not go into finer details. However, sanity testing is a cursory software testing type. It is done whenever a quick round of software testing can prove that the software application is functioning according to business / functional requirements.
* Smoke testing of the software application is done to check whether the build can be accepted for through software testing. Sanity testing of the software is to ensure whether the requirements are met or not.
Wednesday, March 30, 2011
Wednesday, January 12, 2011
The Most Significant Changes in HP Quality Center 10
The Most Significant Changes
The new QC Version 10 has seen a series of changes, of which the most significant ones are:
• Version control
• Baselining
• Integrated dashboard
• Shared libraries
• Cross Project Customization
Version Control
Finally, QC has been provided with a fully integrated version control. In past versions, one had to make do with third-party integration, which generally stumbled rather than ran. The version control, if desired, must first be activated for every individual project via the SiteAdmin. Once this is done, all entities falling under the version control become Version 1. QC entities include requirements, tests, test resources, and business components. If one wishes to add a test step to a test case for example, one is automatically requested to check this test case. As soon as there is more than one version of an entity, one can compare various versions against each other or retrieve an older version.
Summary: The whole thing is intuitive and easy to operate. But what’s the use of having eight versions of a requirement, when one doesn’t know which software release a version belongs to?
Baselining
Along with version control comes baselining, which is intended to answer the question above. Using the new “Management” module that replaces the “Releases” introduced in 9.x one gets to the baseline function via the “Libraries” tab. This enables one to obtain a summary of a complete testing release and retrieve it if necessary. In this way, a test set can be pinned to a baseline in the test lab. In other words, as of now, the manual copying of entire trees into the test plan module is a thing of the past. At last, test managers will be able to properly organize software that has multiple parallel releases (in production, current release, future release).
Summary: Setting up the baseline works very well. While creating it, a log keeps one updated on what is currently taking place. However, setting up baselines probably needs to be done during off-peak hours since it can take a while for larger QC projects.
Integrated Dashboard
Equally interesting for test managers is the new integrated dashboard that can be found on the left-hand navigation bar where the “Management” module is, too. The special feature of the new dashboard does not pertain to the graphics, which are not particularly appealing, but the “Cross-Project” functionality. It is now finally possible, when working on a QC project, to get an overview of all of one’s ongoing projects. These dashboards are freely configurable and can be designated to be personal favorites or publicly accessible. Special Excel reports also enable direct access to the database via SQL. The generated reports can then be graphically processed at the same time by means of VBScript.
Summary: The new dashboard module is quickly customized and achieves its purpose in ongoing projects. What is missing is a sensible way of printing content for a given project meeting, for example.
Shared Libraries
Libraries, which are located in the “Management” module, can be re-used and distributed with Version 10. A library represents a collection of entities in a QC project, including their relationships to each other. When dealing with many similar projects, it offers the advantage of not having to repeatedly create entities. Libraries can be imported from project A into project B, compared against each other, or even synchronized. A library also allows one to collect the same entities as in versioning. Defects are not included, but they can be shared with the new “HP Quality Center Synchronizer” manually among several QC projects. As mentioned, the advantages really only present themselves when one has many and/or large-scale projects. I suppose that is why this functionality is available only in the QC Premier Edition (also available are the Standard and Enterprise editions).
Summary: It remains to be seen whether this function will actually be used in real-world applications. In my opinion, it makes perfect sense to be able to take over pre-defined assets from another project so that one doesn’t have to keep re-inventing the wheel.
Cross Project Customization
And now here’s the last big change: Cross Project Customization. Many organizations have defined standards, such as a uniform defect status field or a standardized priority scale, for their software quality-related areas. However, these fields and lists were often changed or even deleted by QC project administrators. Some companies have even gone to great lengths in using their own programming to define a template that can be distributed to all QC projects, thereby establishing a uniform standard.
For all those who want to spare themselves this time and effort or do not wish to keep an in-house programmed interface going, there is a solution. Site Administrator now provides a way to link projects with a template. If the template is changed, the delta can then be passed on later at the right point in time. This function has been awaited not only by test managers who like to have the same configuration in all their projects, but especially also by the respective operators of QC installations, namely the system administrators. Cross Project Customization is also only available in the Premier Edition.
Summary: This change is awesome! Finally, testing organizations or Test Factory managers are able to implement a certain basic standard in their projects. Once this is accomplished, nothing can get in the way of standardized, across-the-board reporting.
Is an Upgrade Worth It?
The new Version 10 is an absolute milestone not only for tests managers. It also makes life easier for testers, Test Factory managers, as well as QC system administrators. The new functions have been anticipated for quite some time and have been implemented in the new product in a well-conceived manner.
The new QC Version 10 has seen a series of changes, of which the most significant ones are:
• Version control
• Baselining
• Integrated dashboard
• Shared libraries
• Cross Project Customization
Version Control
Finally, QC has been provided with a fully integrated version control. In past versions, one had to make do with third-party integration, which generally stumbled rather than ran. The version control, if desired, must first be activated for every individual project via the SiteAdmin. Once this is done, all entities falling under the version control become Version 1. QC entities include requirements, tests, test resources, and business components. If one wishes to add a test step to a test case for example, one is automatically requested to check this test case. As soon as there is more than one version of an entity, one can compare various versions against each other or retrieve an older version.
Summary: The whole thing is intuitive and easy to operate. But what’s the use of having eight versions of a requirement, when one doesn’t know which software release a version belongs to?
Baselining
Along with version control comes baselining, which is intended to answer the question above. Using the new “Management” module that replaces the “Releases” introduced in 9.x one gets to the baseline function via the “Libraries” tab. This enables one to obtain a summary of a complete testing release and retrieve it if necessary. In this way, a test set can be pinned to a baseline in the test lab. In other words, as of now, the manual copying of entire trees into the test plan module is a thing of the past. At last, test managers will be able to properly organize software that has multiple parallel releases (in production, current release, future release).
Summary: Setting up the baseline works very well. While creating it, a log keeps one updated on what is currently taking place. However, setting up baselines probably needs to be done during off-peak hours since it can take a while for larger QC projects.
Integrated Dashboard
Equally interesting for test managers is the new integrated dashboard that can be found on the left-hand navigation bar where the “Management” module is, too. The special feature of the new dashboard does not pertain to the graphics, which are not particularly appealing, but the “Cross-Project” functionality. It is now finally possible, when working on a QC project, to get an overview of all of one’s ongoing projects. These dashboards are freely configurable and can be designated to be personal favorites or publicly accessible. Special Excel reports also enable direct access to the database via SQL. The generated reports can then be graphically processed at the same time by means of VBScript.
Summary: The new dashboard module is quickly customized and achieves its purpose in ongoing projects. What is missing is a sensible way of printing content for a given project meeting, for example.
Shared Libraries
Libraries, which are located in the “Management” module, can be re-used and distributed with Version 10. A library represents a collection of entities in a QC project, including their relationships to each other. When dealing with many similar projects, it offers the advantage of not having to repeatedly create entities. Libraries can be imported from project A into project B, compared against each other, or even synchronized. A library also allows one to collect the same entities as in versioning. Defects are not included, but they can be shared with the new “HP Quality Center Synchronizer” manually among several QC projects. As mentioned, the advantages really only present themselves when one has many and/or large-scale projects. I suppose that is why this functionality is available only in the QC Premier Edition (also available are the Standard and Enterprise editions).
Summary: It remains to be seen whether this function will actually be used in real-world applications. In my opinion, it makes perfect sense to be able to take over pre-defined assets from another project so that one doesn’t have to keep re-inventing the wheel.
Cross Project Customization
And now here’s the last big change: Cross Project Customization. Many organizations have defined standards, such as a uniform defect status field or a standardized priority scale, for their software quality-related areas. However, these fields and lists were often changed or even deleted by QC project administrators. Some companies have even gone to great lengths in using their own programming to define a template that can be distributed to all QC projects, thereby establishing a uniform standard.
For all those who want to spare themselves this time and effort or do not wish to keep an in-house programmed interface going, there is a solution. Site Administrator now provides a way to link projects with a template. If the template is changed, the delta can then be passed on later at the right point in time. This function has been awaited not only by test managers who like to have the same configuration in all their projects, but especially also by the respective operators of QC installations, namely the system administrators. Cross Project Customization is also only available in the Premier Edition.
Summary: This change is awesome! Finally, testing organizations or Test Factory managers are able to implement a certain basic standard in their projects. Once this is accomplished, nothing can get in the way of standardized, across-the-board reporting.
Is an Upgrade Worth It?
The new Version 10 is an absolute milestone not only for tests managers. It also makes life easier for testers, Test Factory managers, as well as QC system administrators. The new functions have been anticipated for quite some time and have been implemented in the new product in a well-conceived manner.
Monday, October 25, 2010
Reliability Testing
Definition:
Reliability tests are designed to confirm whether the software will work in the expected environment for an acceptable amount of time without degradation. It is quite difficult to perform reliability testing effectively and generally it becomes more & more difficult due to the lack of clear requirements.
What is the meaning of Reliability?
First of all let us understand the meaning of reliability; reason being, reliability is generally less understood as compared to other quality attributes like functionality, performance, and security.
Reliability describes the ability of the software product to perform its required functions under stated conditions for a specified period of time or for a specified number of operations. Thus while talking about reliability, we consider following two important factors
1) "Doing what?" (Stated conditions)
2) "For how long?" (Time or operations)
Reliability is measured by a specific failure intensity metric, like the mean time between failures (MTBF). Software that fails on average once a week is considered less reliable than software that fails once a month. We need to differentiate between the severity of those failures and the conditions under which the software was operating (the "doing what?" element of the reliability definition).
How can we increase the Software Reliability?
Software reliability can be improved by programming practices that "catch" error conditions as they occur and handle them in a defined manner.
E.g. generate an error message, do some alternative action, use default values if calculated values are found to be incorrect in some way.
This ability of the software to maintain a specified level of performance and not to break when a failure or an unexpected event takes place is called "Fault Tolerance". We can use the word "Robustness" also for this.
An important aspect of reliability refers to the ability of software to reestablish a specified level of performance and recover any data directly affected by the failure.
The "Recoverability" of software can be considered by following two aspects:
1) Fail-over capability: This refers to the ability to maintain continuous system operations even in the event of failure. In this case, the re-establishing of a specified level of performance may actually take place seamlessly and without getting noticed by the end users.
2) Restore capability: This refers to the ability to minimize the effects of a failure on the system's data. If the recovery is required to take place as a result of some catastrophic event like fire or earthquake etc. we call it "Disaster Recovery".
While considering the recoverability aspects of reliability, we need to provide due consideration to the impact of a failure or disruption:
1) The criticality of system failures
2) The consequences of interruptions in normal operations (whether planned or not)
3) The implications of any data losses resulting from failures
What are the activities of Reliability Test Planning?
Test planning focuses on all the reliability attributes & performing following primary activities:
1) Assessment of risks associated with reliability
2) Definition of an appropriate testing approach to address those risks
3) Setting reliability goals
4) Scheduling the tests
Reliability tests are designed to confirm whether the software will work in the expected environment for an acceptable amount of time without degradation. It is quite difficult to perform reliability testing effectively and generally it becomes more & more difficult due to the lack of clear requirements.
What is the meaning of Reliability?
First of all let us understand the meaning of reliability; reason being, reliability is generally less understood as compared to other quality attributes like functionality, performance, and security.
Reliability describes the ability of the software product to perform its required functions under stated conditions for a specified period of time or for a specified number of operations. Thus while talking about reliability, we consider following two important factors
1) "Doing what?" (Stated conditions)
2) "For how long?" (Time or operations)
Reliability is measured by a specific failure intensity metric, like the mean time between failures (MTBF). Software that fails on average once a week is considered less reliable than software that fails once a month. We need to differentiate between the severity of those failures and the conditions under which the software was operating (the "doing what?" element of the reliability definition).
How can we increase the Software Reliability?
Software reliability can be improved by programming practices that "catch" error conditions as they occur and handle them in a defined manner.
E.g. generate an error message, do some alternative action, use default values if calculated values are found to be incorrect in some way.
This ability of the software to maintain a specified level of performance and not to break when a failure or an unexpected event takes place is called "Fault Tolerance". We can use the word "Robustness" also for this.
An important aspect of reliability refers to the ability of software to reestablish a specified level of performance and recover any data directly affected by the failure.
The "Recoverability" of software can be considered by following two aspects:
1) Fail-over capability: This refers to the ability to maintain continuous system operations even in the event of failure. In this case, the re-establishing of a specified level of performance may actually take place seamlessly and without getting noticed by the end users.
2) Restore capability: This refers to the ability to minimize the effects of a failure on the system's data. If the recovery is required to take place as a result of some catastrophic event like fire or earthquake etc. we call it "Disaster Recovery".
While considering the recoverability aspects of reliability, we need to provide due consideration to the impact of a failure or disruption:
1) The criticality of system failures
2) The consequences of interruptions in normal operations (whether planned or not)
3) The implications of any data losses resulting from failures
What are the activities of Reliability Test Planning?
Test planning focuses on all the reliability attributes & performing following primary activities:
1) Assessment of risks associated with reliability
2) Definition of an appropriate testing approach to address those risks
3) Setting reliability goals
4) Scheduling the tests
Wednesday, August 25, 2010
Most common Test case questions in Interview or Test
Test Case – 1: Test Case for ATM
1) Insertion of ATM card with success.
2) Incorrect ATM Card Insertion – Leading to unsuccessful operation. Can not accepted.
3) ATM Card of an invalid account – Leading to unsuccessful operation. Can not accepted.
4) Successful feeding of ATM PIN Number.
5) Incorrect ATM PIN Number feeding 3 times - Leading to unsuccessful operation. Block the card for whole day. Can not be operated for whole day.
6) Selection of language of operation, with success.
7) Selection of Type of Bank Account with success.
8) Incorrect Bank Account type Selection in respect to the type of ATM Card inserted - Leading to unsuccessful operation.
9) Selection of withdrawal option with success.
10) Selection of Amount to be withdrawn with success.
11) Incorrect Currency denominations - Leading to unsuccessful operation. Can not accept denomination like Rs.50, 250. Should not accept these type of denomination and ask customer to enter proper denominations.
12) Successful completion of withdrawal of money.
13) Amount to be withdrawn in excess of the available Balance - Leading to unsuccessful operation. Should not allowed it and ask for again entering correct values. Should display message like 'Entering amount is greater that available balance, please enter less than or equal to available balance.
14) Shortage of Currency Notes in ATM - Leading to unsuccessful operation. Should display message. Only some of the denomination accepted . e.g Only 500 denomination should enter.
15) Amount to be withdrawn in excess of the daily withdrawal limit - Leading to unsuccessful operation. Should display message ' Daily withdraw limit is XYZ, you should enter less than or equal to XYZ'.
16) ATM link to the Bank Server not available at the moment - Leading to unsuccessful operation.
17) Clicking of the Cancel button after inserting the ATM card - Leading to unsuccessful operation.
18) Clicking of the Cancel button after feeding the ATM PIN Number - Leading to unsuccessful operation.
19) Clicking of the Cancel button after selection of language of operation - Leading to unsuccessful operation.
20) Clicking of the Cancel button after selection of Type of Bank Account - Leading to unsuccessful operation.
21) Clicking of the Cancel button after selection of Amount of withdrawal - Leading to unsuccessful operation.
22) Clicking of the Cancel button after feeding the amount to be withdrawn - Leading to unsuccessful operation.
Test Case – 2: Test Case for a Cell Phone
1) Check the correct insertion of the Battery in the cell phone.
2) Check the proper operation of Switch ON and Switch OFF functions of the cell phone.
3) Check the correct insertion of the SIM Card in the cell phone.
4) Check the correct insertion of one contact name and phone number in the Address book.
5) Check the successful operation of the Incoming call.
6) Check the successful operation of the outgoing call.
7) Check the successful operation of sending and receiving of Short Messages.
8) Check the correct selection & display of all Numbers and special characters.
9) Check the successful deletion of contact name and phone number from the Address book.
10) Check the successful capturing of the home Network from the service provider.
11) Check the successful connectivity of the GPRS facility – if supported on the cell phone.
12) Check the successful connectivity of the EDGE facility – if supported on the cell phone.
Test Case – 3: Test Case for a Traffic Signal
1) Check the presence of three lights like Green, Yellow & Red on the traffic light post.
2) Check the switching sequence of the lights.
3) Check the defined time delay between the switching of lights of defined colors.
4) Check the possibility and accuracy of adjustment in defining the time delay between the switching of various lights depending upon the traffic density.
5) Check the switching ON of light of one color at one particular time.
6) Check the switching of lights from some type of sensor.
Test Case – 4: Test Case for an Elevator
1) Check the capability of Upward & Downward movement.
2) Check the proper stopping at each and every floor.
3) Check the stoppage exactly at the floor whose corresponding number is pressed.
4) Check the automatic upward movement when called by someone from some floor at higher level.
5) Check the automatic downward movement when called by someone from some floor at lower level.
5) Check the proper functioning of the wait function till Close button is pressed.
6) Check the automatic opening of the door in the event of someone trying to step in while the closing of the door is in progress.
7) Check the motion of the elevator without any jerks.
8) Check the load limit prescribed for the elevator – Warn if load limit exceeds.
9) Check the presence & proper functioning of auto descent facility in case of power failure.
10) Check the presence & proper functioning of the communication system in case of power failure.
11) Check the presence & proper functioning of the ventilation system provided.
12) Check the presence & proper functioning of the fire fighting system in case of emergency
1) Insertion of ATM card with success.
2) Incorrect ATM Card Insertion – Leading to unsuccessful operation. Can not accepted.
3) ATM Card of an invalid account – Leading to unsuccessful operation. Can not accepted.
4) Successful feeding of ATM PIN Number.
5) Incorrect ATM PIN Number feeding 3 times - Leading to unsuccessful operation. Block the card for whole day. Can not be operated for whole day.
6) Selection of language of operation, with success.
7) Selection of Type of Bank Account with success.
8) Incorrect Bank Account type Selection in respect to the type of ATM Card inserted - Leading to unsuccessful operation.
9) Selection of withdrawal option with success.
10) Selection of Amount to be withdrawn with success.
11) Incorrect Currency denominations - Leading to unsuccessful operation. Can not accept denomination like Rs.50, 250. Should not accept these type of denomination and ask customer to enter proper denominations.
12) Successful completion of withdrawal of money.
13) Amount to be withdrawn in excess of the available Balance - Leading to unsuccessful operation. Should not allowed it and ask for again entering correct values. Should display message like 'Entering amount is greater that available balance, please enter less than or equal to available balance.
14) Shortage of Currency Notes in ATM - Leading to unsuccessful operation. Should display message. Only some of the denomination accepted . e.g Only 500 denomination should enter.
15) Amount to be withdrawn in excess of the daily withdrawal limit - Leading to unsuccessful operation. Should display message ' Daily withdraw limit is XYZ, you should enter less than or equal to XYZ'.
16) ATM link to the Bank Server not available at the moment - Leading to unsuccessful operation.
17) Clicking of the Cancel button after inserting the ATM card - Leading to unsuccessful operation.
18) Clicking of the Cancel button after feeding the ATM PIN Number - Leading to unsuccessful operation.
19) Clicking of the Cancel button after selection of language of operation - Leading to unsuccessful operation.
20) Clicking of the Cancel button after selection of Type of Bank Account - Leading to unsuccessful operation.
21) Clicking of the Cancel button after selection of Amount of withdrawal - Leading to unsuccessful operation.
22) Clicking of the Cancel button after feeding the amount to be withdrawn - Leading to unsuccessful operation.
Test Case – 2: Test Case for a Cell Phone
1) Check the correct insertion of the Battery in the cell phone.
2) Check the proper operation of Switch ON and Switch OFF functions of the cell phone.
3) Check the correct insertion of the SIM Card in the cell phone.
4) Check the correct insertion of one contact name and phone number in the Address book.
5) Check the successful operation of the Incoming call.
6) Check the successful operation of the outgoing call.
7) Check the successful operation of sending and receiving of Short Messages.
8) Check the correct selection & display of all Numbers and special characters.
9) Check the successful deletion of contact name and phone number from the Address book.
10) Check the successful capturing of the home Network from the service provider.
11) Check the successful connectivity of the GPRS facility – if supported on the cell phone.
12) Check the successful connectivity of the EDGE facility – if supported on the cell phone.
Test Case – 3: Test Case for a Traffic Signal
1) Check the presence of three lights like Green, Yellow & Red on the traffic light post.
2) Check the switching sequence of the lights.
3) Check the defined time delay between the switching of lights of defined colors.
4) Check the possibility and accuracy of adjustment in defining the time delay between the switching of various lights depending upon the traffic density.
5) Check the switching ON of light of one color at one particular time.
6) Check the switching of lights from some type of sensor.
Test Case – 4: Test Case for an Elevator
1) Check the capability of Upward & Downward movement.
2) Check the proper stopping at each and every floor.
3) Check the stoppage exactly at the floor whose corresponding number is pressed.
4) Check the automatic upward movement when called by someone from some floor at higher level.
5) Check the automatic downward movement when called by someone from some floor at lower level.
5) Check the proper functioning of the wait function till Close button is pressed.
6) Check the automatic opening of the door in the event of someone trying to step in while the closing of the door is in progress.
7) Check the motion of the elevator without any jerks.
8) Check the load limit prescribed for the elevator – Warn if load limit exceeds.
9) Check the presence & proper functioning of auto descent facility in case of power failure.
10) Check the presence & proper functioning of the communication system in case of power failure.
11) Check the presence & proper functioning of the ventilation system provided.
12) Check the presence & proper functioning of the fire fighting system in case of emergency
When to stop Testing
Many of testers no All the testers came across this question during in interview. And all of us know that the testing never complete but it stops at particular stage. This never show that system is bug free but it ensure that the system can work efficiently now on this stage.
There are many criteria s or assumption on which it stop.
* Stop the testing when the committed / planned testing deadlines are about to expire.
* Stop the testing when we are not able to detect any more errors even after execution of all the planned test Cases.
We can see that both the above statements do not carry any meaning and are contradictory since we can satisfy the first statement even by doing nothing while the second statement is equally meaningless since it can not ensure the quality of our test cases.
Pin pointing the time - when to stop testing is difficult. Many modern software applications are so complex and run in such an Interdependent environment, that complete testing can never be done.
Most common factors helpful in deciding when to stop the testing are:
* Stop the Testing when deadlines like release deadlines or testing deadlines have reached
* Stop the Testing when the test cases have been completed with some prescribed pass percentage.
* Stop the Testing when the testing budget comes to its end.
* Stop the Testing when the code coverage and functionality requirements come to a desired level.
* Stop the Testing when bug rate drops below a prescribed level
* Stop the Testing when the period of beta testing / alpha testing gets over.
Keeping a Track on the Progress of Testing:
Testing metrics can help the testers to take better and accurate decisions; like when to stop testing or when the application is ready for release, how to track testing progress & how to measure the quality of a product at a certain point in the testing cycle.
The best way is to have a fixed number of test cases ready well before the beginning of test execution cycle. Subsequently measure the testing progress by recording the total number of test cases executed using the following metrics which are quite helpful in measuring the quality of the software product
1) Percentage Completion: (Number of executed test cases) / (Total number of test cases)
2) Percentage Test cases Passed: Defined as (Number of passed test cases) / (Number of executed test cases)
3) Percentage Test cases Failed: Defined as (Number of failed test cases) / (Number of executed test cases)
A test case is declared - Failed even when just one bug is found while executing it, otherwise it is considered as - Passed
Scientific Methods to decide when to stop testing:
1) Decision based upon Number of Pass / Fail test Cases:
a) Preparation of predefined number of test cases ready before test execution cycle.
b) Execution of all test cases In every testing cycle.
c) Stopping the testing process when all the test cases get Passed
d) Alternatively testing can be stopped when percentage of failure in the last testing cycle is observed to be extremely low.
2) Decision based upon Metrics:
a) Mean Time Between Failure (MTBF): by recording the average operational time before the system failure.
b) Coverage metrics: by recording the percentage of instructions executed during tests.
c) Defect density: by recording the defects related to size of software like "defects per 1000 lines of code" or the number of open bugs and their severity levels.
Finally How to Decide:
Stop the testing, If:
1) Coverage of the code is good
2) Mean time between failure is quite large
3) Defect density is very low
4) Number of high severity Open Bugs is very low.
Here 'Good', 'Large', 'Low' and 'High' are subjective terms and depend on the type of product being tested. Ultimately, the risk associated with moving the application into production, as well as the risk of not moving forward, must be taken into consideration.
Broad / Universal statement to define the time to stop testing is when:
All the test cases, derived from equivalent partitioning, cause-effect analysis & boundary-value analysis are executed without detecting errors.
There are many criteria s or assumption on which it stop.
* Stop the testing when the committed / planned testing deadlines are about to expire.
* Stop the testing when we are not able to detect any more errors even after execution of all the planned test Cases.
We can see that both the above statements do not carry any meaning and are contradictory since we can satisfy the first statement even by doing nothing while the second statement is equally meaningless since it can not ensure the quality of our test cases.
Pin pointing the time - when to stop testing is difficult. Many modern software applications are so complex and run in such an Interdependent environment, that complete testing can never be done.
Most common factors helpful in deciding when to stop the testing are:
* Stop the Testing when deadlines like release deadlines or testing deadlines have reached
* Stop the Testing when the test cases have been completed with some prescribed pass percentage.
* Stop the Testing when the testing budget comes to its end.
* Stop the Testing when the code coverage and functionality requirements come to a desired level.
* Stop the Testing when bug rate drops below a prescribed level
* Stop the Testing when the period of beta testing / alpha testing gets over.
Keeping a Track on the Progress of Testing:
Testing metrics can help the testers to take better and accurate decisions; like when to stop testing or when the application is ready for release, how to track testing progress & how to measure the quality of a product at a certain point in the testing cycle.
The best way is to have a fixed number of test cases ready well before the beginning of test execution cycle. Subsequently measure the testing progress by recording the total number of test cases executed using the following metrics which are quite helpful in measuring the quality of the software product
1) Percentage Completion: (Number of executed test cases) / (Total number of test cases)
2) Percentage Test cases Passed: Defined as (Number of passed test cases) / (Number of executed test cases)
3) Percentage Test cases Failed: Defined as (Number of failed test cases) / (Number of executed test cases)
A test case is declared - Failed even when just one bug is found while executing it, otherwise it is considered as - Passed
Scientific Methods to decide when to stop testing:
1) Decision based upon Number of Pass / Fail test Cases:
a) Preparation of predefined number of test cases ready before test execution cycle.
b) Execution of all test cases In every testing cycle.
c) Stopping the testing process when all the test cases get Passed
d) Alternatively testing can be stopped when percentage of failure in the last testing cycle is observed to be extremely low.
2) Decision based upon Metrics:
a) Mean Time Between Failure (MTBF): by recording the average operational time before the system failure.
b) Coverage metrics: by recording the percentage of instructions executed during tests.
c) Defect density: by recording the defects related to size of software like "defects per 1000 lines of code" or the number of open bugs and their severity levels.
Finally How to Decide:
Stop the testing, If:
1) Coverage of the code is good
2) Mean time between failure is quite large
3) Defect density is very low
4) Number of high severity Open Bugs is very low.
Here 'Good', 'Large', 'Low' and 'High' are subjective terms and depend on the type of product being tested. Ultimately, the risk associated with moving the application into production, as well as the risk of not moving forward, must be taken into consideration.
Broad / Universal statement to define the time to stop testing is when:
All the test cases, derived from equivalent partitioning, cause-effect analysis & boundary-value analysis are executed without detecting errors.
Thursday, July 15, 2010
Test Planning (Summary)
Test planning is one of the most important factor in the testing life cycle.
Test planning is the collective approach of testing methodologies and activities.
Following things should be consider at the time of test planning.
Who should do?
Skills, Roles, Responsibilities
Team Formation
Allocating Testing Tasks to Teams
Allocating Testing Task related activities to individuals
Efforts?
Task Efforts
- Activity Efforts
Function Point Analysis
Wideband Delphi
Work Breakdown Structure
COCOMO II
Percentage
Analogy
Sizing
Feasibility Study & Proof of Concept?
When to do? (Test Execution..etc)
When to Start
- Entry Criteria
When to Stop
When to Continue
When to End/ Finish
- Exit Criteria
Scheduling
Reviews?
Costs?
Fixed Cost
Pricing to Win
Time and Material
COCOMO II
Risks?
Requirements are not Frozen
Issues
Defend Decisions
Risk Mitigation
Manage Testing?
Traceability Matrix
Deliverables?
Test Cases
Change and Review Logs
Test Results
Test Reports
Maintenance Plan?
Defect Tracking and Diagnosis
Trace Bottlenecks
Defect Fixes and Re-Tests
Skills
Competency
Quality
ROI?
Cost Benefit Analysis
Sign-Off?
Agreement
Satisfaction
Future Plans?
Explore
New Business
Test planning is the collective approach of testing methodologies and activities.
Following things should be consider at the time of test planning.
Who should do?
Skills, Roles, Responsibilities
Team Formation
Allocating Testing Tasks to Teams
Allocating Testing Task related activities to individuals
Efforts?
Task Efforts
- Activity Efforts
Function Point Analysis
Wideband Delphi
Work Breakdown Structure
COCOMO II
Percentage
Analogy
Sizing
Feasibility Study & Proof of Concept?
When to do? (Test Execution..etc)
When to Start
- Entry Criteria
When to Stop
When to Continue
When to End/ Finish
- Exit Criteria
Scheduling
Reviews?
Costs?
Fixed Cost
Pricing to Win
Time and Material
COCOMO II
Risks?
Requirements are not Frozen
Issues
Defend Decisions
Risk Mitigation
Manage Testing?
Traceability Matrix
Deliverables?
Test Cases
Change and Review Logs
Test Results
Test Reports
Maintenance Plan?
Defect Tracking and Diagnosis
Trace Bottlenecks
Defect Fixes and Re-Tests
Skills
Competency
Quality
ROI?
Cost Benefit Analysis
Sign-Off?
Agreement
Satisfaction
Future Plans?
Explore
New Business
Test Strategy (Summary )
A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.
In the test strategy is described how the product risks of the stakeholders are mitigated in the test levels, which test types are performed in the test levels, and which entry and exit criteria apply.
The test strategy is created based on development design documents. The system design document is the main one used and occasionally, the conceptual design document can be referred to. The design documents describe the functionalities of the software to be enabled in the upcoming release. For every set of development design, a corresponding test strategy should be created to test the new feature sets.
What to do?
- Identify the Scope of Testing
- Identify Types of Testing to be carried out
- Identify the Testing Tasks
- Identify whether any Testing Tools are required
- Identify whether any Frameworks need to be used
- Identify the Metrics to be collected
- Identify the Deliverables, Dashboard and Reports
- Identify the Factors affecting Quality of Deliverables
- Identify when to complete Testing
How to do?
- Identify the Test Requirements
- Define Target Test Environments
- Identify the Testing Activities to Complete Tasks
- Identify the ways to conduct the Testing Activities
- Identify the Test Cases for the Testing Activities
- Identify Resources for the Testing Activities
- Identify the ways to meet the deliverables
- Identify the ways to improve Quality
For detail analysis click below link
http://pravinbate.blogspot.com/2009/10/test-strategy-or-test-approaches.html
In the test strategy is described how the product risks of the stakeholders are mitigated in the test levels, which test types are performed in the test levels, and which entry and exit criteria apply.
The test strategy is created based on development design documents. The system design document is the main one used and occasionally, the conceptual design document can be referred to. The design documents describe the functionalities of the software to be enabled in the upcoming release. For every set of development design, a corresponding test strategy should be created to test the new feature sets.
What to do?
- Identify the Scope of Testing
- Identify Types of Testing to be carried out
- Identify the Testing Tasks
- Identify whether any Testing Tools are required
- Identify whether any Frameworks need to be used
- Identify the Metrics to be collected
- Identify the Deliverables, Dashboard and Reports
- Identify the Factors affecting Quality of Deliverables
- Identify when to complete Testing
How to do?
- Identify the Test Requirements
- Define Target Test Environments
- Identify the Testing Activities to Complete Tasks
- Identify the ways to conduct the Testing Activities
- Identify the Test Cases for the Testing Activities
- Identify Resources for the Testing Activities
- Identify the ways to meet the deliverables
- Identify the ways to improve Quality
For detail analysis click below link
http://pravinbate.blogspot.com/2009/10/test-strategy-or-test-approaches.html
Wednesday, June 23, 2010
Cloud Computing
Cloud computing is a technology that uses the internet and central remote servers to maintain data and applications. Cloud computing allows consumers and businesses to use applications without installation and access their personal files at any computer with internet access. This technology allows for much more efficient computing by centralizing storage, memory, processing and bandwidth.
A simple example of cloud computing is Yahoo email or Gmail etc. You dont need a software or a server to use them. All a consumer would need is just an internet connection and you can start sending emails. The server and email management software is all on the cloud ( internet) and is totally managed by the cloud service provider Yahoo , Google etc. The consumer gets to use the software alone and enjoy the benefits. The analogy is , 'If you only need milk , would you buy a cow ?' All the users or consumers need is to get the benefits of using the software or hardware of the computer like sending emails etc. Just to get this benefit (milk) why should a consumer buy a (cow) software /hardware ?
Cloud computing is a paradigm shift following the shift from mainframe to client–server in the early 1980s. Details are abstracted from the users, who no longer have need for expertise in, or control over, the technology infrastructure "in the cloud" that supports them. Cloud computing describes a new supplement, consumption, and delivery model for IT services based on the Internet and it typically involves over the-Internet-provision of dynamically scalable and often virtualized resources.It is a byproduct and consequence of the ease-of-access to remote computing sites provided by the Internet.
The term "cloud" is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet in computer network diagram as an abstraction of the underlying infrastructure it represents. Typical cloud computing providers deliver common business applications online that are accessed from another Web service or software like a Web browser, while the software and data are stored on servers.
Most cloud computing infrastructure consists of services delivered through data centers and built on servers. Clouds often appear as single points of access for all consumers' computing needs. Commercial offerings are generally expected to meet quality of service (QoS) requirements of customers, and typically include SLAs. The major cloud-only service providers include Salesforce, Amazon and Google.
Characteristics
n general, Cloud computing customers do not own the physical infrastructure, instead avoiding capital expenditure by renting usage from a third-party provider. They consume resources as a service and pay only for resources that they use. Many cloud-computing offerings employ the utility computing model, which is analogous to how traditional utility services (such as electricity) are consumed, whereas others bill on a subscription basis. Sharing "perishable and intangible" computing power among multiple tenants can improve utilization rates, as servers are not unnecessarily left idle (which can reduce costs significantly while increasing the speed of application development). A side-effect of this approach is that overall computer usage rises dramatically, as customers do not have to engineer for peak load limits.[15] In addition, "increased high-speed bandwidth" makes it possible to receive the same response times from centralized infrastructure at other sites.
Economics
Cloud computing users can avoid capital expenditure (CapEx) on hardware, software, and services when they pay a provider only for what they use. Consumption is usually billed on a utility (resources consumed, like electricity) or subscription (time-based, like a newspaper) basis with little or no upfront cost. Other benefits of this time sharing-style approach are low barriers to entry, shared infrastructure and costs, low management overhead, and immediate access to a broad range of applications. In general, users can terminate the contract at any time (thereby avoiding return on investment risk and uncertainty), and the services are often covered by service level agreements (SLAs) with financial penalties.
According to Nicholas Carr, the strategic importance of information technology is diminishing as it becomes standardized and less expensive. He argues that the cloud computing paradigm shift is similar to the displacement of electricity generators by electricity grids early in the 20th century.
Although companies might be able to save on upfront capital expenditures, they might not save much and might actually pay more for operating expenses. In situations where the capital expense would be relatively small, or where the organization has more flexibility in their capital budget than their operating budget, the cloud model might not make great fiscal sense. Other factors impacting the scale of any potential cost savings include the efficiency of a company's data center as compared to the cloud vendor's, the company's existing operating costs, the level of adoption of cloud computing, and the type of functionality being hosted in the cloud.
Among the items that some cloud hosts charge for are instances (often with extra charges for high-memory or high-CPU instances); data transfer in and out; storage (measured by the GB-month); I/O requests; PUT requests and GET requests; IP addresses; and load balancing. In some cases, users can bid on instances, with pricing dependent on demand for available instances.
Cloud computing is broken down into three segments: "applications," "platforms," and "infrastructure." Each segment serves a different purpose and offers different products for businesses and individuals around the world.
Applications: It's all On Demand
So far the applications segment of cloud computing is the only segment that has proven useful as a business model.
On Demand software services come in a few different varieties which vary in their pricing scheme and how the software is delivered to the end users. In the past, the end-user would generally purchase a servers and is accessed by the end user over the internet. While this is the most common platform for On Demand software services, there are also some slightly different offerings which can be described as a hybrid of these two platforms. For instance, a program through which the end user pays a license fee, but then accesses the software over the internet from centralized servers is considered a hybrid service.
Who is Offering On Demand Software? - The companies below are already established in the On-Demand software or SaaS business. These companies charge their customers a subscription fee and in return host software on central servers that are accessed by the end user via the internet.
e.g. Google, Salesforce.com, NetSuite, Teleo etc..
Who is Offering Traditional Software? - The following companies have established themselves as traditional software providers. These companies sell licenses to their users, who then run the software from on premise servers.
e.g SAP. Oracle etc..
Platforms:
Many of the companies that started out providing On Demand application services have developed platform services as well. The platform segment of cloud computing refers to products that are used to deploy internet. NetSuite, Amazon, Google, and Microsoft have also developed platforms that allow users to access applications from centralized servers.
Active platforms - The following companies are some that have developed platforms that allow end users to access applications from centralized servers using the internet. Next to each company is the name of their platform.
* Google (GOOG) - Apps Engine
* Amazon.com (AMZN) - EC2
* Microsoft (MSFT) - Windows Live
* Terremark Worldwide (TMRK) - The Enterprise Cloud
* Salesforce.com (CRM) - Force.com
* NetSuite (N) - Suiteflex
* Rackspace Cloud - cloudservers, cloudsites, cloudfiles
* Metrisoft - Metrisoft SaaS Platform
Infrastructure:
The final segment in cloud computing, known as the infrastructure, is very much the backbone of the entire concept. Infrastructure vendors environments (such as Google gears) that allow users to build applications. Cloud storage, such as Amazon's S3, is also considered to be part of the infrastructure segment.
* Major Infrastructure Vendors - Below are companies that provide infrastructure services:
o Google (GOOG) - Managed hosting, development environment
o International Business Machines (IBM) - Managed hosting
o SAVVIS (SVVS) - Managed hosting
o Terremark Worldwide (TMRK) - Managed hosting
o Amazon.com (AMZN) - Cloud storage
o Rackspace Hosting (RAX) - Managed hosting & cloud computing
Key features
* Agility improves with users' ability to rapidly and inexpensively re-provision technological infrastructure resources.
* Cost is claimed to be greatly reduced and capital expenditure is converted to operational expenditure. This ostensibly lowers barriers to entry, as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options and fewer IT skills are required for implementation (in-house).
* Device and location independence:enable users to access systems using a web browser regardless of their location or what device they are using (e.g., PC, mobile). As infrastructure is off-site (typically provided by a third-party) and accessed via the Internet, users can connect from anywhere.
* Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for:
o Centralization of infrastructure in locations with lower costs (such as real estate, electricity, etc.)
o Peak-load capacity increases (users need not engineer for highest possible load-levels)
o Utilization and efficiency improvements for systems that are often only 10–20% utilized.
* Reliability is improved if multiple redundant sites are used, which makes well designed cloud computing suitable for business continuity and disaster recovery. Nonetheless, many major cloud computing services have suffered outages, and IT and business managers can at times do little when they are affected.
* Scalability via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads. Performance is monitored, and consistent and loosely coupled architectures are constructed using web services as the system interface.One of the most important new methods for overcoming performance bottlenecks for a large class of applications is data parallel programming on a distributed data grid.
* Security could improve due to centralization of data, increased security-focused resources, etc., but concerns can persist about loss of control over certain sensitive data, and the lack of security for stored kernels. Security is often as good as or better than under traditional systems, in part because providers are able to devote resources to solving security issues that many customers cannot afford. Providers typically log accesses, but accessing the audit logs themselves can be difficult or impossible. Furthermore, the complexity of security is greatly increased when data is distributed over a wider area and / or number of devices.
* Maintenance cloud computing applications are easier to maintain, since they don't have to be installed on each user's computer. They are easier to support and to improve since the changes reach the clients instantly.
* Metering cloud computing resources usage should be measurable and should be metered per client and application on daily, weekly, monthly, and annual basis. This will enable clients on choosing the vendor cloud on cost and reliability (QoS).
Issues:
Privacy
The Cloud model has been criticized by privacy advocates for the greater ease in which the companies hosting the Cloud services control, and thus, can monitor at will, lawfully or unlawfully, the communication and data stored between the user and the host company. Instances such as the secret NSA program, working with AT&T, and Verizon, which recorded over 10 million phone calls between American citizens, causes uncertainty among privacy advocates, and the greater powers it gives to telecommunication companies to monitor user activity. While there have been efforts (such as US-EU Safe Harbor) to "harmonise" the legal environment, providers such as Amazon still cater to major markets (typically the United States and the European Union) by deploying local infrastructure and allowing customers to select "availability zones
Security
The relative security of cloud computing services is a contentious issue which may be delaying its adoption.[82] Some argue that customer data is more secure when managed internally, while others argue that cloud providers have a strong incentive to maintain trust and as such employ a higher level of security.
A simple example of cloud computing is Yahoo email or Gmail etc. You dont need a software or a server to use them. All a consumer would need is just an internet connection and you can start sending emails. The server and email management software is all on the cloud ( internet) and is totally managed by the cloud service provider Yahoo , Google etc. The consumer gets to use the software alone and enjoy the benefits. The analogy is , 'If you only need milk , would you buy a cow ?' All the users or consumers need is to get the benefits of using the software or hardware of the computer like sending emails etc. Just to get this benefit (milk) why should a consumer buy a (cow) software /hardware ?
Cloud computing is a paradigm shift following the shift from mainframe to client–server in the early 1980s. Details are abstracted from the users, who no longer have need for expertise in, or control over, the technology infrastructure "in the cloud" that supports them. Cloud computing describes a new supplement, consumption, and delivery model for IT services based on the Internet and it typically involves over the-Internet-provision of dynamically scalable and often virtualized resources.It is a byproduct and consequence of the ease-of-access to remote computing sites provided by the Internet.
The term "cloud" is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet in computer network diagram as an abstraction of the underlying infrastructure it represents. Typical cloud computing providers deliver common business applications online that are accessed from another Web service or software like a Web browser, while the software and data are stored on servers.
Most cloud computing infrastructure consists of services delivered through data centers and built on servers. Clouds often appear as single points of access for all consumers' computing needs. Commercial offerings are generally expected to meet quality of service (QoS) requirements of customers, and typically include SLAs. The major cloud-only service providers include Salesforce, Amazon and Google.
Characteristics
n general, Cloud computing customers do not own the physical infrastructure, instead avoiding capital expenditure by renting usage from a third-party provider. They consume resources as a service and pay only for resources that they use. Many cloud-computing offerings employ the utility computing model, which is analogous to how traditional utility services (such as electricity) are consumed, whereas others bill on a subscription basis. Sharing "perishable and intangible" computing power among multiple tenants can improve utilization rates, as servers are not unnecessarily left idle (which can reduce costs significantly while increasing the speed of application development). A side-effect of this approach is that overall computer usage rises dramatically, as customers do not have to engineer for peak load limits.[15] In addition, "increased high-speed bandwidth" makes it possible to receive the same response times from centralized infrastructure at other sites.
Economics
Cloud computing users can avoid capital expenditure (CapEx) on hardware, software, and services when they pay a provider only for what they use. Consumption is usually billed on a utility (resources consumed, like electricity) or subscription (time-based, like a newspaper) basis with little or no upfront cost. Other benefits of this time sharing-style approach are low barriers to entry, shared infrastructure and costs, low management overhead, and immediate access to a broad range of applications. In general, users can terminate the contract at any time (thereby avoiding return on investment risk and uncertainty), and the services are often covered by service level agreements (SLAs) with financial penalties.
According to Nicholas Carr, the strategic importance of information technology is diminishing as it becomes standardized and less expensive. He argues that the cloud computing paradigm shift is similar to the displacement of electricity generators by electricity grids early in the 20th century.
Although companies might be able to save on upfront capital expenditures, they might not save much and might actually pay more for operating expenses. In situations where the capital expense would be relatively small, or where the organization has more flexibility in their capital budget than their operating budget, the cloud model might not make great fiscal sense. Other factors impacting the scale of any potential cost savings include the efficiency of a company's data center as compared to the cloud vendor's, the company's existing operating costs, the level of adoption of cloud computing, and the type of functionality being hosted in the cloud.
Among the items that some cloud hosts charge for are instances (often with extra charges for high-memory or high-CPU instances); data transfer in and out; storage (measured by the GB-month); I/O requests; PUT requests and GET requests; IP addresses; and load balancing. In some cases, users can bid on instances, with pricing dependent on demand for available instances.
Cloud computing is broken down into three segments: "applications," "platforms," and "infrastructure." Each segment serves a different purpose and offers different products for businesses and individuals around the world.
Applications: It's all On Demand
So far the applications segment of cloud computing is the only segment that has proven useful as a business model.
On Demand software services come in a few different varieties which vary in their pricing scheme and how the software is delivered to the end users. In the past, the end-user would generally purchase a servers and is accessed by the end user over the internet. While this is the most common platform for On Demand software services, there are also some slightly different offerings which can be described as a hybrid of these two platforms. For instance, a program through which the end user pays a license fee, but then accesses the software over the internet from centralized servers is considered a hybrid service.
Who is Offering On Demand Software? - The companies below are already established in the On-Demand software or SaaS business. These companies charge their customers a subscription fee and in return host software on central servers that are accessed by the end user via the internet.
e.g. Google, Salesforce.com, NetSuite, Teleo etc..
Who is Offering Traditional Software? - The following companies have established themselves as traditional software providers. These companies sell licenses to their users, who then run the software from on premise servers.
e.g SAP. Oracle etc..
Platforms:
Many of the companies that started out providing On Demand application services have developed platform services as well. The platform segment of cloud computing refers to products that are used to deploy internet. NetSuite, Amazon, Google, and Microsoft have also developed platforms that allow users to access applications from centralized servers.
Active platforms - The following companies are some that have developed platforms that allow end users to access applications from centralized servers using the internet. Next to each company is the name of their platform.
* Google (GOOG) - Apps Engine
* Amazon.com (AMZN) - EC2
* Microsoft (MSFT) - Windows Live
* Terremark Worldwide (TMRK) - The Enterprise Cloud
* Salesforce.com (CRM) - Force.com
* NetSuite (N) - Suiteflex
* Rackspace Cloud - cloudservers, cloudsites, cloudfiles
* Metrisoft - Metrisoft SaaS Platform
Infrastructure:
The final segment in cloud computing, known as the infrastructure, is very much the backbone of the entire concept. Infrastructure vendors environments (such as Google gears) that allow users to build applications. Cloud storage, such as Amazon's S3, is also considered to be part of the infrastructure segment.
* Major Infrastructure Vendors - Below are companies that provide infrastructure services:
o Google (GOOG) - Managed hosting, development environment
o International Business Machines (IBM) - Managed hosting
o SAVVIS (SVVS) - Managed hosting
o Terremark Worldwide (TMRK) - Managed hosting
o Amazon.com (AMZN) - Cloud storage
o Rackspace Hosting (RAX) - Managed hosting & cloud computing
Key features
* Agility improves with users' ability to rapidly and inexpensively re-provision technological infrastructure resources.
* Cost is claimed to be greatly reduced and capital expenditure is converted to operational expenditure. This ostensibly lowers barriers to entry, as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options and fewer IT skills are required for implementation (in-house).
* Device and location independence:enable users to access systems using a web browser regardless of their location or what device they are using (e.g., PC, mobile). As infrastructure is off-site (typically provided by a third-party) and accessed via the Internet, users can connect from anywhere.
* Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for:
o Centralization of infrastructure in locations with lower costs (such as real estate, electricity, etc.)
o Peak-load capacity increases (users need not engineer for highest possible load-levels)
o Utilization and efficiency improvements for systems that are often only 10–20% utilized.
* Reliability is improved if multiple redundant sites are used, which makes well designed cloud computing suitable for business continuity and disaster recovery. Nonetheless, many major cloud computing services have suffered outages, and IT and business managers can at times do little when they are affected.
* Scalability via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads. Performance is monitored, and consistent and loosely coupled architectures are constructed using web services as the system interface.One of the most important new methods for overcoming performance bottlenecks for a large class of applications is data parallel programming on a distributed data grid.
* Security could improve due to centralization of data, increased security-focused resources, etc., but concerns can persist about loss of control over certain sensitive data, and the lack of security for stored kernels. Security is often as good as or better than under traditional systems, in part because providers are able to devote resources to solving security issues that many customers cannot afford. Providers typically log accesses, but accessing the audit logs themselves can be difficult or impossible. Furthermore, the complexity of security is greatly increased when data is distributed over a wider area and / or number of devices.
* Maintenance cloud computing applications are easier to maintain, since they don't have to be installed on each user's computer. They are easier to support and to improve since the changes reach the clients instantly.
* Metering cloud computing resources usage should be measurable and should be metered per client and application on daily, weekly, monthly, and annual basis. This will enable clients on choosing the vendor cloud on cost and reliability (QoS).
Issues:
Privacy
The Cloud model has been criticized by privacy advocates for the greater ease in which the companies hosting the Cloud services control, and thus, can monitor at will, lawfully or unlawfully, the communication and data stored between the user and the host company. Instances such as the secret NSA program, working with AT&T, and Verizon, which recorded over 10 million phone calls between American citizens, causes uncertainty among privacy advocates, and the greater powers it gives to telecommunication companies to monitor user activity. While there have been efforts (such as US-EU Safe Harbor) to "harmonise" the legal environment, providers such as Amazon still cater to major markets (typically the United States and the European Union) by deploying local infrastructure and allowing customers to select "availability zones
Security
The relative security of cloud computing services is a contentious issue which may be delaying its adoption.[82] Some argue that customer data is more secure when managed internally, while others argue that cloud providers have a strong incentive to maintain trust and as such employ a higher level of security.
Wednesday, May 26, 2010
HP QC Certification Questions and Answers: 5
Q. 41: To set a Quick Test Professional test as a template test, right-click the test in the test plan tree, and choose _________
A. Template Test
B. Template Tree
C. Template Plan
D. Template
<<<<<< =================== >>>>>>
Q. 42: You can change the label of any of the test detail fields.
A. True
B. False
<<<<<< =================== >>>>>>
Q. 43: A question mark icon in the test plan tree indicates that the QuickTest Professional add-in is _________ on your machine.
A. Not activated
B. Not installed
C. Not enabled
D. Not set
<<<<<< =================== >>>>>>
Q. 44: A ________ link is included in the e-mail, enabling the recipient to go directly to the test.
A. Link To Test
B. Move To Test
C. Go To Test
D. Test
<<<<<< =================== >>>>>>
Q. 45: In the Test Plan module, you create ________ by selecting requirements to link to a test.
A. RTM
B. Requirements coverage
C. Test coverage
D. SRS
<<<<<< =================== >>>>>>
Q. 46: Alternatively, in the Requirements module, you create _______ by selecting tests to link to a requirement.
A. RTM
B. Requirements coverage
C. Test coverage
D. SRS
<<<<<< =================== >>>>>>
Q. 47: A test can cover more than one requirement, and a requirement can be covered by only one test.
A. True
B. False
<<<<<< =================== >>>>>>
Q. 48: You can also create coverage between test instances and requirements. You can enable this feature using the __________ parameter in Site Administration
A. ALLOW_REQ_COVERAGE_BY_TEST_INSTANCE
B. ALLOW_TEST_COVERAGE_BY_REQ_INSTANCE
C. ALLOW_R_COVERAGE_BY_T_INSTANCE
D. None of above
B. ALLOW_TEST_COVERAGE_BY_REQ_INSTANCE
C. ALLOW_R_COVERAGE_BY_T_INSTANCE
D. None of above
<<<<<< =================== >>>>>>
Q. 49: Requirements coverage is created automatically when you convert a requirement to a test. Therefore, even if you have not yet added requirements coverage, it may already exist.
A. True
B. False
<<<<<< =================== >>>>>>
Q. 50: You can also define requirements coverage by dragging a requirement in the requirements tree to the coverage grid. The requirement is added to the coverage grid without its child requirements.
A. True
B. False
HP QC Certification Questions and Answers: 4
Q. 31: QA Manager changes a requirement from a ___________ status to a Reviewed status once it is approved.
A. Released
B. Tested
C. Not reviewed
D. None of the above
<<<<<< =================== >>>>>>
Q. 32: You can also import requirements to your Quality Center
A. HP Third Party add-in.
B. HP Quality Center add-in.
C. HP Quality Center
C. HP Quality Center
D. HP Quality Center License
<<<<<< =================== >>>>>>
Q. 33: The Requirements Grid view enables you to display requirements in a _________ view.
A. Flat
B. Hierarchical
C. Flat-hierarchical
D. Flat non-hierarchical
<<<<<< =================== >>>>>>
Q. 34: The _________ view enables you to analyze the breakdown of child requirements according to test coverage status.
A. Coverage Analysis
B. Coverage Requirements
C. Coverage
C. Coverage
D. Coverage Tests
<<<<<< =================== >>>>>>
Q. 35: You can access the Requirements menu bar from the Requirements module by pressing the shortcut key ___________.
A. F1
B. F9
C. Ctrl + R
D. Alt + R
<<<<<< =================== >>>>>>
Q. 36: You can use the ____________to restrict and dynamically change the fields and values in the Requirements module.
A. Script Edit
B. Scriptor Editor
C. Script Editor
D. Script Editing
<<<<<< =================== >>>>>>
Q. 37: The Requirements module enables you to define and manage your _________
A. Requirements
B. All requirements
C. Some requirements
D. Tedious requirements
<<<<<< =================== >>>>>>
38: You can rename or delete Requirements root folder.
A. True
B. False
<<<<<< =================== >>>>>>
Q. 39: You can search for a particular requirement in the requirements tree or in the requirements grid using the _________ command.
A. Search
B. Find
C. Search All
D. Find All
<<<<<< =================== >>>>>>
Q. 40: You can replace field values in the requirements tree or in the requirements grid using the ___________command.
A. Replace
B. Replace All
C. Find & Replace
D. Replace & Find
Subscribe to:
Posts (Atom)
