Sub sub1()
Stri = "abcxyghixy"
substr = "xy"
MsgBox Replace(Stri, substr, "")
End Sub
Friday, October 8, 2010
How do you test a Notepad?
Humans seem to have a natural tendency to categorize. Software Test Engineers are no exception, especially when it comes into breaking down our work items. Different “types” of Testing include the following:
* Functional Testing
* Specification Testing
* Security Testing
* Regression Testing
* Automation Testing
* Beta Testing
* Functional Testing
* Specification Testing
* Security Testing
* Regression Testing
* Automation Testing
* Beta Testing
When is a product ready to ship?
When test is confident that all issues have been identified, documented, and resolved. [A poor answer would be “when all bugs have been fixed”. Upper management is responsible for deciding when a product is ready to ship. It’s tests responsibility to make sure upper management has all the information they need to make a calculated decision.]
What are the different test categories that test cases are commonly grouped by? or Web Testing Methods ?
For a web application
Functionality, Usability, Accessibility, Performance, Stress, Load, Scalability, Security, Compatibility, Localization, Globalization, UI, Documentation,
Functionality, Usability, Accessibility, Performance, Stress, Load, Scalability, Security, Compatibility, Localization, Globalization, UI, Documentation,
What goes into the body of a good bug report?
A good bug report contains a descriptive summary of the bug, the steps to reproduce the bug,screenshots of the bug, the expected behavior of the system, and the actual behavior of the system.
What is the difference between priority and severity?
Priority refers to how important a bug is to be fixed, and severity refers to how detrimental or damaging the bug is to the system or user experience.
Thursday, October 7, 2010
What is Value type and Reference type ? Whats the difference between Struct and class ?
A struct is a value type. To help understand the struct, it's helpful to make a comparison with classes.While a struct is a value type, a class is a reference type. Value types hold their value in memory where they are declared, but reference types hold a reference to an object in memory. If you copy a struct, C# creates a new copy of the object and assigns the copy of the object to a separate struct instance. However, if you copy a class, C# creates a new copy of the reference to the object and assigns the copy of the reference to the separate class instance. Structs can't have destructors, but classes can have destructors. Another difference between a struct and class is that a struct can't have implementation inheritance, but a class can. Although a struct can't have implementation inheritance, it can have interface inheritance.
what is the testing approach for web based application?
Why testing Web Applications is different?
Testing web applications is different because of many factors scenarios affecting the performance and user experience.
Web applications can typically cater to a large and a diverse audience. Web Applications can also be exposed to wide range of security threats. Web applications may open up illegal points of entry to the databases and other systems holding sensitive information.
Test Approach is a part of test plan.Basically this is what you want to test about the application.
1.what are the types of testings that we are going to perform on that application.let us say
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing
http://www.softwaretestinghelp.com/web-application-testing/
2.
Testing web applications is different because of many factors scenarios affecting the performance and user experience.
Web applications can typically cater to a large and a diverse audience. Web Applications can also be exposed to wide range of security threats. Web applications may open up illegal points of entry to the databases and other systems holding sensitive information.
Test Approach is a part of test plan.Basically this is what you want to test about the application.
1.what are the types of testings that we are going to perform on that application.let us say
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing
http://www.softwaretestinghelp.com/web-application-testing/
2.
Gloabalization and Localization Testing
Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!
You should be aware that pseudo-localization, which was discussed earlier, does not completely eliminate the need for functionality testing of a localized application. When you test for localizability before you localize, the chances of having serious functional problems due to localization are slim. However, you still have to check that the application you're shipping to a particular market really works. Now you can do it in less time and with fewer resources. The following section shows you some of the general areas on which to focus when performing a localization test. (For information on more specific areas, see "Localization Testing of the UI" later in this article.)
General Areas of Focus in Localization TestingLocalization testing should focus on several general areas. The first involves things that are often altered during localization, such as the UI and content files. The second consists of culture-specific, language-specific, and country-specific areas. Examples include configurable components-such as region defaults and the default language-as well as language-specific and region-specific functionality-such as default spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware and look for the encryption algorithms incorporated into the application. The rules and regulations for distribution of cryptographic software differ from country to country.
Pay specific attention to the customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework). For example, check that formatting of mailing addresses is locale-specific and that parts of the user's name are ordered correctly. (The order in which surname and first name appear varies according to country. For instance, some Muslim countries and certain regions in India use a different name order than that used in the English language.) Functionality of this kind is often implemented by an application-testing must verify its correctness.
Other areas of localization testing should include basic functionality tests; setup, upgrade, and uninstall tests that are run in the localized environment; and, finally, application and hardware compatibility tests that are planned according to the product's target market.
Platform in Localization TestingAny language version of Windows XP or Windows 2000 can be selected as a platform for the test if the product is properly globalized. Of course, in the case of localization testing, the localized version of the operating system can be a wise choice, since that's the most likely environment for your application in the real world. However, a globalized and localizable application, even after it undergoes localization, must be able to run on any language version of the operating system and with MUI installed.
You should run the application with MUI installed when your application implements an MUI behavior, through pluggable UI, satellite dynamic-link libraries (DLLs), or some other technique that adjusts the UI language to the user's preferences. MUI allows the user to switch the UI language of the operating system and thus you must make sure your application matches the operating-system settings. You should verify the behavior of the application when the user's default language of the UI differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.
Localization Testing of the UIAlso keep an eye on the behavior of applications that run processes in a system-such as operating-system services-rather than in a user's context. When a system process queries its user default UI language settings, it might get a result different from what a user's process running at the same time will get. This can cause localization problems, inconsistency in the UI that the user sees (if parts of it are generated by the system services), or even problems in functionality. In order to avoid those problems, always check an application's behavior with different default user and system UI languages. The settings for UI languages should also be different from those used in the development environment.
For example, assume you have a machine with MUI installed and a user whose default UI language is different from that of the system. Suppose a fax service waiting for incoming calls is running continuously and that, when a fax arrives, the service displays a notification message to the currently logged user (if there is one). You must ensure that the message be in the user's language, which might not necessarily be the same as the one returned to the fax service when it queries its default UI language.
In particular, localization testing of the UI and linguistics should cover items such as:
Validation of all application resources.
Verification of linguistic accuracy and resource attributes.
Checking for typographical errors.
Checking that printed documentation, online Help, messages, interface resources, and command-key sequences are consistent with each other. If you have shipped localized versions of your product before, make sure that the translation is consistent with the earlier released versions.
Confirmation of adherence to system, input, and display environment standards.
Checking usability of the UI.
Assessment of cultural appropriateness.
Checking for politically sensitive content.
Making sure the market-specific information about your company, such as contact information or local product-support phone numbers, is updated.
It's also a good idea to check that everything you are going to distribute in a local market complies with the local laws and regulations. (See Designing a World-Ready Program.) This includes not only the license agreement but also online Help and other user documentation.
You've now seen the importance of globalized testing, localizability testing, and localization testing in terms of ensuring both that a product is world-ready and that it is suitable for worldwide distribution. One way in which the testing process has changed to reflect new goals involves the type of tools currently being used.
http://msdn.microsoft.com/en-us/goglobal/bb688151.aspx
You should be aware that pseudo-localization, which was discussed earlier, does not completely eliminate the need for functionality testing of a localized application. When you test for localizability before you localize, the chances of having serious functional problems due to localization are slim. However, you still have to check that the application you're shipping to a particular market really works. Now you can do it in less time and with fewer resources. The following section shows you some of the general areas on which to focus when performing a localization test. (For information on more specific areas, see "Localization Testing of the UI" later in this article.)
General Areas of Focus in Localization TestingLocalization testing should focus on several general areas. The first involves things that are often altered during localization, such as the UI and content files. The second consists of culture-specific, language-specific, and country-specific areas. Examples include configurable components-such as region defaults and the default language-as well as language-specific and region-specific functionality-such as default spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware and look for the encryption algorithms incorporated into the application. The rules and regulations for distribution of cryptographic software differ from country to country.
Pay specific attention to the customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework). For example, check that formatting of mailing addresses is locale-specific and that parts of the user's name are ordered correctly. (The order in which surname and first name appear varies according to country. For instance, some Muslim countries and certain regions in India use a different name order than that used in the English language.) Functionality of this kind is often implemented by an application-testing must verify its correctness.
Other areas of localization testing should include basic functionality tests; setup, upgrade, and uninstall tests that are run in the localized environment; and, finally, application and hardware compatibility tests that are planned according to the product's target market.
Platform in Localization TestingAny language version of Windows XP or Windows 2000 can be selected as a platform for the test if the product is properly globalized. Of course, in the case of localization testing, the localized version of the operating system can be a wise choice, since that's the most likely environment for your application in the real world. However, a globalized and localizable application, even after it undergoes localization, must be able to run on any language version of the operating system and with MUI installed.
You should run the application with MUI installed when your application implements an MUI behavior, through pluggable UI, satellite dynamic-link libraries (DLLs), or some other technique that adjusts the UI language to the user's preferences. MUI allows the user to switch the UI language of the operating system and thus you must make sure your application matches the operating-system settings. You should verify the behavior of the application when the user's default language of the UI differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.
Localization Testing of the UIAlso keep an eye on the behavior of applications that run processes in a system-such as operating-system services-rather than in a user's context. When a system process queries its user default UI language settings, it might get a result different from what a user's process running at the same time will get. This can cause localization problems, inconsistency in the UI that the user sees (if parts of it are generated by the system services), or even problems in functionality. In order to avoid those problems, always check an application's behavior with different default user and system UI languages. The settings for UI languages should also be different from those used in the development environment.
For example, assume you have a machine with MUI installed and a user whose default UI language is different from that of the system. Suppose a fax service waiting for incoming calls is running continuously and that, when a fax arrives, the service displays a notification message to the currently logged user (if there is one). You must ensure that the message be in the user's language, which might not necessarily be the same as the one returned to the fax service when it queries its default UI language.
In particular, localization testing of the UI and linguistics should cover items such as:
Validation of all application resources.
Verification of linguistic accuracy and resource attributes.
Checking for typographical errors.
Checking that printed documentation, online Help, messages, interface resources, and command-key sequences are consistent with each other. If you have shipped localized versions of your product before, make sure that the translation is consistent with the earlier released versions.
Confirmation of adherence to system, input, and display environment standards.
Checking usability of the UI.
Assessment of cultural appropriateness.
Checking for politically sensitive content.
Making sure the market-specific information about your company, such as contact information or local product-support phone numbers, is updated.
It's also a good idea to check that everything you are going to distribute in a local market complies with the local laws and regulations. (See Designing a World-Ready Program.) This includes not only the license agreement but also online Help and other user documentation.
You've now seen the importance of globalized testing, localizability testing, and localization testing in terms of ensuring both that a product is world-ready and that it is suitable for worldwide distribution. One way in which the testing process has changed to reflect new goals involves the type of tools currently being used.
http://msdn.microsoft.com/en-us/goglobal/bb688151.aspx
Tuesday, October 5, 2010
How to test an application which has DataBase Upgrade
1. Identify and execute the testcases which can exercise all the database operations from application.
2. Execute automation scripts
3. Execute performance tests
4. Identify and execute testcases which update the existing records to test the backward compatibilty.
5. Ensure data integrity is maintained after upgrade. Contstraints for example should still be handled as expected.
2. Execute automation scripts
3. Execute performance tests
4. Identify and execute testcases which update the existing records to test the backward compatibilty.
5. Ensure data integrity is maintained after upgrade. Contstraints for example should still be handled as expected.
Monday, October 4, 2010
Contents of the Test Plan :
1.Objective : explains the purposoe of the testing
2.Scope : Explains the limittions of the testing
3.Activites: The actions need to be performed while testing.
4.Dependencies : Explains the prerequisites of the testing
5.Deliverables : The outcomes of the testing
6.H/W&S/w: Contains a list of H/W and S/W reqs
7.Resources: persons reqd,how long they reqd,what skills they shud have
8.Risk FActor : %of risk
9.Test Strategy : The strategy to be followed while tesing
10.Tracebility Matrix : it will have the reqs one side and the test cases other side
2.Scope : Explains the limittions of the testing
3.Activites: The actions need to be performed while testing.
4.Dependencies : Explains the prerequisites of the testing
5.Deliverables : The outcomes of the testing
6.H/W&S/w: Contains a list of H/W and S/W reqs
7.Resources: persons reqd,how long they reqd,what skills they shud have
8.Risk FActor : %of risk
9.Test Strategy : The strategy to be followed while tesing
10.Tracebility Matrix : it will have the reqs one side and the test cases other side
Difference between Smoke Testing and SanityTesting
Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
Smoke Testing:
Smoke testing is done at the start of the application is deployed. Smoke test is the entry point for the entire test execution. When the application is passed under the smoke test then only further system testing or regression testing can be carried out.
In general smoke testing is done when the higher version of the build is deployed and is done at each and every time the build is deployed. In smoke testing the main functionalites are tested and the stability of the system is validated.
Sanity Testing:
Sanity testing is also similar to Smoke testing, but has some minor differences. Sanity testing is done when the application is deployed into testing for the very first time and in smoke testing only positive scenarios are validated but in sanity testing both the positive and negative scenarios are validated.
For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
Sanity testing:We will check the complete functionality of the application
Smoke Testing: We will check the basic functionality of the application
A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.
Smoke Testing:
Smoke testing is done at the start of the application is deployed. Smoke test is the entry point for the entire test execution. When the application is passed under the smoke test then only further system testing or regression testing can be carried out.
In general smoke testing is done when the higher version of the build is deployed and is done at each and every time the build is deployed. In smoke testing the main functionalites are tested and the stability of the system is validated.
Sanity Testing:
Sanity testing is also similar to Smoke testing, but has some minor differences. Sanity testing is done when the application is deployed into testing for the very first time and in smoke testing only positive scenarios are validated but in sanity testing both the positive and negative scenarios are validated.
For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
Sanity testing:We will check the complete functionality of the application
Smoke Testing: We will check the basic functionality of the application
Subscribe to:
Posts (Atom)