API Testing -- HTTP and REST, the difference exist

From the last post in this series, I'm continuing to share my learning and till day practice in testing the APIs. In this context, this post will have information on below mentioned.

• HTTP and REST, the difference exist

I wish to keep the below topics in the next post so that it helps in gaining the clarity of RESTful APIs with different protocols.

• The usual in the WEB API testing
• The "not thought about" in testing APIs -- Web and RESTful

HTTP and REST, the difference exist

HTTP is a protocol and one of the way to transfer the files. This will connect the pages in the World Wide Web. While the REST is set of constraints documented for the architectural style for web. This constraints are to ensure the scalability and ease use of the web systems.

The common understanding for an engineer is the web runs on HTTP and so the RESTful API.Yes, the REST API will use and can use HTTP as communicating and transfer protocol. This understanding is common because one might see HTTP being used often and most times with RESTful APIs. But it is not mandate that RESTful API should always use HTTP only.  The RESTful API can also be for FTP, SMTP and other protocols to transfer and communicate.

Now let me reiterate this line again from above paragraph,

"While the REST is set of constraints documented for the architectural style for web"

The web has many protocols to communicate and transfer; one among them is the HTTP. So now we know the idea that RESTful API can be designed and used for any communicating and transfer protocols other than HTTP.

Then the difference between REST and HTTP to mention here in short is as below:

1. HTTP API is the any API which makes use of HTTP as its protocol.
2. RESTful API sticks on to all REST constraints which are described in the dissertation of Roy Fielding.

Usually the 'Web API' is referred to HTTP API. However it is good to seek clarity when one hears "it is the Web API".  That means, SOAP can also be HTTP API if it uses HTTP. If the SOAP can use HTTP for transfer and communication, then RESTful API are possible for SOAP as well over HTTP, isn't it?  This looks to be tricky in understanding but it is not. Spending sometime to ponder and explore on this area, will give the clarity in learning this.

IME Test Model: Briefing the "RICH VIP MUST PLUG AND HE PUTS LOCK"

On posting this, I had not covered what this mnemonic means.  In this post, I will cover briefly about each factors that comprises this mnemonic. An IME app do not necessarily have to be an app always which will be installed on the mobile phone by the user. It can be a SDK which will be bundled in to the OEM as well.  Testing an IME app and testing the IME's SDK is similar? If wished to share your thoughts and ideas to program and test the same, please do share.

What is this mnemonic ?

RICH VIP MUST PLUG AND HE PUTS LOCK

Before briefing it out, I want to tell -- this will help a programmer, tester, product owner or anyone who is interested in building one such mobile application. It helps by being a pointer to provide an idea to categorize the development (programming + testing + segmenting the app to market & users) of IME. Thereby, it becomes easier to assess them technically as well for the context. I can derive the ideas to test the IME and IME's SDK technically from this test model and assist in the better development of it.

1. Response 
2. Interruption
3. Content & Key Layouts
4. HIG
5. View
6. Intent Search & Discover
7. Permission
8. Messages
9. UI
10. Settings
11. Type of IME
12. Platform & Specific Device
13. Languages
14. Users
15. Gestures
16. Action
17. Notification
18. Dictionary
19. Help
20. Error Handling
21. Prediction
22. Updates
23. Trails
24. Sound
25. Locale
26. Orientation
27. Cursor
28. Keys

Briefing the 28's of IME Test Model

In this section, I will convey few lines among what I have thought about each factors while I was identifying and picked it.  To make it clear, this cannot be treated solely as the test ideas and design ideas for programming; rather, it will be a pointer to start and influence in building the ideas to test and program.

• Response -- Anywhere in the IME app and where it is used in conjunction with other apps, you have a thought how 'fast' or 'slow' is the response, then find the tests and know how to do it. Anyways, what is that I'm going to get by learning this? Know it!

• Interruption -- Not the small one for sure. What is the interruption to you and what can be part of interruption in mobile technology? It is beyond the calls, messages and the other common words you and I have heard. How good and bad the IME app can be on the device if this is handled well? This can be a good start after knowing what is an interruption.

• Content & Key Layouts -- It looks simple yet it is not the simplest by the way. If the IME is built for global users or specific to region, what is that I need to have in the content and key layouts?  Right from visual design to interaction design to data architecture to mapping it to the mobile hardware with locale selected, is for sure a interesting programming and testing. Think what's in your ideas to test and automate it.

• HIG -- What do the platform's HIG guideline tell about design pattern, IME design and what you unlearn and learn about the design you were visualizing, seeing and wanting? Having the reference of this definitely helps when you want users to use the IME you are thinking, programming and testing.  Do you know if your platform allows to build one IME app? Is that right !?

• View -- It is beyond the UI, if you thought it is the UI.  For an app programmer, it can hold her or his breath if the View is not handled. Know the different kinds of Views available in the IME and how to program for it to hold relevant data (re-read Content & Key Layouts) and process it by using it as input and output.

• Intent Search & Discover -- The mobility is evolved and so the Artificial Intelligence with the chat bots and service API integration. Your IME has got this efficiency and feature or wanting to have it? Then know how to consider programming constraint and testing the same. It is no more just the app; it is with-in and from-outside-inside of the app together with AI. Discover your tests to test it.  Hey what's the version of mobile OS version you are targeting to support and build the IME ?

• Permission -- What is the permission you are thinking about to grant as a user for the keypad on your mobile app? Do the permissions you want to grant and that you do not want to grant for IME app - consume your device's resources (why?), slows your interaction with the task you do in the device (why?), and puts you in state of embarrassment and annoying (why?) Then think about the permission for your IME you are building and testing. Wait, are you happy with the permission you ask from the user for using this IME morally, technically and ethically?

• Messages -- What you get  in your thoughts when said the 'message' in an software mobile app? Ponder over and touch Ben Simo's FAILURE heuristic when required consistently. The message looks to be as UI part but it is more from the behind the UI to the UI.  What messages are programmed in the IME app and localized to suite the context of app usage with locale of device? Besides the known error, warning, and info, what is the kind of other message I do not get known often? Is this taken care in the IME app?

• UI -- Not the mastering one for sure when it comes to app that supports different locale and language and several hardware configuration devices. Pattern is the key in keypad. The UI anywhere is not all about the visible UI aesthetics but it is more about the performance and fastness. How is the UI of your app is light and yet straight in delivering optimized expectation? What should be part of programming such UI? What are the tests I should be figuring out and sample to know the UI of the IME app?

• Settings -- How the setting changes of IME add to the factors that handles the device's service and intent? Besides the Settings functionality of the IME app or IME SDK, what I have to consider in programming and testing of it?

• Type of IME -- What's your IME type and how do you input the data? What are the different option it supports to provide the input to mobile device and apps?  How about an SDK here, forget about the IME mobile app. Now list out that should be handled in programming it and how to test the same. Is there a pattern in how the input is provided via IME?

• Platform & Specific Device -- How's the IME built specific to platform? How different can be the behavior of IME when there is a behavior specific to device and its software? How to program for such cases in handling behavior of IME? How to isolate, debug and test such behavior?

• Languages -- Language which IME claim to support, do device support that language? How the language's alphabet characters are rendered and shown? Does the construction of word in language looks similar to as and when human does it? How the mapping of keypad keys happen to language's alphabet character, symbol and other characters? UTF, the common word; but is that has to be considered when programming and testing here?

• Users -- I want to go beyond these - User Personas, User's Device and Accessibility. Not that I want to ignore them; I see there is much more than the above said. How can I identify and capture them in my test?  What is that specific support a user will get from the platform when providing the input, especially via IME? Okay, let me bring this thought here -- most say, they scaled and built the technology and app/product for customer engagement, do this app have that technology segment? This is just one thought. As this, I have much more where I can identify, derive my tests and see which are suitable to automate among them. Just to trigger a chained thought from the previous one, how about A/B strategy to read the user's priorities and mindset while using the IME? Then connecting it to the User Customized IME. How to test it and to have it in a app?

• Gestures -- Do you have list of gestures available and supported on your device and OS? As usual, the Gesture will be used by IME users. But what is that comes with gesture as a cost? How does that impact in device fragmentation space? How the gesture which you have set works in case bilingual and native keypad? Customized gestures do exist and how will I intimated when there is a confusion in gesture recognition by the app and device? To spice up a thought here, just think -- how the gestures make differences when the IME is used with a mobile app to input and when it is used to input on a mobile web as well. Any new gestures available via this IME which is unavailable till date? How to approach testing of gesture on different types of touch and display framework of platform if I'm bundling the IME SDK with OEM?

• Action -- The action keys available in the keypad, how do they get localized as and when the language is chosen? Also how it reflects when the locale of the device is changed.  Besides the functionality of such action keys, what can I consider in programming and testing of such keys? One example at UI level is, what should be the direction of arrows in action keys when it is being used with right to left language?  That was at UI level; if I had to figure out how the performance of the IME will be influenced by such keys, then what should I learn now?

• Notification -- On knowing the types of notification available in each platforms and how it appears, how do an IME app handle and show the notifications. Do this notification need a trigger from the app internals to appear by user action? What is the contribution of it in battery drain if the notification uses the wakelocks?

• Dictionary -- It comes with the size either the user start adding the words to it or the products comes with limited words. Size matters on the mobile phone in space utilization aspect? If user can add the words to the dictionary, then the space utilization grows. What if the IME app supports for bilingual and multilingual? Then space occupied in the dictionary file for different language's word differs? As well the dictionary can be downloaded and gets updated regularly. Do this have any effect on low end devices? What other tests and factors I have to consider when testing for the Dictionary apart for the functionality? Did you forget the the file type and format?

• Help -- In my opinion, the help section of IME is yet to become helpful especially when it comes to non-English language. For example, if the IME supports Indian language, how to use the keypad to type the words? Likewise, if it has to support different languages, then the pattern of using the keys in keypad to type the words in respective language, should be in the help section? This is open to discussion considering the context and who will the targeted audience of the IME app.

• Error Handling -- I will use Ben Simo's FAILURE mnemonic here. I'm learning to use in UI and non-UI mode. Coming to the error handling, I understand 'error' is when a user perform actions which is not valid as per the product and the product has to inform the user without causing any lose to customer in product's context. Few devices may not support languages which is supported by the IME. While such language is used by the user, how will this be handled by the IME app?  This is one example. As this, figuring out the error handling in each factors mentioned here, helps.

• Prediction -- Before I talk about how to test the prediction mechanism, how to bring in assistance of accessibility to the prediction feature in the IME app? Let us think on this. Now, the prediction in-turn builds the size of the dictionary and the predicted candidate words come from the dictionary which I have and building in the device. That said, dictionary and the content in it for the language chosen plays a role! IME app has to learn the user's typing and words usage style in the chosen language. That is not simple but doable and testable. The prediction comes from the user's input to the dictionary; if she or he does it incorrectly then the prediction that appears later will also be incorrect. Understanding the key:word and value:frequency in the algorithm used, helps.  Insertion, deletion, transposition, alternations, and duplicates all will come into picture as user types and sees the prediction in candidate words/list.  How do I program this? It has to be quick in calculation so I see the prediction appearing and changing as I type. How do I test this? What I have look for performance factor when the dictionary size is growing with words for a language which will contribute to the prediction?

• Updates -- When updating the app, do the content of app which is available now will be retained or get cleared? The content of the IME app such as dictionary and languages should be untouched unless the app wants to sanitize and clean it as well. Post update how these contents will be used by the app?  This is one instance of thought among the several what we think while building and testing the IME app.

• Trails -- The UI mark trails left after using keys and swyping over keys, do introduce any problem on the device?  If it is low end device, then such trails of gestures and keypad usage cause CPU and GPU overload?  This is one such thought to consider in programming and testing the IME with trails sign feature.  As this collect and build the list to consider for programming and testing this factor. What about the trails when using the Indian languages and other similar languages?

• Sound -- Build the dictionary file size and test for keypad sound and other that you hear when using the IME app. Do you see any difference in speed and how the sound is heard to you? As this figure out what needs to be considered when programming and testing for the Sound factor with the IME app.

• Locale -- On changing the locale on the device how the IME app changes accordingly? What has to be considered for programming for an IME app with locale? How to test it? For example, I have changed locale to reflect right to left language in the device and toggling between the bilingual in the IME app. How will the IME app have to behave with locale's context and selected mode context in app? As this, build the list to test for locale factor. Interestingly this clubs with most factors here very closely and will have dependency.

• Orientation -- Orientation do have contribution in screen overdrawing, GPU rendering and memory consumed. Apart from this, how do the keypad look and evolve for different languages? How the keys and different UI areas look in the keypad with different language in different orientation of different screen size? This is a start area to explore.  Any key get missed in portrait mode but not in the landscape mode?

• Cursor -- Do this remain consistent with device standard or will it have standard of the IME app? How the cursor assist here in accessibility? For example, the cursor blinks. Is there a case, where the cursor stands still without blinking? How do the IME behaves in that case? Moving of the cursor in the word you are typing or typed, changes the prediction shown? These are few examples to consider in programming and testing of cursor in the IME app.

• Keys -- The visible part of the IME app to a user. Contextualizing the keys is one feature with respect to locale, language chosen and input being entered. How the key has to manage its space within it to show different characters when primary and secondary are enabled? Colors, themes, and Settings leave any influence on the keys? For example, the touch area sensitivity on keys.  As these what are the factors do I need to consider in programming and the testing the keys of IME in different screen size and hardware devices?