Archive for November 2018

Day 02: Brief History of Exploratory Testing

New Goal in My Learning University:  Boost Your Testing Super Powers to Exploratory Testing.






My Learning Notes -  Day 02: Brief History of Exploratory Testing

It was a long process to learn about History of Exploratory Testing.

The story on ET is the most important learning I’ve have done today.


References:   
http://www.satisfice.com/blog/archives/1504


                                   Believe Yourself. Reinvent Yourself. 

Posted in , , , | Leave a comment

Day 01: What is Exploratory Testing

New Goal in My Learning University:  Boost Your Testing Super Powers to Exploratory Testing.






My Learning Notes -  Day 01: What is Exploratory Testing?


What is Exploratory Testing?


Exploratory Testing is an approach to Software Testing. It is sometimes more productive than Scripted Testing.
We at least unconsciously perform exploratory testing.


How do we perform Exploratory Testing?
In Exploratory Testing, We test design and test execution at the same time. Not defined in Advance.
In Scripted Testing, We predefined procedures (Manual / Automated).


Exploratory Testing != Adhoc Testing
Exploratory Testing is done in a specific way to verify specific facts. Exploratory Testing is a structured Process.
Whereas Adhoc Testing is not done in a specific way nor to verify specific facts. Adhoc Testing is unstructured Process.


Term “Exploratory Testing” is coined by Cem Kaner in Testing Computer Software as Thoughtful approach to Adhoc-Testing.


Balance Exploratory Testing and Scripted Testing.


Most of the time next test we do, will be influenced based on previous test result. Here, We are doing Exploratory Testing by incorporating test ideas into tests.
We take scripted testing approach, when we are not sure how do we need to test.

My Approach of Testing:

  • Learn about the Story (Epic/Bug/User Story)
  • If there are any technical concepts: Spend time learning about the Technical Details, write personal notes, ask developers if any questions.
  • If there are topics related to Product: Learn about the Product from the documentation available, write personal notes, ask developers if any questions.
  • Then preparing my test ideas and review with the developer to check if my approach is correct or any details needs to be added.
  • Then Exploring the product and test accordingly. 
  • Then writing the testing notes / report.
  • Then write the scripted tests to use it in future (or) others to refer.



When we do Exploratory Testing?
Exploratory Testing is useful in situations where we need to perform complex testing and little is known on the product.
Exploratory Testing is performed when we want to go beyond the obvious.


Reference: http://www.satisfice.com/articles/what_is_et.shtml


Do not trust your employer to take care of your career. Only you can do that. Your employer just wants to get value out of you, not help you achieve your ambitions.

Posted in , , , | Leave a comment

Day 17: Find 5 API testing experts to follow on Twitter.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.



It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

17th Challenge: Find 5 API testing experts to follow on Twitter.




I follow below 5 API Testing experts on Twitter.
  • Lorinda Brandon - https://twitter.com/lindybrandon (First Person I met and Learnt about API and API Testing) ๐Ÿ‘ˆ
  • Matthias Biehl - https://twitter.com/mattbiehl (Author and Advisor at API University)
  • Mike Amundsen - https://twitter.com/mamund (Director of API Academy)
  • Ole Lensmar - https://twitter.com/olensmar  (SOAPUI Creator)
  • Abhinav Asthana - https://twitter.com/a85  (Postman Creator)
             

                   What are you doing to get better? Invest in yourself.

Posted in , , , | Leave a comment

Day 14: Compare and contrast mocking, stubbing, and faking.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.



It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

14th Challenge: Compare and contrast mocking, stubbing, and faking.



It is one of the challenging topic to understand related to Unit Testing.
  • Test Doubles (Mocks, Stubs, Fakes etc.), are an essential tool when writing unit tests. 
  • A test double is an object that can stand in for a real object in a test, similar to how a stunt double stands in for an actor in a movie for dangerous scenes. 
  • The most common types of test doubles are stubs, mocks, and fakes.
  • Their purpose is to be substituted for dependencies of the class or classes under test.
  • Example: E-mail services are a canonical example - we don't want to send out real e-mails every time we run our tests!
  • Example: we probably don't want to connect to a real database somewhere in our unit tests, as that would make them dependent on that database's state. There are solutions that let you control them from your unit tests - in-memory databases like H2
  •  All Test Doubles can be created using very popular, library: Mockito.
The various types of Test Doubles
  • stub is an artificial object, which has no logic, and only returns what you tell it to return. 
  • Stubs can be used when you need an object to return specific values in order to get your code under test into a certain state. 
  • While it's usually easy to write stubs by hand, using a mocking framework is often a convenient way to reduce boilerplate.
  • Example: To always return the same value, or to throw an exception when called with a particular argument.

  • Mock is an object which records the methods called on it, and allows later verification that the recorded calls match some criteria, such as: the order of calls, their number, the values of parameters, and the absence of any unexpected calls. Test should fail if it's not called that way. 
  • This way of asserting is called behavior verification, which means checking the correctness of a class through analyzing its interactions - in contrast to state verification, which uses the object's state to achieve that.
  • Mocks are used to test interactions between objects, and are useful in cases where there are no other visible state changes or return results that you can verify. 
  • Example: If your code reads from disk and you want to ensure that it doesn't do more than one disk read, you can use a mock to verify that the method that does the read is only called once.

  • A Fake doesn’t use a mocking framework: it’s a lightweight implementation of an API that behaves like the real implementation, but isn't suitable for production (e.g. an in-memory database). 
  • Fakes can be used when you can't use a real implementation in your test.
  • Example: If the real implementation is too slow or it talks over the network. 
  • You shouldn't need to write your own fakes often since fakes should usually be created and maintained by the person or team that owns the real implementation.
Summary:

  • Stubs: Fake responses to method calls
  • Mocks: Expectations about method calls, verifying them, and faking returning a value
  • Fake: Objects with a working implementation that is useful for tests


References:
  1. https://www.endoflineblog.com/testing-with-doubles-or-why-mocks-are-stupid-part-1
  2. https://martinfowler.com/articles/mocksArentStubs.html
  3. https://testing.googleblog.com/2013/07/testing-on-toilet-know-your-test-doubles.html
  4. https://youtu.be/pMmXJcDLUFA
  5. https://club.ministryoftesting.com/t/30-days-of-api-testing-day-14-compare-and-contrast-mocking-stubbing-and-faking/20140/7


Posted in , , , | Leave a comment

Day 13: Contribute to the list of API automation tools over on The Club and share your experiences with using them.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.



It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

13th Challenge: Contribute to the list of API automation tools over on The Club and share your experiences with using them.



I am not into Automation of (UI/API) levels. So, this challenge helped me to uncover different tools used in Testing the APIs.

I always reach out to this website to learn related to Automation.
Joe writes posts which focuses on Automation - https://www.joecolantonio.com 

There are different API Testing tools which we can use to Automate API Testing.


  • Postman ๐Ÿ‘ˆ
  • Karate DSL ๐Ÿ‘ˆ
  • Soap UI ๐Ÿ‘ˆ
  • HTTPMaster Express
  • Rest-Assured ๐Ÿ‘ˆ
  • RestSharp
  • RestConsole
  • RoboHydra Server
  • Hippie-Swagger
  • WebInject
  • Pyresttest
  • Airborne
  • Unirest
  • Mockbin
  • Citrus Framework
  • ZeroCode
  • Katalon Studio ๐Ÿ‘ˆ
  • JMeter
  • Tavern
  • Chakram
  • RestBird
  • Fiddler



References: 

Ask your WHY. Find out what is your purpose and goal to learn a new thing.

Posted in , , , | Leave a comment

Day 12: Share what skills a team needs to succeed with API testing.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.




It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

12th Challenge: Share what skills a team needs to succeed with API testing.




While I have started learning about APIs and API Testing, while working at Unilog.

Below are the skills a Team/Team Members needs to have to succeed with API Testing.


  • Have Curiosity to Learn and Research.
  • Able to understand Business Requirements with Functional Requirements
  • Able to Collaborate and Communicate with Developers
  • Able to Read the API Documentation if readily available (or) Find them Online.
  • Testing Skills and Mindset how to Test with various conditions (rationally/logically).
  • Able to Plan the testing activity and Inform the relevant stakeholders (internal/external) about how the testing will be approached and Ask for feedback.
  • Have knowledge on SQL and Able to perform Queries (simple) to validate the information.
  • Have knowledge on How HTTP Works.
  • Have Knowledge about JSON and XML. (Basics)
  • Have Knowledge on REST vs SOAP. and Find out what APIs we are going to Test. 
  • Have Knowledge on API Testing Tools. Example - SOAP UI, POSTMAN, SWAGGER
  • Ablility to decide what tools we could use for API Testing.
  • Have Knowledge to use Web Developer Tools.
  • Additional: Have Knowledge on Fiddler, Charles, Fiddler.
  • From Danny Dainton: We should have Knowledge on Scripting. (Javascript) for Writing Tests on Postman.
  • From Yogitha (Ex-Colleague in Unilog): We should have knowledge on Groovy Scripts.
  • Having Knowledge about API Security. Security of APIs is essential.
  • Mentoring/Teaching the team/stakeholders on How the testing has been performed. (Remember: Not everyone will be able to know How testing is done)
  • Bonus: Be Open to Read/Learn about APIs Online/Books and how others are performing API Testing.

There are many things which I need to learn from the above list mentioned.

Set your goals high, and don't stop till you get there.


Posted in , , , | Leave a comment

Day 11: Learn about different types of API’s, share your findings.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

11th Challenge is Learn about different types of API’s, share your findings.




There are different views on Different Types of API's.

View #1:
APIs come in many shapes and sizes. Even when APIs may share a common resource, the likelihood that they are similar in functional.
We can organize API's into different meaningful groups.
Different Types Of APIs:
  • General Data - You can get at data across the platform, users, and resources.
  • Relative Data - You can get at data that is relative to a user, company, or specific account.
  • Static Data - The data doesn’t change too often, and will always remain fairly constant.
  • Evolving Data - The data changes on a regular basis, providing a reason to come back often.
  • Historical Data - Provides access to historical data, going back an X number of. years.
  • Service - The API is offered as a service, or is provided to extend a specific service.
  • Algorithmic - The API provides some sort of algorithmic functionality like ML, or otherwise.

Understanding the type of data an API provides is important to this classification. 
http://api.gallery.streamdata.io/ has 
39302 API paths classified into 869 topics.


Reference: https://apievangelist.com/2018/08/21/identifying-the-different-types-of-apis/


View #2:Based on the API business strategy and interface architecture, There are three different types of API's.

  • Private API's - 
A private API is an interface that opens parts of an organization’s backend data and application functionality for use by developers working within (or contractors working for) that organization.


Managing a private API program may sound easy: interfaces are only exposed to internal developers, reducing security risks; API designers have direct access to these developers, making it easier to create dev-friendly interfaces. However, it is important to remember that exposing software interface always creates a range of security and management challenges.
  • Open API's
An open APIs is an interface that has been designed to be easily accessible by the wider population of Web and mobile developers. This means an open API may be used both by developers inside the organization that published the API or by any developers outside that organization who wish to register for access to the interface.

Therefore, for business managers and interface designers alike, the key goal should be to increase both the quantity and quality of API usage. This will mean targeting a specific dev audience, delivering an interface and accompanying documentation designed to meet that audience’s preferences and conducting targeted outreach/education activities.

With many third-party client apps active in the field, it can be very challenging to ensure that interface updates do not break application functionality.
  • Partner API's

A partner API is a hybrid form of the open and private interface models. This kind of API is usually implemented to support applications built by developers within an organization that has an existing relationship with the API publisher. This means that business managers and interface designers will have knowledge of and direct access to client application developers.

While this will certainly ease the process of designing and implementing an API, it must be noted that publishing a partner APIs comes with its own set of challenges. Many of these challenges arise from the fact that – although managers and designers will have some access to client developers, they lack direct influence or authority over these devs.


Reference: https://www.apiacademy.co/lessons/2015/04/api-strategy-lesson-201-private-apis-vs-open-apis


Other Views:

While reading the Topic Thread - https://club.ministryoftesting.com/t/30-days-of-api-testing-day-11-learn-about-different-types-of-api-s-share-your-findings/20047/3 , I have learnt below details.


Reference: https://ffeathers.wordpress.com/2014/02/16/api-types/

Reference: https://www.mulesoft.com/lp/ebook/api/restbook

Note: If you are working with APIs, find out which type of API you are currently working with from the list.


Ask yourself if what you're doing today is getting you closer to where you want to be tomorrow.

Posted in , , , | Leave a comment

Day 10: Share your favourite API testing tools and why.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

10th Challenge is Share your favourite API testing tools and why.




In this blogpost, I have written about Tools that I have used and My Favorite API Testing Tools.

When I started my career at Unilog, We had Internally Developed tool "EclipseTest" to make requests for Epicor Eclipse ERP. That was the starting point for me to learn about APIs.


Then I had worked on SOAP Webservices which interacts with Infor SX.E ERP.
Here, I had been introduced to SOAP UI.

SOAPUI Tool: ๐Ÿ‘
I have used Open Source version. It was very useful in testing the SOAP Webservices.




Then I had worked on REST APIs as part of Product Development.
Here, I had tried multiple tools while learning through online tutorials to find out which would help me in doing my tasks.


Advanced REST client:  (Chrome App)
https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo
Note: Now, This application is deprecated by Google.

POSTMAN REST Client: (Chrome App)

It is very useful tool and It has lots of features inbuilt.
  • It's Simple GUI and Features such as Saving the API Calls in a collections.
  • History of API Requests made.
  • Sharing the API Requests or Collections to Team Members.
  • You can sign into Postman and All Collections are saved in the Cloud.


POSTMAN: (Native App) ๐Ÿ‘

Recently, Postman Team encourages to use Native App than Chrome App.

Download: https://www.getpostman.com/apps


I need to learn more about Postman Tool.



Chrome Web Developer - Network Tab ๐Ÿ‘
This was very helpful in testing and knowing about the API Calls used on the web application.

The direction you are heading is more important than the speed you are moving to get there.

Posted in , , , | Leave a comment

Day 9: Share some tools we can use to discover what API calls our applications are making.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

9th Challenge is Share some tools we can use to discover what API calls our applications are making.



I have started working with API's in my earlier company (Unilog) in the year 2014-15. Where I have worked on SOAP Webservices which interacts with Ecommerce Web Application.

I was initially provided with WSDL, without prior knowledge of what it is. I have started going through SOAP UI Tutorials to learn How and What it interacts. (https://www.soapui.org/soapui-101-beginners-guide-api-testing.html) 

Used API Documentation of ERP as a basis to learn about API Calls and functionality.


Later learnt about usage of Web Developer Tools - Network tab. This provides lots of information on what calls (HTTP/API) does applications make when loaded on the Browser.

There are other tools: 
Web Sniffer - Chrome Addon - Helps to View all HTTP Requests and Responses sent between the Web browser and the Webserver. 




Wizdler - Chrome Addon - Recognizes WSDL information on the page to show you the available services and operations. (Learnt about this today)


WSDL: http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl


The Chrome extension provides details of Available Webservices and Operations.


  'Success is no accident. It is hard work, perseverance, learning, studying, sacrifice and most of all, love of what you are doing or learning to do'

Posted in , , , | Leave a comment

Day 8: Explore the API thread on The Club and contribute to the conversations.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

Eight Challenge is Explore the API thread on The Club and contribute to the conversations.




There are lots of Questions and Conversations on API and Testing.
https://club.ministryoftesting.com/c/all-testing-talk/api



This provides access to the Threads, helps to understand and have different ideas on Testing.   



I have contributed to the conversations on below thread.

https://club.ministryoftesting.com/t/need-to-learn-soapui/16286/7

If you believe in yourself and have dedication and pride - and never quit, you'll be a winner. ...

Posted in , , , | Leave a comment

Day 7: Complete exercise one over at The Club using popular API testing tools such as Postman, SoapUI, and API Fortress

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

Seventh Challenge is Complete Exercise one over at The Club using popular API testing tools such as Postman, SoapUI, and API Fortress.



Goal

Execute some simple API calls using as many tools as possible!

Objectives

  1. Send a GET and POST request
  2. Gain exposure to many API testing tools

Exercise

Choose an API testing tool such as API FortressPostmanSoapUI Paw or perhaps a different one.

Complete the GET and POST call on a test API.


Example

Using https://automationintesting.online created by Mark Winteringham and Richard, do the following:
{
 "username": "admin",
 "password": "password"
}

Share

Post your experiences with the tools you use below.
If you used a different API post the calls you did so others can try them.


Experiences

I have used API Fortress tool for the first time. 
It has lots of features in it. 

GET Method:


POST Method:




Also, I have tried Postman tool, which I have been using since last two years.
I find it user-friendly in using this tool.

I have created a collection as: AutomationInTesting, where all API Calls are saved in it.

GET Method:



POST Method:


Paw Tool : This is available for Mac OS. Will try out this tool in future challenges.
SOAP UI Tool:   This tool is available for Windows OS. Will try out this in future challenges. 



Get off the hamster wheel and start adding value! - Huib Schoots & Alex Schladebeck

Posted in , , , | Leave a comment

Day 6: Read and share an interesting blog post on API testing.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.


It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

Sixth Challenge is Read and share an interesting blog post on API testing.


          Sharing will enrich everyone with more knowledge.

I will actually share couple of posts which help in learning. 

a. Danny Dainton's GitHub Post on All Things Postman https://github.com/DannyDainton/All-Things-Postman

b. Recent blogpost by Anne-Marie Charrett 
https://mavericktester.com/2018/11/05/rest-apis-written-by-women/

This blogpost includes collation of posts written female software craftspeople.

Please do check out them, there are plenty of interesting blogposts.



Ministry of Testing Discussion Thread:  https://club.ministryoftesting.com/t/30-days-of-api-testing-day-6-interesting-blog-post-on-api-testing/19595/18

Posted in , , , | Leave a comment