Your SlideShare is downloading. ×
Automate your functional testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Automate your functional testing

228
views

Published on

Published in: Software, Technology, Education

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
228
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Automate your Functional Testing ©2014 YASUI Tsutomu aka yattom
  • 2. What is Functional Testing? Functional testing is a quality assurance (QA) process[1] and a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like in white-box testing).[2] Functional Testing usually describes what the system does. http://en.wikipedia.org/wiki/Functional_testing
  • 3. What is YOUR Functional Testing? <Insert your definition here!>
  • 4. What is Functional Testing again? • quality assurance (QA) process • black box testing • bases its test cases on the specifications • test by feeding input and examining the output • internal program structure is rarely considered
  • 5. In today’s context … What. test against web UI or API (input and output) Why. to see it functions as specified and expected Who. engineers, but from the viewpoint of the spec holder (= producers, directors) Where. on your dev PC When. anytime after development is done How. automation!
  • 6. You Need Test Cases • A set of test cases that validates a function – Enough, no more than enough – Coverage can be measured • We take a list of features (user stories / functions) and build test scenarios – What if there’s no such list? Scribble it from the working system!
  • 7. • Display list of search result • Sorted by score • Abstract of each results are shown • You can click to show the page • You can choose to translate • Show “https” clearly if the link is https • Show type of contents eg. PDF • Change keywords and search again • From dropdown you can choose “cache” “similar” “share” • Pagination • Internationalization
  • 8. Scenario Example 1. Access google.com 2. Enter keyword “automate functional testing” and do search 3. Display list of results in appropriate order 4. Read some abstracts 5. Change keyword “testing” to “test” and search again 6. Move to next page 7. Click the 3rd item and the page shows • Display list of search result • Sorted by score • Abstract of each results are shown • You can click to show the page • You can choose to translate • Show “https” clearly if the link is https • Show type of contents eg. PDF • Change keywords and search again • From dropdown you can choose “cache” “similar” “share” • Pagination
  • 9. Good Test Scenarios • SMART – Specific – they are explicitly defined and definite – Measurable – the result is observable and quantifiable – Achievable – they describe a realistic scenario – Relevant – they are related to the particular story – Time-bound – the result can be observed almost instantly (Gojko Adzic, “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” http://amzn.to/1iABAXT )
  • 10. Good Test Scenarios (contd.) • At first focus on the Happy Paths – Default scenario; typical and successful – No exceptions, no errors http://en.wikipedia.org/wiki/Happy_path • Mind maintainability! – Don’t be thorough too much – Don’t do too much – Don’t make it too long
  • 11. Who write test cases? Test case is: • Communication - between spec holders and engineers • Expectation – how spec holder thinks the system should work • Verification – engineers can verify the system’s functionality Who. engineers, but from the viewpoint of the spec holder (= producers , directors)
  • 12. What is YOUR Functional Testing? <Insert your definition here!>