"Test Automation is no more a niche skill" – "any good business tester with right attitude can create test automation scripts".
Over the last decade test automation has undergone multiple facets of changes. Same vendors have introduced new tools, open source tools have come to stay, and still some vendors are marketing their products as the ultimate solution for Quality. CTOs of the organizations are convinced that automation is going to give them greater benefits in squeezing the cost and time over long run. Service providers have introduced several ultimate frameworks which save the effort of automation testers – right from standard data driven, Key-word, Hybrid to script-less frameworks whereby business users can create automation scripts without the hassles of Java of VB scripting knowledge.
This ultimately led us to the question if a dedicated automation test scripting community is required or the normal testers can do automation also? There are many articles stating that test automation should be group automation not a dedicated, aligned team working on automation scripts/projects.
When I was managing a test automation project during 2002, I was hunting for testers with development background to be part of the team as the tool created the code in a propriety language similar to "C". Any upgrade to the script is easily done by a tester who has the knowledge on the language. Then came the automation frameworks where the expertise in language helped the tester to write the "reusable functions" which are expected to save considerable time of the automation developers.
Secondly test automation developers were expected to convert the already written test cases into automation scripts; they are rarely expected to have the knowledge in the business to understand the same in right perspective before creating the scripts.
Test Automation as a preferred profession in Software Testing grew leaps and bounds over the next few years until the great recession struck us during 2008. Clients have started questioning the ROI out of the automation scripts developed over a period of time and the re-usage percentage of these scripts for the subsequent releases. They were really shocked to see that in many cases test automation has not yielded the desired result and scripts requires more maintenance to keep them LIVE to the current applications. Only very few clients where the technology is web centric have got excellent benefits in saving the cost and time due to Automation.
Test Automation – Current Status:
1) From automating the Regression test cases, automation is moving towards life cycle test automation. Clients have started exploring the various stages of test life cycle which can be automated with the right set of tools required for automating such manual work.
2) Automation testers are expected to have good business knowledge with the advent of model based testing. Clients can not hire separate testers for creating the model and automating the test cases.
3) Business Process automated test packs helps the clients to reduce the time to market for the standard, established applications and products.
4) Clients are unable to choose the tool vendors as there are multiple boutique shops which offer customized frameworks and script-less automation frameworks.
5) The Test Management tools have been completely integrated with the test life cycle and on the fly customized reports are generated.
6) Integration with different vendor tools sets in terms of requirements management, test management, test script execution, defect management are easily managed by the team which give more flexibility in choosing the appropriate vendors/tools.
7) Multiple customized utilities which helps the testers to reduce the redundant manual work has been created and promoted as differentiators by the independent testing vendors and some are even pricing them on the value client gets.
Let us come back to the question which we asked at the beginning if a dedicated automation tester is required or still automation holds key as a career ladder
While one can agree that test automation has become much simpler and manual tester with good business knowledge can pick up automation, the expectation from an automation expert has gone to different level. Anyone can execute the test automation scripts created by an expert, but still there are different skill sets with more technical knowledge which cannot be easily acquired by a manual tester overnight.
Test automation experts are expected to give the overall automation strategy for the entire product/application life cycle – gone are the days when they were requested to automate the already finalized test cases or scenarios. They need to identify the right set of tools for each stages of life cycle and given a seamless integration strategy which is cost effective. No client is ready to wait 6 to 8 cycles to get the return on investment. Apart from that, they are expected to define and develop multiple set of utilities which reduces the redundant manual testing work and test data generation work.
To conclude, Test automation experts will remain strongly as a technical professionals though the standard redundant part of test automation (sounds familiar ? – history repeats) may get merged with the group testing.
Today let me take a moment and explain my testing fraternity about one of the much in demand and upcoming skills for my tester friends i.e. ETL testing (Extract, Transform, and Load). This article will present you with a complete idea about ETL testing and what we do to test ETL process.
It has been observed that Independent Verification and Validation is gaining huge market potential and many companies are now seeing this as prospective business gain. Customers have been offered different range of products in terms of service offerings, distributed in many areas based on technology, process and solutions. ETL or data warehouse is one of the offerings which are developing rapidly and successfully.
Why do organizations need Data Warehouse?
Most of the companies are taking a step forward for constructing their data warehouse to store and monitor real time data as well as historical data. Crafting an efficient data warehouse is not an easy job. Many organizations have distributed departments with different applications running on distributed technology. ETL tool is employed in order to make a flawless integration between different data sources from different departments. ETL tool will work as an integrator, extracting data from different sources; transforming it in preferred format based on the business transformation rules and loading it in cohesive DB known are Data Warehouse.
Well planned, well defined and effective testing scope guarantees smooth conversion of the project to the production. A business gains the real buoyancy once the ETL processes are verified and validated by independent group of experts to make sure that data warehouse is concrete and robust.
ETL or Data warehouse testing is categorized into four different engagements irrespective of technology or ETL tools used:
ETL Testing Techniques:
1) Verify that data is transformed correctly according to various business requirements and rules.
Apart from these 4 main ETL testing methods other testing methods like integration testing and user acceptance testing is also carried out to make sure everything is smooth and reliable.
ETL Testing Process:
Similar to any other testing that lies under Independent Verification and Validation, ETL also go through the same phase.
It is necessary to define test strategy which should be mutually accepted by stakeholders before starting actual testing. A well defined test strategy will make sure that correct approach has been followed meeting the testing aspiration. ETL testing might require writing SQL statements extensively by testing team or may be tailoring the SQL provided by development team. In any case testing team must be aware of the results they are trying to get using those SQL statements.
Difference between Database and Data Warehouse Testing
There are number of universal verifications that have to be carried out for any kind of data warehouse testing. Below is the list of objects that are treated as essential for validation in ETL testing:
ETL Testing Challenges:
ETL testing is quite different from conventional testing. There are many challenges we faced while performing data warehouse testing. Here is the list of few ETL testing challenges I experienced on my project:
Data is important for businesses to make the critical business decisions. ETL testing plays a significant role validating and ensuring that the business information is exact, consistent and reliable. Also, it minimizes hazard of data loss in production.
Hope these tips will help ensure your ETL process is accurate and the data warehouse build by this is a competitive advantage for your business.
This is a guest post by Vishal Chhaperia who is working in a MNC on a test management role. He is having extensive experience in managing multi technology QA projects, Processes and teams.
Have you worked on ETL testing? Please share your ETL/DW testing tips and challenges below.
Negative Testing Examples
The process of negative testing is intended to exhibit - that a system does not do what it is not believed or supposed to do. While positive testing verifies that your application works as expected, negative testing makes sure that your application can gracefully handle invalid input or unexpected/ unpredicted user behavior.
Below are some of the examples of negative test cases:
1. I worked on an application where in there were few modules which had an Attachment tab containing buttons for adding an attachment (DOCX, PDF, and JPEG etc.), viewing an attachment, editing an attachment and deleting an attachment. In this scenario one of the negative test cases was uploading an empty DOCX file. It was uploaded fine but while viewing, it showed exceptions.
2. Suppose there is a Date field on a page. Negative testing will require you to enter invalid dates. On the other hand there are some fields which are required like Name etc. Try leaving those required fields empty and examine application behavior or response with that. For a Numeric field, try entering alphabets or vice versa to observe application behavior. For a field accepting limited characters observe application behavior by entering more characters than limited, enter negative numbers in case only positive are accepted and so on.
4. Negative test cases for an installer includes - try installing on a drive with "not adequate" disk space, try installing in a "read only" folder/directory etc, consume more RAM so that it starts paging data and see the behavior of installer afterwards.
6. A compact disk player can be in one of three states: Standby, On or Playing.
When in standby mode, the CD player can be turned On by pressing the standby button once (an indicator light turns from red to green to show the CD player is On). When the CD player is On, it can return to standby mode by pressing the standby button once (an indicator light turns from green to red to show the CD player is in standby mode). When the CD player is On, pressing the play button causes the currently loaded CD to play. Pressing the stop button when the CD player is playing a CD causes the CD player to stop playing the disk.
Examples of positive tests could include:
Verifying that with the CD player in Standby mode, pressing the standby button causes the CD player to turn On and the indicator light changes from red to green.
Verifying that with the CD player in the On state, pressing the Standby button causes the state of the CD player to change to Standby and the indicator light changes from green to red.
Examples of negative tests could include:
Investigating what happens if the CD player is playing a CD and the Standby button is pressed.
Investigating what happens if the CD player is On and the Play button is pressed without CD in the CD player.