Wiki-2b: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(29 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Automated Testing'''
'''Automated Testing'''
<p>Every software development group tests its products but still defects are always present in delivered software. Test engineerings always try to catch these errors but they always creep in and they often reappear, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. Automation Testing is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, test design, and other test control and test reporting functions. usually, test automation involves automating a manual process already in existence that uses a formalized testing process. There are many tools available to perform automation testing today.
<p>Every software development group tests its products but still defects are always present in delivered software. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> always try to catch these errors but they always creep in and they often reappear, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. Automation Testing is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. Usually, test automation involves automating a manual process already in existence that uses a formalized testing process. There are many tools available to perform automation testing today.
</p>
</p>


== Manual Testing ==
== Manual Testing ==
<p>
<p>
Manual testing is the method in which testing of the software is done manually. In this type of testing, a tester acts like an end-user. All features of a software are tested to know if the behavior of the software is exactly according to the expectations of the customer. The tester uses a test plan. Other than test plan, there are test cases written, which are used for implementing the test plan. Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition, it may not be effective in finding certain classes of defects.
Manual testing is the method in which testing of the software is done manually. In this type of testing, a tester acts like an end-user. All features of a software are tested to know if the behavior of the software is exactly according to the expectations of the customer. The tester uses a test plan<ref>http://testingsoftware.blogspot.com/2005/11/what-is-test-plan_30.html</ref>. Other than test plan, there are test cases<ref>http://softwaretestingfundamentals.com/test-case/</ref> written, which are used for implementing the test plan. Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition, it may not be effective in finding certain classes of defects.
</p>
</p>


== Why Automation Testing ==
== Why Automation Testing ==
<p>Automated software testing has long been considered critical for big software development organizations but is often thought to be too expensive or difficult for smaller companies to implement. Many companies are recognizing the importance of automating the work of testers and including the auto-test as part of the regular build process. The results of the automatic test are seen as a measure of the current quality of the software. Combined with a code coverage tool it gives the answer to the all-elusive question: "How much of my code is currently running ok?"</p>
<p>Automated software testing has long been considered critical for big software development organizations but is often thought to be too expensive or difficult for smaller companies to implement. Many companies are recognizing the importance of automating the work of testers and including the auto-test as part of the regular build process. The results of the automatic test are seen as a measure of the current quality of the software. Combined with a code coverage tool it gives the answer to the all-elusive question: "How much of my code is currently running ok?."</p><p> The below factors make automation testing important:
<p>
</p>
The Development Environment is what we use while developing the application. The production environment refers to the database that is used when the application is published in the real world. The testing environment is meant for testing tools.  Testing of the application is done using Testing tools which automates the entire testing procedure. Since there are different databases in each environment, the problem that occurs is changes made in one Database do not reflect in the other.</p><p>
===<small>Automated Testing is both Time and Money Saving</small>===
A programmer is also responsible to tell the other developers what changes have been made in the database. Also one has to keep track of which changes need to be run against production machines during deployment. The solution for the above problem that rails offers is data migration. Databases of different types can also be migrated between the three different environments. For example, we may use  SQLlite<ref>http://en.wikipedia.org/wiki/SQLite</ref> in Development environment, but we can still migrate into production environment where heroku<ref>http://en.wikipedia.org/wiki/Heroku</ref> may have been used. The source is portable and the back end understands what operations to do on the database.</p><p>
<p>During software development cycle, software tests have to be repeated very often  to ensure quality. Software tests need to be repeated, every time a change in the source code happens. For each release of the software it may be tested on all supported operating systems<ref>http://www.computerhope.com/os.htm</ref> and hardware configurations. Repeating these tests manually is costly and time consuming. Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. The time to run these repetitive tests is reduced from days to hours by automated software testing. Saving the time directly translates into cost savings.
 
</p>
In reality Rails migrations are similar to version control of databases. Rails migrations is actually used since databases change requires modifications to both code and data. Hence we cannot use a source code version control system like Subversion<ref>http://betterexplained.com/articles/a-visual-guide-to-version-control/</ref> or Sourcesafe<ref>https://wiki.library.ucsf.edu/display/~128507@ucsf.edu/Source+Safe+vs.+Subversion</ref>. 


===<small>Improves Accuracy</small>===
<p>Manual testers are bound to make mistakes during monotonous manual testing. With Automated tests, the probability of errors occuring is relatively low. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results.
</p>
</p>
===<small>Increases Test Coverage</small>===
Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are difficult to be conducted  manually can be run unattended in Automation testing. They can even be run on multiple computers with different configurations. Automated software tests can easily execute thousands of different complex test cases during every test run providing test coverage that is impossible with manual tests.


== Creating A Migration ==
===<small>Automated Software Testing Does What Manual Testing Cannot</small>===
<p>
A controlled web application test with thousands of users cannot be performed by even the largest software departments. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with network or web software<ref>http://en.wikipedia.org/wiki/Category:Web_software</ref> and applications.
A migration is a sub class of ActiveRecord:: Migration which implements two methods: ‘up’ and ‘down’. The “up” method performs the required changes or transformations while the down methods reverses or roll backs them.</p><p>
A migration can be created using the following command:
<pre>
rake generate migration CreateCourse
</pre>
Migration Created :
<pre>
class CreateCourse < ActiveRecord::Migration
def up
create_table :course do |t|
  t.string :name
  t.text :description
  t.timestamps
end
end
def down
drop_table :course
end
end
</pre>
The above migration CreateCourse has just been created, but has not been applied to the Database yet. This migration will add a table called courses with string column called name and the text column called description. A primary key column called id will also be created by default. The time stamp columns created_at and updated_at which ActiveRecord populates automatically will also be added. Reversing this migration is nothing but dropping the table.</p>
<p>
Migrations can also be used to fix bad data in the database or generate new fields.</p><p>
For Example:
<pre>
class AddGradesToStudents < ActiveRecord::Migration
def up
change_table :students do |t|
  t.boolean :receive_grade, :default => false
end
User.update_all ["receive_grade = ?", true]
end
def down
remove_column :students, :receive_grade
end
end
</pre>
The above migration adds receive_grades to the students table. We want the default value to be false for new students. But existing students are considered to have a grade, So we use the student model to set the flag to true for existing students.</p><p>


ActiveRecord<ref>http://api.rubyonrails.org/classes/ActiveRecord/Base.html</ref> provides methods that perform common data definition tasks in a database. A migration is like a Ruby class so you’re not limited to these functions. For example, after adding a column you can write a code to set the value of that column for existing records (if necessary using your models).  The kind of object that  is yielded as a result of the migration code is object representing table.</p>
===<small>Helps Developers and Testers</small>===
         
Shared automated tests can be used by developers to find problems quickly before sending the code for Quality assurance. Tests would  run automatically whenever source code changes are checked in and in case of failure error reports would be automatically sent to the team or the developer. Features like these save developers time and increase their confidence.
== Updating Migrations ==
<p>
If you wish to make changes to the migration and you have already run the migration then you cannot just edit the migration and run it again. Rails will consider it has already run the migration, so it will do nothing on running “rake db:migrate”. The migration has to be rolled back and then make changes to the migration and run it.
It is not recommended to edit existing migration and that too if it has been run on production systems. Instead, writing a new migration that performs the changes required is better. Making changes to a newly generated migration that has not been committed to source code is relatively safe.</p><p>
Migrations are stored as files in the db/migrate directory, for every migration class. The name of the file is of the form YYYYMMDDHHMMSS_create_course.rb, that is nothing but a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration.
</p>


== Anatomy of Migrations ==
===<small>Improves Team Morale</small>===
<p>
Automating repetitive tasks with automated software testing gives the project  team , time to spend on more challenging and rewarding projects. Team members improve their skill sets and confidence and, in turn, pass those gains on to their organization.
Migrations are a subclass of the Rails class ActiveRecord::Migration. The class must contain at least two methods i.e up and down.
<pre>
class CreateCourses < ActiveRecord::Migration
def self.up
#...
end
def self.down
#...
end
end
</pre>
The ‘up’ method used to apply schema changes for this migration and the ‘down’ method is used to undo the changes. Example: the ‘up’ method creates a table with all the attribute description for the migration whereas the ‘down’ method can be used to drop the table for the same migration.
<pre>
Class CreateCourses < ActiveRecord::Migration
def self.up
      add_column :room_no, :integer
end
def self.down
      remove_column :room_no
end
end
</pre>
</p>


== Relationship between Model and Migration ==
==Approaches to Test Automation==
In Rails, a model<ref>http://www.tutorialspoint.com/ruby-on-rails/rails-active-records.htm</ref> internally maps itself to a database table. The table in the database must be the plural form of the model’s class. If we generate a model called Course, Rails automatically looks for a table called courses in the database.
<ul>
You can use the Rails generator to generate both the model and a corresponding migration using the following commands:
<li>Code-driven testing: With the help of a variety of input arguments, the public (usually) interfaces to classes, modules or libraries are tested to validate that the results that are returned are correct.</li>
<pre>
<li>Graphical user interface testing: User interface events such as keystrokes and mouse clicks are generated by testing framework, and observes the changes that result in the user interface and validates whether the observable behavior of the program is correct or not.</li>
rake generate model Course name: string description: text
</pre>
will create a migration that looks like this
<pre>
class CreateCourses < ActiveRecord::Migration
def change
  create_table :courses do |t|
t.string :name
t.text :description
t.timestamps
  end
end
end
</pre>


== Creating a Standalone Migration ==
===Code-driven testing===
If you are creating migrations for other purposes, then a migration generator is used:
Code driven test automation is a key feature of agile software development<ref>http://en.wikipedia.org/wiki/Agile_software_development</ref>, where it is known as test-driven development (TDD)<ref>http://en.wikipedia.org/wiki/Test-driven_development</ref>. Unit tests are written to define the functionality before the code is written. Only when all tests pass is the code considered complete. Proponents argue that it produces software that is both more reliable and less costly than code that is tested by manual exploration. It is considered more reliable because the code coverage is better, and because it is run constantly during development rather than once at the end of a waterfall development cycle. The developer discovers defects immediately upon making a change, when it is least expensive to fix. Finally, code refactoring<ref>http://refactoring.com/</ref> is safer; transforming the code into a simpler form with less code duplication, but equivalent behavior, is much less likely to introduce new defects.
<pre>
$ rails generate migration AddSemesterToCourse
</pre>
This will create an empty but appropriately named migration:
<pre>
class AddPartNumberToProducts < ActiveRecord::Migration
def change
end
end
</pre>


== Applying Migration to Development ==
===Graphical User Interface (GUI) testing===
<p>
<p>A variation on this type of tool is for testing of web sites. Here, web page is the “interface”. Such a framework utilizes entirely different techniques because it is reading HTML instead of observing window events. Another variation is scriptless test automation that does not use record and playback, but instead builds a model of the Application Under Test (AUT) and then enables the tester to create test cases by simply editing the test parameters and conditions. Test-case maintenance is  easy, as there is no code to maintain .As the AUT changes the software objects can simply be re-learned or added. It can be applied to any GUI-based software application. The problem with this model is that AUT is actually implemented using test scripts, which have to be constantly maintained whenever there's change to the AUT.</p>
Since CreateCourse migration has been created but not applied to the database, the following command is used to apply the migration to the development database:
</ul>
<pre>
rake  db:migrate
</pre>
Every Rails Database has a table called schema_migrations maintained by the migration code. Whenever a migration is applied successfully a new row will be added to schema_migrations table. The schema_migrations table has a version column. When you run rake db:migrate, the task first looks for the schema_migrations table. It will be created if it does not exist. The migration code then looks at all the migration files in db/migrate and skips from considering any that have a version number that is already in the database. It then continues by applying the remaining migrations in turn creating a new row in the schema_migrations table for every migration.
</p>


== Applying Migration to Production ==
==What To Automate==
<p>
<p>Test automation tools can be expensive, and are usually employed in combination with manual testing. Hence It is not possible to automate everything in the Software. Software systems which are used by a  large amount of users simultaneously should be automated. For example, automating test that tests the combinatorial interactions of interdependent parameters at the API level or through the UI makes a lot of sense because the number of combinatorial tests for any complex feature would take much longer to test manually as compared to a 'data-driven' automated test.</p>
The following command is used to apply migration to the production database:
<pre>
heroku rake db:migrate
</pre>
In the above example the production database is Heroku.
</p>


== Running Specific Migrations ==
==When To Automate==
<p>
<p>Automated tests, that are written before the code, capture the intention of the code, inform design decisions, provide rapid feedback and let the developers know when the code is done. Test automation could also be written after the system code has been written so the automation has to cope with less change. But Automated tests that are written after the code do not directly inform the design nor do they provide rapid feedback. If these tests help us build a better product then they should be written before the code. If we are using automation to do exploratory testing and we intend to throw the automation code away afterwards then we can write the tests later.</p>
If you need to run a specific migration up or down, the db:migrate:up and db:migrate:downtasks will do that on including the version also.
</p>
For example,
<pre>
rake db:migrate:up VERSION=20080906120000
</pre><p>
The above command will run the up method from the 20080906120000 migration. These tasks still check whether the migration has already run, so for example db:migrate:up VERSION=20080906120000 will do nothing if Active Record believes that 20080906120000 has already been run.
</p>


== Rolling Back a Migration ==
== Automation Tools ==
<p>
<p>
The following command is used to rollback the last migration:
Tools are a driving agent for an automation process. Tools are specifically designed to target some particular test environment, such as Windows and web automation tools, etc.  However, an automation framework is an infrastructure that provides the solution where different tools can do their job in a unified manner. This provides a common platform for the automation engineer. Below are few automation tools that are being used in the software industry today:</p>
<pre>
<ul>
rake db:rollback
<li>HP QuickTest Professional</li>
</pre>
<li>IBM Rational Functional Tester</li>
Rollback is performed when you made some mistake and instead of tracking down the version number of the previous migration, you can just rollback and run it after making changes.</p><p>
<li>Rational robot</li>
If you need to rollback several migrations, a STEP parameter is used. For example,
<li>WATIR</li>  
<pre>
<li>Selenium</li>  
rake db:rollback STEP=2
</ul>
</pre>
The above command will rollback the last 2 migrations.
The db:migrate:redo task is an easy way for doing a rollback and then migrating again. If you need to redo several migrations, a STEP parameter is used. For example, in order to redo the last 4 migrations, the command is
<pre>
rake db:migrate:redo STEP=4
</pre>
“rake db:reset” is the command for resetting the database. This will drop the databse, recreate it and loads the current schema into it.
</p>


== Problems with Migration ==
<p>HP QuickTest Professional is produced by HP Software Division, IBM Rational Functional Tester and Rational robot are produced by IBM Rational and WATIR and Selenium are open source. There are also many other tools which are available.
<p>
One major problem Migrations suffer is that most databases do not support the rolling back of create table or alter table i.e. DDL statements in general. Let’s consider an example where a migration tries to create two tables.
<pre>
class Example < ActiveRecord::Migration
def self.up
  create_table :first do ...
 
  end
  create_table
:second do ...
  end
end
def self.down
  drop_table :second
  drop_table :first
end
end
</pre>
In the above example the up method is used for creating the tables first and second and the down method is used to dropping the tables. Now, consider a situation where there is a problem creating the second table. Then the database will contain only the first table and not the second table. So if you try to rollback the migration, it won’t work as the original migration failed and the schema version in the database
wasn’t updated. So you cannot roll back it. One solution to the above problem is, to manually change the schema information and drop the table first. But, it is recommended in these cases to simply drop the whole database, create the whole thing again and apply migrations to bring it back to the original state.
</p>
</p>


== Advantages of Migration ==
== Disadvantages of Automation ==
<ol>
<ul>
<li>You can identify each migration and know when it has taken place.</li>
<li>Creating an automated test is more time-consuming and expensive than running it once manually. </li>
<li>Some migrations can also be rolled back. We can specify what the roll back procedure is.</li>
<li>Proficiency is required to write the automation test scripts.</li>
<li>Migrations can be managed with version control.</li>
<li>Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.</li>
<li>Automation – Automate things to be done which makes it reliably repeatable.  For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>
<li>Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be re-recorded or replaced by a new test script.</li>
</ol>
<li>Maintenance of test data files is difficult, if the test script tests more screens.</li>
 
</ul>
== Disadvantages of Migration ==
<ol>
<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>
<li>The whole discussion about Migration suggest that they are dangerous to use on production database. One should backup the database first and then use migrations on the production database.</li>
<li>Most databases do not prop up the rolling back of data definition language(DDL)<ref>http://en.wikipedia.org/wiki/Data_definition_language</ref> statements.</li>
</ol>


== Conclusion ==
== Conclusion ==
<p>
<p>
In a nutshell, Database Migration is a very efficient way to handle the discrepancies that occur between databases. i.e. changes made in one database not reflecting in other. It is a convenient way to alter the database in structured and organized manner. Rails migrations are mostly similar to version control of databases.  Rails migrations are database independent but SQL scripts are not.
In a nut shell, Test automation is the process of writing a computer program to do testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly and repeatedly. This is often the most cost effective method for software products that have a long maintenance life, because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time. There are many tools available to automate testing.
</p>
</p>


Line 223: Line 81:
== Additional Reading ==
== Additional Reading ==
<ol>
<ol>
<li>http://guides.rubyonrails.org/migrations.html#anatomy-of-a-migration</li>
<li>http://www.tutorialspoint.com/software_testing/testing_types.htm</li>
<li>http://www.ibm.com/developerworks/java/library/j-cb08156/index.html</li>
<li>http://support.smartbear.com/articles/testcomplete/manager-overview/</li>
<li>http://jacqueschirag.wordpress.com/2007/08/12/rants-about-rails-database-migrations</li>
<li>http://www.buzzle.com/articles/manual-testing-tutorial.html</li>
<li>http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html</li>
<li>http://www.outsourcebazaar.com/index_Article_AutomatedVsManualTesing.html</li>
<li>Agile Web Development With Rails, Fourth Edition, Sam Rooby, Dave Thomas, David Heinemeier Hansson.</li>
<li>http://www.aptest.com/tools.html</li>
</ol>
</ol>

Latest revision as of 02:02, 27 October 2012

Automated Testing

Every software development group tests its products but still defects are always present in delivered software. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> always try to catch these errors but they always creep in and they often reappear, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. Automation Testing is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. Usually, test automation involves automating a manual process already in existence that uses a formalized testing process. There are many tools available to perform automation testing today.

Manual Testing

Manual testing is the method in which testing of the software is done manually. In this type of testing, a tester acts like an end-user. All features of a software are tested to know if the behavior of the software is exactly according to the expectations of the customer. The tester uses a test plan<ref>http://testingsoftware.blogspot.com/2005/11/what-is-test-plan_30.html</ref>. Other than test plan, there are test cases<ref>http://softwaretestingfundamentals.com/test-case/</ref> written, which are used for implementing the test plan. Although manual tests may find many defects in a software application, it is a laborious and time consuming process. In addition, it may not be effective in finding certain classes of defects.

Why Automation Testing

Automated software testing has long been considered critical for big software development organizations but is often thought to be too expensive or difficult for smaller companies to implement. Many companies are recognizing the importance of automating the work of testers and including the auto-test as part of the regular build process. The results of the automatic test are seen as a measure of the current quality of the software. Combined with a code coverage tool it gives the answer to the all-elusive question: "How much of my code is currently running ok?."

The below factors make automation testing important:

Automated Testing is both Time and Money Saving

During software development cycle, software tests have to be repeated very often to ensure quality. Software tests need to be repeated, every time a change in the source code happens. For each release of the software it may be tested on all supported operating systems<ref>http://www.computerhope.com/os.htm</ref> and hardware configurations. Repeating these tests manually is costly and time consuming. Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. The time to run these repetitive tests is reduced from days to hours by automated software testing. Saving the time directly translates into cost savings.

Improves Accuracy

Manual testers are bound to make mistakes during monotonous manual testing. With Automated tests, the probability of errors occuring is relatively low. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results.

Increases Test Coverage

Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are difficult to be conducted manually can be run unattended in Automation testing. They can even be run on multiple computers with different configurations. Automated software tests can easily execute thousands of different complex test cases during every test run providing test coverage that is impossible with manual tests.

Automated Software Testing Does What Manual Testing Cannot

A controlled web application test with thousands of users cannot be performed by even the largest software departments. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with network or web software<ref>http://en.wikipedia.org/wiki/Category:Web_software</ref> and applications.

Helps Developers and Testers

Shared automated tests can be used by developers to find problems quickly before sending the code for Quality assurance. Tests would run automatically whenever source code changes are checked in and in case of failure error reports would be automatically sent to the team or the developer. Features like these save developers time and increase their confidence.

Improves Team Morale

Automating repetitive tasks with automated software testing gives the project team , time to spend on more challenging and rewarding projects. Team members improve their skill sets and confidence and, in turn, pass those gains on to their organization.

Approaches to Test Automation

  • Code-driven testing: With the help of a variety of input arguments, the public (usually) interfaces to classes, modules or libraries are tested to validate that the results that are returned are correct.
  • Graphical user interface testing: User interface events such as keystrokes and mouse clicks are generated by testing framework, and observes the changes that result in the user interface and validates whether the observable behavior of the program is correct or not.

    • Code-driven testing

    Code driven test automation is a key feature of agile software development<ref>http://en.wikipedia.org/wiki/Agile_software_development</ref>, where it is known as test-driven development (TDD)<ref>http://en.wikipedia.org/wiki/Test-driven_development</ref>. Unit tests are written to define the functionality before the code is written. Only when all tests pass is the code considered complete. Proponents argue that it produces software that is both more reliable and less costly than code that is tested by manual exploration. It is considered more reliable because the code coverage is better, and because it is run constantly during development rather than once at the end of a waterfall development cycle. The developer discovers defects immediately upon making a change, when it is least expensive to fix. Finally, code refactoring<ref>http://refactoring.com/</ref> is safer; transforming the code into a simpler form with less code duplication, but equivalent behavior, is much less likely to introduce new defects.

    Graphical User Interface (GUI) testing

    A variation on this type of tool is for testing of web sites. Here, web page is the “interface”. Such a framework utilizes entirely different techniques because it is reading HTML instead of observing window events. Another variation is scriptless test automation that does not use record and playback, but instead builds a model of the Application Under Test (AUT) and then enables the tester to create test cases by simply editing the test parameters and conditions. Test-case maintenance is easy, as there is no code to maintain .As the AUT changes the software objects can simply be re-learned or added. It can be applied to any GUI-based software application. The problem with this model is that AUT is actually implemented using test scripts, which have to be constantly maintained whenever there's change to the AUT.

What To Automate

Test automation tools can be expensive, and are usually employed in combination with manual testing. Hence It is not possible to automate everything in the Software. Software systems which are used by a large amount of users simultaneously should be automated. For example, automating test that tests the combinatorial interactions of interdependent parameters at the API level or through the UI makes a lot of sense because the number of combinatorial tests for any complex feature would take much longer to test manually as compared to a 'data-driven' automated test.

When To Automate

Automated tests, that are written before the code, capture the intention of the code, inform design decisions, provide rapid feedback and let the developers know when the code is done. Test automation could also be written after the system code has been written so the automation has to cope with less change. But Automated tests that are written after the code do not directly inform the design nor do they provide rapid feedback. If these tests help us build a better product then they should be written before the code. If we are using automation to do exploratory testing and we intend to throw the automation code away afterwards then we can write the tests later.

Automation Tools

Tools are a driving agent for an automation process. Tools are specifically designed to target some particular test environment, such as Windows and web automation tools, etc. However, an automation framework is an infrastructure that provides the solution where different tools can do their job in a unified manner. This provides a common platform for the automation engineer. Below are few automation tools that are being used in the software industry today:

  • HP QuickTest Professional
  • IBM Rational Functional Tester
  • Rational robot
  • WATIR
  • Selenium

HP QuickTest Professional is produced by HP Software Division, IBM Rational Functional Tester and Rational robot are produced by IBM Rational and WATIR and Selenium are open source. There are also many other tools which are available.

Disadvantages of Automation

  • Creating an automated test is more time-consuming and expensive than running it once manually.
  • Proficiency is required to write the automation test scripts.
  • Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.
  • Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be re-recorded or replaced by a new test script.
  • Maintenance of test data files is difficult, if the test script tests more screens.

Conclusion

In a nut shell, Test automation is the process of writing a computer program to do testing that would otherwise need to be done manually. Once tests have been automated, they can be run quickly and repeatedly. This is often the most cost effective method for software products that have a long maintenance life, because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time. There are many tools available to automate testing.

References

<references/>

Additional Reading

  1. http://www.tutorialspoint.com/software_testing/testing_types.htm
  2. http://support.smartbear.com/articles/testcomplete/manager-overview/
  3. http://www.buzzle.com/articles/manual-testing-tutorial.html
  4. http://www.outsourcebazaar.com/index_Article_AutomatedVsManualTesing.html
  5. http://www.aptest.com/tools.html
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=Wiki-2b&oldid=68857"