Announcement for Zagreb STC #16 meetup

Reading Time: 1 minute

We are announcing our #16 meet up that will be held on next Wednesday, July 2nd, at 18.00 in Sheridan’s Irish Pub, Savska 36. Sponsor of this event is Toptal.
As we meet in Irish pub, first part of our meet up will be about beer testing. You will have a chance to learn how to properly test the beer, because this activity will be demonstrated by professionals, founders of first Croatian Craft Brewery, NovaRunda.
Second part will be about software testing. We will test your

software testing knowledge in first Zagreb STC quiz!
Please confirm you attendance at Meetup platform.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

CRUD bug taxonomies

Reading Time: 2 minutes

Taxonomy is the practice and science (study) of classification of things and concepts, including the principles that underlie such classification [source Wikipedia]. First time when I herd of how to apply taxonomy in software testing was in BBST Test Design course. You can find more details in Dr. Cem Kaner paper, Bug Taxonomies: Use Them to Generate Better Tests.

In my testing I often have to test CRUD functionality. I searched for CRUD (create, retrieve, update, delete) bug taxonomy list, but Google did not list any relevant result.

In this post I will try to do bug taxonomy for CRUD acronym. CRUD acronym is often used and I think that many testers would found that list very useful. In the end, I will map CRUD acronym on REST API methods.

In this example we have object with mandatory and optional attributes. One of the attributes must have unique value. Client side could create any Object (no any check is performed) and server has to do all checks. Context of bug taxonomy are object attribute values.

Create object:

  • missing mandatory attribute
  • attribute does not belong to object
  • duplicate attribute
  • wrong attribute value type
  • wrong attribute value range
  • wrong attribute value format
  • existing value for unique attribute value

Retrieve object:

  • missing unique attribute value
  • unique attribute value does not exist
  • wrong type of unique attribute value
  • missing attribute in response

Update object:

  • missing unique attribute value
  • unique attribute value does not exist
  • update of unique attribute value to existing value
  • wrong type of unique attribute value
  • duplicate attribute
  • wrong attribute value type
  • wrong attribute value range
  • wrong attribute value format
  • attribute does not belong to object

    Delete object:

    • missing unique attribute value
    • unique attribute value does not exist
    • wrong type of unique attribute value
    • object already deleted

    Notice the redundancy in Retrieve, Update and Delete.

    This could be easily mapped to REST API:
    Create -> POST
    Retrieve -> GET
    Update -> PUT
    Delete -> DELETE

    When I start testing RSET API, I first automate tests for CRUD bug taxonomy. But that taxonomy must be also used by project management in order to negotiate REST API protocol. For every object, we must know:

    • attributes
    • mandatory attributes
    • unique attributes
    • attribute value type
    • attribute value range
    • attribute value format

    Otherwise,  RSET API could easily be used for malicious data manipulation. If you found that I missed some bug taxonomy, please let me know and I will add it to the list.

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

    How to properly check result of orderby method using random data?

    Reading Time: 1 minute

    In current project we are testing api endpoints that are developed using OData protocol. Microsoft implemented framework that implements Odata protocol and it helps experienced developers to expose system data very quickly and efficiently.

    We are developing regression test suite for Odata REST api endpoints using following technology stack:

    • Ruby
    • httpclient gem
    • rspec gem


    One of important features of regression test suite is robustness on application data changes. In this post I will present evolution of check for orderby Odata filter. We first improperly designed that check making it not robust on application data changes.

    Here is first, not data robust version:

    it “default orderby” do
            response = @api_client.get @customers_list_url, query={“$orderby” => “Name”, “$top” => 2}, ‘Cookie’ => @cookie
            json_response = parse_json response.content
            expect(json_response[‘value’][0][‘Name’]).to eq ‘Game of Thrones’ 
            expect(json_response[‘value’][1][‘Name’]).to eq ‘Lord of the Rings’
    end

    and second version, robust on data changes:

    it “default orderby” do
            response = @api_client.get @customers_list_url, query={“$orderby” => “Name”, “$top” => 2}, ‘Cookie’ => @cookie
            json_response = parse_json response.content
            expect(json_response[‘value’][0][‘Name’]).to be <= json_response[‘value’][1][‘Name’]
    end

    In your automated check, always check for what feature actually do, do not check for hardcoded test data values that are result values of the feature. 

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather