Automation Tools - Different tools used for Automation

Automation is something that is becoming an important skill for any tester. If you have a minimum knowledge on how to automate an application & how to use the available automation tools would give a distinct quality for your profile.

Here in this blog, will try to explain what tools are in use in the present market and little bit about each of those tools.

GUI Layer Testing Tools:

Quick Test Professional (QTP) - by Hewlett-Packard (formerly owned by Mercury)

Test Complete (TC) - by Smart Bear (formerly Automated QA)

WinRunner - by Hewlett-Packard (formerly owned by Mercury)

IBM Rational Functional Tester - by IBM

Silk Test - by Borland

Note: This list contains only important or tools that are used by most of the companies. It doesn't include every tool that is in use.

Load/ Performance Testing Tools:

Load Runner - by Hewlett-Packard (formerly owned by Mercury)

IBM Rational performance Tester - by IBM

VisualStudio Load Test - Microsoft

Silk performer - by MicroFocus

GH Tester - by Greenhat

There's load of other load testing tools that you can find on internet.

References:

http://www.load-testing-tools.com/

http://www.testingfaqs.org/t-load.html

Test Cases: Plan/ Write/ Execute

Test case is the test documentation that a tester would write documenting the below:

• what functionality he's going to test, 
• what input he would require to give to execute this test, 
• in how many steps can he finish the step
• what is expected out of each step and finally document what is the Actual result of each step while executing.

Writing test cases is one of the typical responsibility that any tester would do all the time at his work. However writing test cases is done in chunks in different stages of SDLC. Test cases are planned, written and executed in different stages of application development. Test cases should be

Planned: when requirement documents are being prepared

Written: when requirement documents are signed off and when development is busy coding, should be peer reviewed, walk through'ed with all stake holders

Executed: when development is done with coding and when code is handed off to QA

What is a Test case Matrix:

Test cases could be written in either a spresdsheet or in Quality Centre like quality management tools. In most of the small companies, would go prepare a Test Case Matrix if they want save some money on these quality management tools.

Test case Matrix is nothing but a spreadsheet that has a list of tests and its results formatted in a column format for readability purposes. In some cases Test case matrix may have a set of requirements, set of test cases for each of those requirements and its results after the run, any defects if raised and a link to the test case running which caused that defect. A perfect relationship that one would see in Quality Centre like management tools can be replicated in Excel spreadsheet.

Example Template can be found here......

Testing Deliverables

When you perform testing, you deliver a quality product that is clean code (defect free code). However on top of this as QA team you would also deliver documents suggesting how did you go about testing, what all test cases you ran, are you happy with the application or not? & finally any lessons learned from this testing. Typically the documents expected to be delivered from QA are given below:

1. Manual Test case Matrix

2. Automation Test Scripts

3. Test Strategy/ Master Test Plan Document

4. Lessons Learnt Document

5. Sign-off Document

Note: These documents are stored in a file repository database so they can be referred to, if needed. Ex: Sometimes there's a bug found in production, so QA lead has a repository to go back to check for test cases that they wrote for testing that piece of functionality currently broke in production. If there were no tests written to test this particular scenario that failed in production, we will add a test to the regression test suite with High priority as this may repeat again

On top of this, you would be reporting the status of testing (may be in a weekly progress report call) using a document that you produce on the fly:

1. Defect Report

Note: Defect reports are generally used to track either test team or dev progress on the raised defects.