Why upgrade to Automation Testing?
Sometimes people assume that automation will replace the manual testing/resource in the organization. Manual testing cannot be replaced with the Automation. Automation cannot be implemented to 100%. The tool itself will have certain limitations like the memory management, multiple operating environments and hardware configurations, etc. But the fact is that Automation Testing is the best way to increase the effectiveness, efficiency and coverage of our software testing.
Monday, 12 August 2013
How can I be a better tester?
Everyone is wondering 'How can I be a better tester' (or at least you should be). I request read this article.
http://www.ebaytechblog.com/2013/01/31/becoming-a-world-class-tester/
http://www.ebaytechblog.com/2013/01/31/becoming-a-world-class-tester/
Few secret methods of QTP objects
All QTP test objects have these five methods in common:
- Highlight – Highlights the object, much like the highlight feature in the object-repository.
- ToString – Returns a string representation of the object. Usually it’s just the name.
- Init – As described here, re-links the test-object to the runtime object. Especially useful in a web environment, after a page refresh. It works like method .RefreshObject
- MakeObjVisible - QTP sometimes throws error while acting upon an object which is not visible or not in focus. So to overcome such type of errors, we can use “.MakeObjVisible” method.
Monday, 15 July 2013
Why Automated Tests Didn’t Find That Bug?
It is widely accepted that the purpose of automated tests is not to find new defects but rather find regression bugs as new features are developed. But even so, there are many occasions where regression bugs slip through that end up in production and really should have been caught by the automated regression tests.
Let’s examine the reasons why automated tests failed to find the regression bugs:
1 – The Scenario Was Not Thought Of
Automated Tests are as good as the person who designed the tests. Automated Tests are a set of instructions that are executed against the target application. First, test analysts design test cases and come up with a list of scenarios. The scenarios are then scripted in a programming language to execute the scenarios automatically. Therefore, if a particular scenario was not thought of, it wouldn’t have been scripted to run as automated test.
2 – The Scenario Was Thought Of But Was Not Scripted
It takes time to automate tests. Depending on the complexity of the tests, test engineers coding skills, flexibility of test automation tools and frameworks, some tests take a long time to automate and hence miss the chance to find regression bugs as new features are developed.
3 – There is a Bug in the Test Code Itself
There are situations where the automated tests do not really run against the tester’s intentions or assumptions. In other words the automation engineers made a mistake in coding the tests or did not insert verification points in correct places.
4 – The Automated Tests Couldn’t Execute due to Environment Issues
This is particularly true when running System Tests via application UI, e.g. launching the application in browser. In such cases there are many dependencies on other applications, 3rd party or downstream systems, and if any of these are down or not responding or respond intermittently, the automated tests could not execute successfully and hence could not verify correctness of a particular test.
5 – Poor Analysis of Test Reports
After automated tests have executed, when there are failed tests, analysis is required to see the reason for the failed cases. This can take quite some time to analyze all the failed cases (many of which can be false positive). The analysis part is normally done manually and if the analysis is not done correctly, there could be genuine failures that are overlooked or masked by other issues.
Source: Testing Excellence
Let’s examine the reasons why automated tests failed to find the regression bugs:
1 – The Scenario Was Not Thought Of
Automated Tests are as good as the person who designed the tests. Automated Tests are a set of instructions that are executed against the target application. First, test analysts design test cases and come up with a list of scenarios. The scenarios are then scripted in a programming language to execute the scenarios automatically. Therefore, if a particular scenario was not thought of, it wouldn’t have been scripted to run as automated test.
2 – The Scenario Was Thought Of But Was Not Scripted
It takes time to automate tests. Depending on the complexity of the tests, test engineers coding skills, flexibility of test automation tools and frameworks, some tests take a long time to automate and hence miss the chance to find regression bugs as new features are developed.
3 – There is a Bug in the Test Code Itself
There are situations where the automated tests do not really run against the tester’s intentions or assumptions. In other words the automation engineers made a mistake in coding the tests or did not insert verification points in correct places.
4 – The Automated Tests Couldn’t Execute due to Environment Issues
This is particularly true when running System Tests via application UI, e.g. launching the application in browser. In such cases there are many dependencies on other applications, 3rd party or downstream systems, and if any of these are down or not responding or respond intermittently, the automated tests could not execute successfully and hence could not verify correctness of a particular test.
5 – Poor Analysis of Test Reports
After automated tests have executed, when there are failed tests, analysis is required to see the reason for the failed cases. This can take quite some time to analyze all the failed cases (many of which can be false positive). The analysis part is normally done manually and if the analysis is not done correctly, there could be genuine failures that are overlooked or masked by other issues.
Source: Testing Excellence
Tuesday, 9 July 2013
New Law Will Make Testers Liable for Missed Bugs
A tiny provision in a recent piece of proposed legislation could have an enormous impact on software testers worldwide if passed. Part of a bill introduced in the House of Representatives would make certain missed bugs a federal offense – including security bugs, functional bugs and even typos – with potential fines up to $10k and even prison time if the bug was deemed as something that should have “reasonably” been discovered in testing.
Source: Testing BlogsQTP to Selenium - Get Transformed
There are many tester's who are well versed with QTP but not selenium, here is a quick start. In the below mentioned image has all the basic operations that you would perform on a web browser. The left side are Selenium and the right side are the corresponding QTP commands.
Source: Go gaga over testing
Tuesday, 18 June 2013
Ten steps to implement Automation Framework approach
- Identification of the Scope of Testing - Company Oriented, Product Oriented, Project Oriented.
- Identification of the Needs of Testing - Identify Types of testing e.g. FT, Web Services etc. and application / modules to be tested.
- Identification of the Requirements of Testing - Find out the Nature of Requirements, Identification of type of actions for each requirement & identification of High Priority Requirements.
- Evaluation of the Test Automation Tool - Preparation of Evaluation Checklist, Identification of the Candidate Tools Available, Sample Run, Rate & Select the Tool, Implementation & Training.
- Identification of the Actions to be automated - Actions, Validations & Requirements supported by the Tool.
- Design of the Test Automation Framework - Framework Guidelines, Validations, Actions Involved, Systems Involved, Tool Extensibility Support, Customs Messages & UML Documentation.
- Design of the Input Data Bank - Identification of Types of Input file, Categorization & Design of File Prototypes.
- Development of the Automation Framework - Development of Script based upon Framework Design, Driver Scripts, Worker Scripts, Record / Playback, Screen / Window / Transaction, Action / Keyword & Data Driven.
- Population of Input Data Bank - Different Types of Data Input, Population of Data from Different Data Sources, Manual Input of Data and Parent – Child Data Hierarchy.
- Configuration of the Schedulers - Identify Scheduler Requirements & Configure the Schedulers .
Subscribe to:
Posts (Atom)