Author Archives: Andon S

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.