Reading Time: 1 minute
In this post I will explain how simple change in testing environment influenced my testing of simple feature.
Feature is rather simple, tweet something interesting from the application. As this feature is tested, I was creating automated script for it. This feature is important for my client, so I decided that it should be part of regression testing suite.
I developed script for Chrome, and I also decided to check it using Firefox. Remember that in RIMGEA we learned that G stands for Generalize. We need to test our feature by changing the environment, in this case browser itself.
And in Firefox script failed! Why? Because Firefox tweet feature has one extra step in domain of twitter application.
It is clear that Firefox requires one extra button click. Since prior to that click, user clicks on “Log in and tweet” button, this is not consistent with that button. User expects that with one click he does two actions, log in to twitter and tweet that item.
With this post I amplified on real case how important is to vary your testing environment because in that way you could find interesting issues within the application.
Reading Time: 1 minute
In this post I will explain my heuristic how I solved issue that was indicated with misleading error message.
Error message was very simple: in order to be able to log in to our site, cookies must be enabled in your browser.
Cookies are pieces of information that also contain session information for your website. Using them, you do not need to enter username/password for every page of the site.
The problem was that cookies were enabled in my browser. Error message itself was wrong. Developer put this message because he only knew that cookies could be filtered in browser. Better message would be:
“We did not received cookie with session for this site. Something filters your cookie.”
My heuristic was, who can also filter cookies? And I remembered that my firewall has that option. I unchecked that option, and that was it.
The issue here is that I kept try to login, after I checked misleading error message instructions. In order to save your precious time, think about your problem. You will definitely learn something new.
Reading Time: 2 minutes
In this post I will describe what I learned when search application feature failed.
Currently I have following testing mission: write executable specification in cucumber for all features of my client’s web application.
By executable specification I mean following ruby gems:
- page objects
- selenium webdriver
While I was running cucumber features for application search feature, one of automated test failed. Replicating the issue by “hand”, I realized that problem is with application itself, not in my automated check code.
Search just stopped working on integration and production environments. There was no user interface error displayed, but http 500 that I discovered using network tab in Chrome developer tools. I started to investigate how search feature was implemented. I used codebase stored in github repository and realized that application connects to elasticsearch (key value pairs) in order to return requested data.
Application uses Heroku infrastructure, so I first observed heroku application log:
`heroku logs -t -a app_name`
With that I also confirmed that search error is related to elasticsearch availability.
Application infrastructure also uses Bugsnag tool. It is very useful, because every application exception is logged in web application with all important variables values at the time of exception. Elasticsearch was provided as Heroku plugin. There was elasticsearch provider ticket reporter, with very useful feature. I started entering ticket summary by copy/pasting exception text. And ticket tool found out that that type of issues was reported in the past. I also got information that at that time, elasticsearch infrastructure was not available because of provider maintenance work.
In order to conclude. Application that I am testing does not have extensive architecture document, but in agile environment this is not needed. Because application uses cloud architecture provider, Heroku. With few clicks in Heroku admin interface, I got all the needed information about application search infrastructure. By testing search feature that failed, I learned about application architecture infrastructure. I identified important application risk, that elasticsearch provider will do maintenance work that will last for some time and maintenance work will not be announced!