Author Archive
Friday, August 22nd, 2008
The following can help with QuickTest Professional performance issues:
1. Do not load unnecessary add-ins in the Add-in Manager when QuickTest starts.
2. Run your tests in “Fast” mode. From the Run tab in the Options dialog box, select the “Fast” option.
3. If you are not using the Active Screen while editing your test, hide the Active Screen. Choose View > Active Screen, or toggle the Active Screen toolbar button to hide the Active Screen.
4. Decide if and how much information you want to capture and save in the Active Screen. The more information you capture, the slower recording and editing times. You can choose from the following Active Screen options to improve performance:
4.1 If you are testing Windows applications, you can choose to save all Active Screen information in every step, save information only in certain steps, or to disable Active Screen captures entirely. You set this preference in the Active Screen tab of the Options dialog box.
4.2 If you are testing Web applications, you can disable screen capture of all steps in the Active Screen. From the Active Screen tab of the Options dialog box, click Custom Level to open the Custom Active Screen Capture Settings dialog box. Select the Disable Active Screen Capture option. This will improve recording time.
4.3 When you save a new test, or when you save a test with a new name using Save As, you can choose not to save the captured Active Screen files with the test by clearing the Save Active Screen files option in the Save or Save As dialog box. This is especially useful when you have finished designing your test and you plan to use your test only for test runs. Tests without Active Screen files open more quickly and use significantly less disk space.
5. Decide when you want to capture and save images of the application for the test results. Unless absolutely required, uncheck the options “Save still image capture to results” and “Save movie to results” present under Tools > Options > Run tab.
6. Define variables and function in an external .vbs files and not inside an action. Then associate these files with your test script. If you define a variable or a function in an action, during each iteration of a test run, memory will be allocated to those variables/functions and would not be released.
7. Have more RAM than what is recommended by HP and good processor speed (System Requirements for QTP 9.2 are “Minimum of 512 MB of RAM” and “Pentinum IV”).
8. When you have tests (QTP) running for a long period if time, there are chances of memory leaks. To avoid memory leakage, always restart QTP from time to time.
9. Avoid using hard coded wait(x) statement. Wait statement waits for full x seconds, even if the event has already occurred. Instead use .sync or .exist. When using .exist property, always set TimeOut value.
10. Use Descriptive Programming instead of Object Repository. The lesser the function calls the Object Repository, the faster the script runs.
11. If using Object Repository, use “With” statement which can be set in Tools > Options > General Tab > “Automatically Generate “With” statements after recording”. When using “With” statement, the reference to the object is getting stored in the memory and gets referenced without calling the Object Repository.
12. If using Object Repository, disable Smart Identification in File -> Settings -> Run Tab. Instead, add additional properties to an object, so QTP can identify it without using Smart Identification.
13. Make sure that Object Synchronization Timeout in File->Settings->Run is set to 1 second.
14. When using objects like DB connections or MS Office COM, make sure you don’t create and initialize these objects multiple times (e.g. re-opening an excel file whenever you write to it).
15. Make sure that code doesn’t wait for an event that has already occurred. For example, if you are using wait loop for an object to appear, do not simply wait for 20 seconds. Instead, wait until wait time has passed OR until the object appears. This way, if the object appears after 10 seconds, you do not waste 10 seconds.
Mike Girenko
Wednesday, July 30th, 2008
Some time ago I was convinced that Testing is “a process of exercising an application with a purpose to find errors.” But I found that this is incorrect; Testing includes a lot more than just finding errors. Before Testing there is Test Estimation, Test Planning, and Test Documents Preparation phases. Then there is actual Testing, when application’s functionality is being compared to functional requirements (“a process of exercising an application with a purpose to find errors”) and defects are being reported. After Testing, there is Test Reporting, Test Process Review, and Test Documents Preparation. Out of many definitions of Testing, I like Cem Kaner’s one, “technical investigation of a product, on behalf of stakeholders, with the objective of exposing quality-related information of the kind they seek”
Mike Girenko
Monday, July 14th, 2008
When planning GUI level Automated testing, one of the main questions is what to automate. Build Acceptance testing and Regression Testing are two most common candidates for automation. When deciding, consider the balance between effort and benefit.
Some tests are easy to automate. Examples are:
1. Data-driven tests. When the same function needs to be validated with lots of different inputs or large data sets (login, search)
2. Short or simple transactions
3. Tests with stable and easy to generate results
4. Static and repetitive tests
Some tests are more difficult to automate:
1. Tests involving complex business logic
2. Tests with difficult to predict results
3. Cross-browser testing. Even if many tools for automated testing work with IE and FireFox, a test will not run on both browsers without extra effort.
When choosing what to automate, it is a good idea to start with a small set of tests covering only main functionality, which should give some short-term success and a working set of scripts, which can be used for testing. Then these scripts can be expanded to cover more functionality and eventually cover Regression Testing.
Mike Girenko
Wednesday, June 4th, 2008
Below is the link to an excellent overview of WATIR:
http://watirpodcast.com/
Željko Filipin asks Bret Pettichord about Watir. Bret is a lead developer of WATIR and just recently established his new company, WatirCraft, which will provide commercial support of WATIR.
Couple of notes:
1. Bret explains why WATIR doesn’t have a recorder. I personally used WatirRecorder (http://www.hanselman.com/blog/NewReleaseOfWatirMakerNowWatirRecorder.aspx), but agree with Bret, it is not very useful. I think it is also a part of bigger discussion about using recording, when creating scripts. I found that recording only helps with learning how a tool interacts with an application, but that is about all. It would be a mistake to rely on recording, when planning automated testing.
2. Since WATIR only works with IE, FireWater (which works with FF) is a main point of future development.
3. Bret mentions that WATIR is having issues with handling dialogs. I agree, I had a hard time automating testing of dialogs and pop up screens. There are seems to be workarounds, but I did not have much success.
Mike Girenko
Wednesday, May 28th, 2008
I wanted to outline a few pros and cons of manual and automated testing. By automated testing I mean GUI level Functional Testing (using commercial tools like HP Quick Test Pro or open-source tools like WATIR)
Pros and cons of Manual testing
Pros:
1. Low cost of test case design
2. Minimal requirement for tools or tool expertise (MS Word or MS Excel can be used)
3. No automation required
4. A tester can start preparing test cases as soon as requirements are ready
5. Can be scripted, exploratory, or both
Cons:
1. High cost of test execution (cost = execution time * labor rate)
2. The time to execute test cases is high
3. Scripted test execution is tedious and sometimes simply boring
4. It is error-prone and the quality depends on tester’s attention to detail
Pros and cons of Automated Testing.
Pros:
1. Frees testers for more intelligent types of testing (e.g., exploratory testing) or testing of complex, business-logic related functions of an application
2. It reduces time to execute test cases (it is especially helpful with Regression Testing, which takes the most time to complete)
3. It allows more frequent testing
4. Low cost of test execution
5. It increases accuracy and reliability of quality assessment in a release cycle
Cons:
1. High cost of tools (if using commercial tools, like HP Quick Test Pro)
2. Higher salaries (automated test creators get paid more (on average) than comparably senior manual test creators) required to hire resources
3. Cost of test scripts development and maintenance is high
4. Requires more technical expertise and requires programming skills
5. It cannot be introduced late in the development cycle, since it requires considerable amount of time to setup, design, and create
6. It is easy to spend time on automating something that should not be automated (for example, too complex functions of an application or GUI objects that cannot be automated), resulting in wasted time and efforts.
Mike Girenko
