OneStopTesting - Quality Testing Jobs, eBooks, Articles, FAQs, Training Institutes, Testing Software, Testing downloads, testing news, testing tools, learn testing, manual testing, automated testing, load runner, winrunner, test director, silk test, STLC

Forum| Contact Us| Testimonials| Sitemap| Employee Referrals| News| Articles| Feedback| Enquiry
 
Testing Resources
 
  • Testing Articles
  • Testing Books
  • Testing Certification
  • Testing FAQs
  • Testing Downloads
  • Testing Interview Questions
  • Career In Software Testing
  • Testing Jobs
  • Testing Job Consultants
  • Testing News
  • Testing Training Institutes
  •  
    Fundamentals
     
  • Introduction
  • Designing Test Cases
  • Developing Test Cases
  • Writing Test Cases
  • Test Case Templates
  • Purpose
  • What Is a Good Test Case?
  • Test Specifications
  • UML
  • Scenario Testing
  • Test Script
  • Test Summary Report
  • Test Data
  • Defect Tracking
  •  
    Software testing
     
  • Testing Forum
  • Introduction
  • Testing Start Process
  • Testing Stop Process
  • Testing Strategy
  • Risk Analysis
  • Software Listings
  • Test Metrics
  • Release Life Cycle
  • Interoperability Testing
  • Extreme Programming
  • Cyclomatic Complexity
  • Equivalence Partitioning
  • Error Guessing
  • Boundary Value Analysis
  • Traceability Matrix
  •  
    SDLC Models
     
  • Introduction
  • Waterfall Model
  • Iterative Model
  • V-Model
  • Spiral Model
  • Big Bang Model
  • RAD Model
  • Prototyping Model
  •  
    Software Testing Types
     
  • Static Testing
  • Dynamic Testing
  • Blackbox Testing
  • Whitebox Testing
  • Unit Testing
  • Requirements Testing
  • Regression Testing
  • Error Handling Testing
  • Manual support Testing
  • Intersystem Testing
  • Control Testing
  • Parallel Testing
  • Volume Testing
  • Stress Testing
  • Performance Testing
  • Agile Testing
  • Localization Testing
  • Globalization Testing
  • Internationalization Testing
  •  
    Test Plan
     
  • Introduction
  • Test Plan Development
  • Test Plan Template
  • Regional Differences
  • Criticism
  • Hardware Development
  • IEEE 829-1998
  • Testing Without a TestPlan
  •  
    Code Coverage
     
  • Introduction
  • Measures
  • Working
  • Statement Coverage
  • Branch Coverage
  • Path Coverage
  • Coverage criteria
  • Code coverage in practice
  • Tools
  • Features
  •  
    Quality Management
     
  • Introduction
  • Components
  • Capability Maturity Model
  • CMMI
  • Six Sigma
  •  
    Project Management
     
  • Introduction
  • PM Activities
  • Project Control Variables
  • PM Methodology
  • PM Phases
  • PM Templates
  • Agile PM
  •  
    Automated Testing Tools
     
  • Quick Test Professional
  • WinRunner
  • LoadRunner
  • Test Director
  • Silk Test
  • Test Partner
  • Rational Robot
  •  
    Performance Testing Tools
     
  • Apache JMeter
  • Rational Performance Tester
  • LoadRunner
  • NeoLoad
  • WAPT
  • WebLOAD
  • Loadster
  • OpenSTA
  • LoadUI
  • Appvance
  • Loadstorm
  • LoadImpact
  • QEngine
  • Httperf
  • CloudTest
  •  
    Languages
     
  • Perl Testing
  • Python Testing
  • JUnit Testing
  • Unix Shell Scripting
  •  
    Automation Framework
     
  • Introduction
  • Keyword-driven Testing
  • Data-driven Testing
  •  
    Configuration Management
     
  • History
  • What is CM?
  • Meaning of CM
  • Graphically Representation
  • Traditional CM
  • CM Activities
  • Tools
  •  
    Articles
     
  • What Is Software Testing?
  • Effective Defect Reports
  • Software Security
  • Tracking Defects
  • Bug Report
  • Web Testing
  • Exploratory Testing
  • Good Test Case
  • Write a Test
  • Code Coverage
  • WinRunner vs. QuickTest
  • Web Testing Tools
  • Automated Testing
  • Testing Estimation Process
  • Quality Assurance
  • The Interview Guide
  • Upgrade Path Testing
  • Priority and Severity of Bug
  • Three Questions About Bug
  •    
     
    Home » Testing Articles » Automated Testing Articles » How to Write Good Acceptance Tests

    How to Write Good Acceptance Tests

    A D V E R T I S E M E N T


    So you want to learn how to write good acceptance tests? There's only one way, let's write some.

    This is a practical example that is designed to help beginners write clear and easily maintainable acceptance tests.

    Our System

    We are BOG, "Bank Of Gus" and we have a Loan Approval Processing System that takes in input some data regarding the applying customer and his loan requirements, as output it returns either Accept (the customer will be given the loan) or Reject (the customer will not be given the loan).

    The marketing manager wants to start selling a new Holiday Loan and produces the following user story:

    As a Customer
    I want to borrow money from the bank
    So that I can go on Holiday and enjoy myself

    Acceptance Criteria:
    In order to get the Holiday Loan approved
    1) The Customer must be 18 or older
    2) The Customer's salary must be > �20,000.00
    3) The Customer Time in employment must be >= 6 months
    4) The Loan amount < (Customer salary)/5

    The Loan Application Form (UI) exists already, the Loan Application Form calls a REST service that is what we are now updating to allow for this new product. The UI is also ready and able to display our outcome, a big green Approved or red Rejected string based on what our service returns.

    The Loan Application Form looks something like this:

    I am eager to start writing acceptance tests, and I start writing down the first one without thinking much, (please don't get bored by the first test, I promise it gets better, this is the worst one you'll see)

    I'm going to use a rich celebrity for my first test, let's try to make things interesting.

    first_test

    Auch� 16 steps for ONLY ONE TEST, by the time I do all the necessary scenarios with boundary analysis I am going to have a document the size of the iTunes licence agreement and this is only the start!

    HINT #1: Focus on "what" you are testing and not on "how"

    First of all, do I really need to say that I go to a page and that I fill each field and that I push a button? That's the "how" I use the app, it is not necessarily "what" I do with it. The "what" is "a customer is applying for a loan".

    Could I generalize and get to a concept of a customer applying for a loan? YES
    Do I really need to fill the web form to exercise the code I am writing/testing? NO
    Can I abstract it, use a test double and call directly my code? YES

    Focus on what you are testing, you are not testing the UI, you are testing the loan approval logic! You don't need to exercise it through the UI. You would exercise it through the UI only if you were testing the UI.

    Ok let's use a test double. I create a mock with the data as per example above and will use it for testing, but, it's not making writing the test any easier Sad

    I could do something like

    second_test

    Besides the fact that I abstracted the how (the customer entering strings and clicking buttons) with the what (the customer applying for a loan) I still have a very messy test with loads of detail and quite difficult to read and maintain.

    It looks slightly better but not good enough, I couldn't even fit all the data on one line and I took the lazy option of adding ellipses, but in the real world ellipses don't work, they can't be automated, imagine repeating this for all the scenarios I need to cover, it's a disaster, what am I going to do?

    HINT #2: Eliminate irrelevant Detail

    Do I really need to know the name of the customer to decide if I want to approve his loan? NO
    Do I need to know his sex? NO
    Shall I continue asking rethorical questions? NO

    The only important variables for designing the logic of my application are the ones described in the acceptance criteria, look back: Age, Salary, Time in employment, Loan amount

    OK this looks promising, let me try to write the original test using only those.

    third_test

    This looks definitely better, it exposes only the parameters that have an impact on the loan approval logic, it is more readable and while reading it I have some idea of how the system will work, that's better isn't it?

    OK let's write all the scenarios to comply with the acceptance criteria using boundary analysis, equivalence partitioning and other test techniques.

    fourth_test

    Auch again� I haven't even started looking at the cases where the loan will be rejected and I have already 4 very similar tests that will bore to tears the Product Owner, so much that he won't speak to me for a month, what can I do?

    HINT #3: Consolidate similar tests with readable tables

    I know of a very useful way of writing tests that are very similar without repeating myself over and over and make the readers fall asleep. It's called scenario outline and I'm not going to explain in words what it does, I'm just going to show it to you because I know that looking at it you won't require any explanation.

    sixth_test

    Wow, this looks much better! One test of 3 lines and examples that cover all the possible scenarios! Do you remember when you needed 16 lines of unnecessary detail to describe only the first line in the examples above? This is certainly a an improvement, more readable, more maintainable and all around 100 times better than the original one.

    Also, look at it closely; it gives the business an amazing power of using this test in the future to make changes! Imagine that we end up in a credit crunch (again) and the banks want to tighten the way they lend money. So they decide to increase the minimum salary to 30,000 and the minimum time in employment to 12 months for example.

    A quick copy and paste + small refactor and we get:

    seventh_test

    That's quite powerful isn't it?

    Now if I was a tester and I wanted to be picky I would tell you that there are plenty of scenarios that have not been tested and a full decision table should be created to give good coverage.

    Yes you guessed, I am a picky tester, let's build the decision table for the Credit Crunch scenario.

    HINT #4: Use decision tables and boundary analysis to get high coverage

    How do I build a decision table?
    First you need to know what your variables are and what "interesting values" need to be considered.

    What's an "interesting" value? They are all the values a variable can take that might make the logic fail. Generally they are Boundary values.

    Ok back to the Credit crunch requirements:

    2) Customer salary must be > �30,000.00
    3) Customer Time in employment must be >= 12 months

    The salary variable, for example has 3 interesting values: 29,999.99, 30,000.00, 30.000.01
    Respectively, left boundary, boundary and right boundary (some observers might say that 0 and -1 could be interesting values as well, I agree but for the purpose of this exercise we won't consider them).

    How about time in employment, the interesting values are: 11, 12, 13

    OK I have 2 variables each with 3 "interesting" values (or dimensions)

    I can immediately calculate the amount of tests I need to get 100% coverage with all possible combinations of "interesting" values.

    NumberOfTests = dim(salary)*dim(time_in_employment) = 3*3=9

    9 test cases will cover all possible paths using all combinations of "interesting" values.

    Let's build the decision table, and guess what? It can be expressed as a test!

    eight_test

    1 test, 3 steps, 9 examples, 100% boundary analysis coverage, in English, readable, maintainable, clearly expressing the business value delivered, what do you want more?

    One last thing; you might be in a situation where decision tables with many variables with large dimensions will require hundreds or even thousands of test cases. If these tests are run at the unit level I wouldn't worry too much about the run time but if for instance you are testing some Javascript logic and are able to do so only through the UI this will require a long time to execute and not represent a good Return On Investment.

    What can you do? There are many ways of reducing the amount of tests to run still maintaining relevant coverage. One technique is called pairwise testing, it is very straight forward and uses tools to quickly identify the highest risk tests that should be included and eliminate the ones with less risk associated. Pairwise testing is outside the scope of this document, If you are interested in knowing more about it,



    More Automated Testing Articles
    Previous 1 2 3 4 5 6 7 8 9 10 11 Next



    discussionDiscussion Center
    Discuss
    Discuss

    Query

    Feedback
    Yahoo Groups
    Y! Group
    Sirfdosti Groups
    Sirfdosti
    Contact Us
    Contact

    Looking for Software Testing eBooks and Interview Questions? Join now and get it FREE!
     
    A D V E R T I S E M E N T
       
       

    Members Login


    Email ID:
    Password:


    Forgot Password
    New User
       
       
    Testing Interview Questions
  • General Testing
  • Automation Testing
  • Manual Testing
  • Software Development Life Cycle
  • Software Testing Life Cycle
  • Testing Models
  • Automated Testing Tools
  • Silk Test
  • Win Runner
  •    
       
    Testing Highlights

  • Software Testing Ebooks
  • Testing Jobs
  • Testing Frequently Asked Questions
  • Testing News
  • Testing Interview Questions
  • Testing Jobs
  • Testing Companies
  • Testing Job Consultants
  • ISTQB Certification Questions
  •    
       
    Interview Questions

  • WinRunner
  • LoadRunner
  • SilkTest
  • TestDirector
  • General Testing Questions
  •    
       
    Resources

  • Testing Forum
  • Downloads
  • E-Books
  • Testing Jobs
  • Testing Interview Questions
  • Testing Tools Questions
  • Testing Jobs
  • A-Z Knowledge
  •    
    Planning
    for
    Study ABROAD ?


    Study Abroad


    Vyom Network : Free SMS, GRE, GMAT, MBA | Online Exams | Freshers Jobs | Software Downloads | Programming & Source Codes | Free eBooks | Job Interview Questions | Free Tutorials | Jokes, Songs, Fun | Free Classifieds | Free Recipes | Bangalore Info | GATE Preparation | MBA Preparation | Free SAP Training
    Privacy Policy | Terms and Conditions
    Sitemap | Sitemap (XML)
    Job Interview Questions | Placement Papers | SMS Jokes | C++ Interview Questions | C Interview Questions | Web Hosting
    German | French | Portugese | Italian