Automated Testing Vs Manual Testing
Automated Testing Vs Manual Testing
Manual Tests
Automated Tests
Case 1: Register a .com domain with all correct fields Case 2: Register a .com domain with an invalid nameserver
Manual Tests provide limited Visibility and have to be Repeated by all Stakeholders
Only the developer testing the code can see the results Tests have to be repeated by each stakeholder For eg Developer, Tech Lead, GM, Management
Release 1 2 3 4 5
Dev Manual Total Manual Total Manual Test Test Testing Auto Test Cumulative Cumulative 18 18 18 18 18 10 0 0 0 0 10 20 30 40 50 18 36 54 72 90
Automated Tests can have varying scopes and require less complex setup and teardown
Unit Tests have external dependencies mocked so no setup / teardown required Setup and Tear down are automated in Functional Tests using framework support
10
11
12
13
14
15
Summary
1.
Manual Tests take more Effort and Cost more than Automated Test to write and run Manual Testing is boring Automated Tests are reusable Manual Tests provide limited Visibility and have to be Repeated by all Stakeholders Automated Tests can have varying scopes and can test single units of code by Mocking the dependencies Automated tests may require less complex setup and teardown
2. 3. 4. 5.
6.
16
Summary
7.
Automated Testing ensures you dont miss out on running a test 8. Automated Testing can actually enforce and drive clean design decisions 9. Automated Tests provide a Safety Net for refactoring 10.Automated Tests have Training value 11.Automated Tests do not create clutter in code/console/logs
17
Am I really going to be working on this same module again? Will my tests be re-used? If not what is the point?
18
Solution
Spend time during First Release to freeze / design / implement A Code Repository structure that incorporates Unit Tests and
Designate Responsibility Each developer MUST write Unit tests for multiple use cases per unit Designate a specific Developer to write Functional Tests The developer who writes the tests is also responsible for organizing
them, committing them and linking them in CI Functional Tests A CI Server integrated with the release Unit Testing Framework (any xUnit framework) Functional Testing Tools (Sahi / Watir / Selenium / QTP etc) Code Coverage Tools (Clover) Testing guidelines and principles
19
20
What to Test
Unit Tests
Ideally do not cross class boundaries Definitely do not cross process-boundaries Write a unit test with multiple cases
Functional Tests
UI Tests using specific tools (Watir / Selenium / QTP / White etc) Tests one layer below the UI (Using APIs)
21
Best Practices
You must use a unit testing frameworks (theres one for every platform) You must have an auto-build process, a CI server, autotesting upon commits etc Unit Tests are locally during the day, and upon commit by CI Server Over a period of time you may want to have your CI Server run tests selectively Tests must be committed alongwith code
22
Best Practices
Organize the tests properly If you do not commit Tests they are not reusable and the reduced effort advantage is lost
23