Intelligent People. Uncommon Ideas.

Automated Testing vs Manual Testing

Manual Tests

• Coding Process with Manual Tests

 Write code
 Uploading the code to some place
 Build it
 Running the code manually (in many cases filling up forms etc step
by step)
 Check Log files, Database, External Services, Values of variable n
ames, Output on the screen etc
 If it does not work, repeat the above process

Creative Commons Attribution Share-alike 2

Automated Tests

• Coding Process with Automated Unit Tests

 Write one or more test cases
 Auto-compile and run to see the tests fail
 Write code to pass the tests
 Auto-compile and run
 If tests fail -> make appropriate modifications
 If tests pass -> repeat for next method
• Coding Process with Automated Functional Tests
 Finish writing code (with all unit tests passing)
 Write a Functional Test using any tool
 Auto-compile and run
 If tests fail -> make appropriate modifications
 If tests pass -> move ahead

Creative Commons Attribution Share-alike 3

Automated Tests vs Manual Tests

• Effort and Cost

 Lets assume 6 test cases
 Effort required to run all 6 manually => 10 min
 Effort required to write unit tests for all 6 cases => 10 min
 Effort required to run unit tests for all 6 cases => < 1 min
 Number of testing iterations => 5
 Total manual testing time => 50 min
 Total unit testing time => 10 min
Manual Test
Release Manual Test Auto Test Cumulative

1 10 10 10

2 10 0 20

3 10 0 30

4 10 0 40

5 10 0 50

Creative Commons Attribution Share-alike 4

Automated Tests vs Manual Tests

• Effort and Cost

 Adding incremental Unit test cases is cheaper than adding increme
ntal Manual Test Cases
• Eg registerDomain
 Case 1: Register a .com domain with all correct fields
 Case 2: Register a .com domain with an invalid nameserver

Creative Commons Attribution Share-alike 5

Automated Tests vs Manual Tests

• Manual Testing is boring

 Noone wants to keep filling the same forms
 There is nothing new to learn when one tests manually
 People tend to neglect running manual tests
 Noone maintains a list of the tests required to be run if they are ma
nual tests
• Automated Tests on the other hand are code
 They are fun and challenging to write
 One has to carefully think of design for reusability and coverage
 They require analytical and reasoning skills
 They represent contribution that is usable in the future

Creative Commons Attribution Share-alike 6

Automated Tests vs Manual Tests

• Manual Testing is not reusable

 The effort required is the same each time
 One cannot reuse a Manual Test
• Automated Tests are completely reusable
 IMPORTANT: One needs to setup a Continuous Integration Server
, a common Code Repository and a organization structure
 Once written the Automated Tests form a part of the codebase
 They can be reused without any additional effort for the lifetime of t
he Project

Creative Commons Attribution Share-alike 7

Automated Tests vs Manual Tests

• Manual Tests provide limited Visibility and have to be Rep

eated 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
• Automated Tests provide global visibility
 Developers, Tech Leads and Management can login and see Test
Results
 No additional effort required by any of them to see the software wo
rks!!
Manual Manual Manual Dev Manual T Total Manual
Testing by De Testing by Tea Testing by Mg Total Manual est Test
Release v m Leads mt Testing Auto Test Cumulative Cumulative
1 10 5 3 18 10 10 18
2 10 5 3 18 0 20 36
3 10 5 3 18 0 30 54
4 10 5 3 18 0 40 72
5 10 5 3 18 0 50 90

Creative Commons Attribution Share-alike 8

Automated Tests vs Manual Tests

• Manual Testing ends up being an Integration Test

 In a typical manual test it is very difficult to test a single unit
 In most circumstances you end up checking the unit alongwith bac
kend services
 Introduces fragility – if something else breaks the manual test brea
ks
• Automated Tests can have varying scopes
 One can test a unit (class / method), a module, a system etc

Creative Commons Attribution Share-alike 9

Automated Tests vs Manual Tests

• Manual Testing requires complex Manual Setup and Tear

Down
 Can involve frequently running db queries
 Can involve making changes to backend servers
 Steps become more complex with multiple dependent test cases
• Automated Tests can have varying scopes and require les
s complex setup and teardown
 Unit Tests have external dependencies mocked – so no setup / tea
rdown required
 Setup and Tear down are automated in Functional Tests using fra
mework support

Creative Commons Attribution Share-alike 10

Automated Tests vs Manual Tests

• Manual Testing has a high risk of missing out on somethin

g
 Each time a developer runs manual tests it is likely he will miss out
on an important test case
 New developers may have no clue about the battery of tests to be r
un
• Automated Tests have zero risk of missing out a pre-decid
ed test
 Once a Test becomes a part of Continuous Integration – it will run
without someone having to remember to run it

Creative Commons Attribution Share-alike 11

Automated Tests vs Manual Tests

• Manual Tests do not drive design

 Manual tests are run post-facto and hence only drive bug-patching
• Automated Tests and TDD / Test-First development drive
design
 Writing a Unit test first clarifies the requirement and influences desi
gn
 Writing Unit Tests with Mock Objects etc forces clean design and s
egregation through abstraction / interfaces / polymorphism etc

Creative Commons Attribution Share-alike 12

Automated Tests vs Manual Tests

• Manual Tests do not provide a safety-net

 Manual tests are run post-facto and hence only drive bug-patching
• Automated Tests provide a safety-net for refactoring / addi
tions
 Even New developers who have never touched the code can be co
nfident about making changes

Creative Commons Attribution Share-alike 13

Automated Tests vs Manual Tests

• Manual Tests have no training value

• Automated Tests act as documentation
 Reading a set of Unit Tests clarifies the purpose of a codebase
 They provide a clear contract and define the requirement
 They provide visibility into different use cases and expected results
 A new developer can understand a piece of code much more by lo
oking at Unit Tests than by looking at the code
 Unit Tests define the expected behavior of the code

Creative Commons Attribution Share-alike 14

Automated Tests vs Manual Tests

• Manual Tests create crazy code clutter

 Most manual testing involves –
• System.outs to check values of variable names
• Useless log file entries in app server, db server etc
• Cause code / log / console clutter
 if then(s), flag based logging, event based log entries etc
• Slows down the application
• Automated Tests reduce code clutter to zero
 Log file entries / System.outs are replaced by assertions in test cod
e
 Even if specific console / log entries are needed they can reside in
the test and not in the code
 Keep a live application / logs / console clutter-free and fast

Creative Commons Attribution Share-alike 15

Summary

1. Manual Tests take more Effort and Cost more than Autom
ated Test to write and run
2. Manual Testing is boring
3. Automated Tests are reusable
4. Manual Tests provide limited Visibility and have to be Rep
eated by all Stakeholders
5. Automated Tests can have varying scopes and can test si
ngle units of code by Mocking the dependencies
6. Automated tests may require less complex setup and tear
down

Creative Commons Attribution Share-alike 16

Summary

7. Automated Testing ensures you dont miss out on running

a test
8. Automated Testing can actually enforce and drive clean d
esign 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/lo
gs

Creative Commons Attribution Share-alike 17

Why do people not write Automated Tests

• Initial learning curve

 Understanding Unit Testing Frameworks and Functional Testing Fr
ameworks
 Understanding Continuous Integration and effective usage of it
 Understanding and learning Code Coverage Tools
 Figuring out how to organize the tests
 How to create Mock Objects?
 How to automate the running of the tests each time?
 Where to commit the tests?
• Am I really going to be working on this same module again
?
• Will my tests be re-used? If not what is the point?

Creative Commons Attribution Share-alike 18

Why do people not write Automated Tests

• Solution
 Spend time during First Release to freeze / design / implement -
• A Code Repository structure that incorporates Unit Tests and Function
al 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
 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 t
hem, committing them and linking them in CI

Creative Commons Attribution Share-alike 19

Why do people not write Automated Tests

• Don’t give up
 If you come across a hurdle, pair
 Make sure you complete your testing responsibility
• Check Code Coverage
 Use code coverage tools while coding and post-coding to check pa
rts of your code that are covered by tests

Creative Commons Attribution Share-alike 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)

Creative Commons Attribution Share-alike 21

Best Practices

• You must use a unit testing frameworks (there’s one for ev

ery platform)
• You must have an auto-build process, a CI server, auto-te
sting 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 Serve
r run tests selectively
• Tests must be committed alongwith code

Creative Commons Attribution Share-alike 22

Best Practices

• Organize the tests properly

• If you do not commit Tests they are not reusable and the r
educed effort advantage is lost

Creative Commons Attribution Share-alike 23