Stroking the Gestures in Gesturs 1.1

I practiced testing on the gestures stroke in the application Gesturs 1.1. This was the application provided to test as part of STePIN Testers Arena's 4th contest. I covered various aspects of tests on different quality criteria.

The tests conducted for gesture stroke is interesting and it gave me new perspective of learning. It was a two hour session where I touring the product to understand and how it calculates and executes the gestures stroked by me.  The coverage area spanned from install, operation and post uninstallation.

The observations I made in a session is shared in this report. It spans to coverage area from pre-installation, installation, configuration, in-built gestures, customized gestures, gesture stroking, stroking velocity, stroke angular details, stroke length, gesture reversal and gesture threshold area.  Explored the product on functionality and response time criteria. 

From the experience part of use, I felt very much uncomfortable to use Windows in the usual way I do using the'Windows' key in keyboard. The Windows key was not functional when Gesturs process is active in Activity List of Windows.  Using the product in laptop on trackpad with no mouse, is another area where the experiences varies on different versions of Windows OS. 

That is, Windows 7 and Windows 8 has different uncomfortable experience when used it with Gesturs 1.1. Whatever it is, it was not helping me to make my task quicker. I have worked on how the Gesturs can be designed to make the experiences better. While I worked on this, I worked on the Test Architecture of the same and it is impressive for me when I tested it under the perspectives I thought of at the time of testing it. As known, the product is still in the primitive state of development and it will get better as it evolves. Wishing the best to development teams.

The testability factor for gesture testing was not straight simple. But, it had clues to learn and test about it. I used few tools available in Windows OS to make my learning quicker during the session. There was a need to build second layer of testability to understand Gestur's gestures functioning. Once I did that, it became easier for me to proceed with the testing.

The interesting test which I did not carry out is working on different screen resolution and varied hardware acceleration for gesture stroking and response.

Functional Interoperability Tests for Image Uploading in Greenshot with Imgur

Interoperability, that exists everywhere where the data or information is exchanged or interpreted is an interesting area which does not get identified usually. Software applications also have this area in them. The communication and exchange of data between two components of same system or of different system is challenging from different perspectives.

The challenge lists keeps growing as I continue to learn about it. The primary challenge what I have seen so far in my practice is, not understanding and knowing that there is a communication here to accomplish and how it is being communicated and translated in each request and response. For example, how does the command 'netstat' or 'tracert' or 'ping' functions in MS DOS and produces the information which is requested? How does the horn button when pressed in the bike or car produces the sound?

That beautiful is the interoperability is and most times it is not considered for study in the daily software testing practice. In this blog post, I'm sharing the functional interoperability test which Bhavana and myself practiced for Greenshot and Imgur to upload the captured image.  The context framed in this session notes is an assumption which I framed out for testing practice. 

Covering the Imgur API limitations and rules, is one of the interesting part of this testing. Likewise, we understood how the API limitations can cause confusion at UI level and functionality. The report can be found here.

Getting Pythoned!

The tester in me keeps encouraging to learn, practice and test better each time. When I get that energy from the tester in me, he always said and tell, 'you need to assist your testing better and find the ways of helping yourself.'  I keep facing the challenges in the utilities I'm building to assist my testing; during this time, the voice of tester in me became very much prominent.

The aspiring interest of me is being skilled enough to program for helping my testing. Tester in me identified this area and kept saying to work on this with dedication. I have started my programming practice by selecting Python. While I'm doing this, I need a mentor for me. I have my friends who can help me very well here. But, I'm thinking of their context and practicing in silent mode from few months.

I'm reporting to tester in me, what did I do. 

• I configured Eclipse Standard SDK Kepler Service R2 20140224-0627 with Python 2.7.6  interpreter
• Configured PyDev Python plugin with Eclipse and created the workspace
• I wrote a simple program with a function to accept value and process a defined constant. Executed the program to make sure the configuration of IDE functions

I wanted and want to practice Python programming using a text file i.e. Notepad. Doing so, it will help me to become aware of syntax, debugging and language specifics. Also, I had a wish to practice programming using Eclipse from long time. Hence I started to use Eclipse for my Python programming practice. I'm enjoying, while I test the program I write.

Claims Testing for Google Chrome's Tweet Deck Extension

I don't want to publish this blog post with 140 characters and neither I do not claim that it will be so. I use Twitter and this is my Twitter ID @testinggarage. I have seen, how Twitter has evolved in its web version, Tweet Deck version and Android version. In this evolvement it has undergone change in experience, functionality and how it fits into various areas in public world need.

While being so, it is making claims for what it is now by telling the changes it brings in. That is, the claim is made for its present state, service or solution offer and experience. Now, we have one attribute of testing which looks at claims made by product and its server or solution to seeker.

I want to write in brief for what I understand for Claims Testing in one perspective. Hence the next five paragraphs will be about it. If wishing to go through the test report alone, go to last second paragraph by scrolling down the page a bit. Now, back to one of my views on Claims Testing in next paragraphs.

What is the claims and how it is related to testing? This question started to pound me when I heard this word six years back. For today I understand and see it in this way. 

• A product's solution or service exist. This existence itself is a claim.
• Each elements in this solution or service will have its own claims to meet for giving the intended service or solution.
• When I look from perspectives of testing
• looks like each attributes or quality criteria of a product is a claim when looked into it.
• For example, functionality of each components is a claim; performance of each component and product as a whole is a claim.
• I see two things when it comes to claims.
• Explicit -- which is made by product to who needs it and does not need it as well. For example, the requirement lines or document; advertisement; sales and marketing campaign content.
• Implicit -- this is expected by users and potential solution wanting person. For example, she should be able to use the product with ease by learning what it is.

Identify the claims is simple job. Yes, it might be simple with assumptions being made and available statements said regarding it. But, to understand the claims and actually identifying them, needs patience. And the tests conducted particularly for claims needs time. For this, time needing activity, I have witnessed most skip out from this test or lose focus while doing it. In other view, it is also this way -- software testing evaluates the claims of the product purpose, existence and its activities considering the environment of it.

I tell you from my little and limited testing practice experience, testing a product might look simple in a perspective; but, when the word 'claims' is added to testing and to tell 'claims testing', it is not a light task any more in whatever perspectives it is so. It spans to multiple dimensions and covering all of them is impossible for limited and fixed time we get for testing.

Then how to have the better coverage for context when explicitly said Claims Testing is done? How does the claim made by the coverage about Claims Testing is good enough for the context and what to consider for identifying the claims? This is a key question which misleads the tester, as per my observations so far. Hence stating the claims picked and in what specific context it is being evaluated, and having it mutually agreed with stakeholders helps.

As part of my testing practice, I picked Google Chrome's Tweet Deck extension for claims testing. Now, the key question to me was what will I test for claims? I picked up the changes made to Tweet Deck 3.5.5 and how it synchronizes with Twitter Web and Twitter's Android app. 

This was not simple one to start off. I was with a tester, who was observing what I was doing and had questions to me, for where I was heading to. This practice activity became so much intervened within itself, I enjoyed it. I took 2 hours for identifying and validating the claims. Later, I moved into second session in testing these identified claims (explicit) and started recognizing the implicit claims. These observations are recorded in this report. 

Though, I have spent around 6 hours of time on this exercise, still I see, the claims testing can go on. But I have to stop at a point on getting fair information based on the context need, and I stopped on assessing the accomplished coverage.

Plan to Digg and Explore the Digg Reader

I picked up this exercise posted by Weekend Testing Australia New Zealand (@WTANZ_) in Weekend Testing (@weekendtesting) on 14th Sep 2013.

The mission given to tester in this practice session is as below.

Create a test plan for digg.com and assume you were asked to test the new Digg Reader product. However the catch is: you only have 1 week to test the whole thing. If you only had one week to test the entire product, what would you test?

I had to understand what was the condition of Digg Reader product to proceed further considering the constraint of one week time. On studying what are the changes and risky areas in Digg Reader for that day's version, I came up with master strategy and initial plan to test the product. However, the strategy and plan keeps evolving as I test.

Looking at the context of product and testing need, I feel the functionality needed the tests to start and cover the other tests spanning to different quality criteria. This report is my session notes having the Test Plan for the given mission.