Popularity on Twitter (for my blog tags)

I went to a good presentation on twitter tags in January by Kym Raines.

She showed us how to identify has tags that are popular using #HashTagBattle. The idea is that if you use the hashtag that more people use, the more your tweet can show up in people’s twitter searches (yes, some people search by hashtags). So I looked into it because a lurker like me should make the most out of the few tweets I make. I found that HashTagBattle uses a search engine called Topsy. Just for fun, I created a script to capture the popularity of the tags I use in this blog.

Script:

#in IRB
load 'hashcount.rb'
list = """ all the tags scraped out of my blog """
tags = list.split(" ")
tags.each do |tag|
  h = Hashcount.new(tag)
  puts "#{tag} : #{h.get(MONTH)}"
end

#hashcount.rb
require 'hpricot'
require 'mechanize'
MONTH = 'off tab-m'
class Hashcount
    URL = "http://topsy.com/s?"
    def initialize(hash)
        mech = Mechanize.new
        @doc = Hpricot(mech.get("http://topsy.com/s?q=%23#{hash}").body)
    end
    def get(t)
        xpath = %Q(//li[@class='xxxx']/a/span[@class='count'])
        begin
            return @doc.search(xpath.sub('xxxx',t))[0].inner_html
        rescue Exception => e
            # puts e.message             
        end
    end
end

And here is the output of them:

adjuster : 44
author : 19K
automatedtesting : 11
Automation : 3,006
books : 84K
brand : 23K
Bugzilla :
caine : 126
Change : 31K
character : 6,140
children : 30K
choose : 1,661
commitment : 5,058
communityservice : 1,716
competence : 167
Compuware : 104
Confidence : 8,212
Continuousintegration : 44
Cucumber : 2,914
Cucumber-JVM : 0
Culture : 40K
database : 3,837
decision : 1,791
delegates : 83
dictators : 218
ElasticSearch : 357
Exceptional : 316
experience : 6,955
exploratorytesting : 2
Functionaltesting : 4
future : 38K
Git : 5,368
Graphicaluserinterface : 2
grasshopper :
graylog2 : 6
HardWork : 27K
help : 129K
helpingothers : 333
interactiveautomation :
interest : 1,067
investigate : 197
IRB : 274
java : 29K
Jenkins : 449
JeremyLin : 373
job : 1M
Kids : 75K
Leader : 13K
leaders : 7,144
Leadership* : 59K
Learn : 11K
Libraries : 3,339
Library : 16K
Linux : 68K
listener : 228
manager : 19K
masterpo : 1
MongoDB : 2,790
NBA : 246K
NewYorkKnicks : 1,478
Opensource : 10K
Opportunity : 5,545
organization : 2,771
Organizations : 276
payitforward : 4,025
Perserverance : 169
planner : 2,509
practice : 14K
ProblemSolving : 408
problems : 12K
program : 5,688
pursuer : 1
recognition : 1,660
recognize : 1,541
Redmine : 112
reluctantleader : 0
Resistance : 2,759
Revisioncontrol : 0
rewarding : 372
Ruby* : 12K
RubyOnRails : 844
scripts : 1,210
servant : 493
Service : 17K
software : 28K
softwaredevelopment : 1,483
softwaretest : 19
Softwaretesting : 976
speaker : 2,599
Splunk : 273
success : 63K
team : 60K
testautomation : 78
testmanager : 17
TestStack : 0
testingautomationgeneratecases :
tests : 2,539
toolsupported :
Trac : 245
training : 41K
trust : 30K
Unittesting : 70
vendor : 429
vendortesttools :
vendortools :
victimofchanges : 1
VM(operatingsystem) : 1,364
WatirPodcast : 0

Note: When I scraped them, I removed the spaces from between words as is typical of twitter hash tags.

Developing Trust

“What did they say?” “That it’s supposed to work that way.” “And?” “I wasn’t sure what else to say. What do you think?” “I think that you need to develop some trust. First, develop some trust in yourself. Then develop some trust from the dev to you.” It’s a common conversation I have with junior testers. As testers, our goal should be to build trust. Trust enables us to our jobs.

photo credit: mikebaird via photopin cc

What is trust?

The asset most required in our jobs as software testers is trust. That is because trust is knowledge of a person or group. The currency of that knowledge is the combination of competence, character, and commitment.

The first, competence, is how well we can do our jobs. People may think we have character, but we I say a feature has a problem, do people believe that I know what I am talking about. Competence varies for all of us depending on the domain. I can know much about restful web services (Rest) and not know much about User Experiences (UX). Or somebody may trust my knowledge in Rest but not UX. I could understand the technologies used but lack understanding of the business use.

The second measure of trust is character. I consider character to cross domains. I guess that somebody could have a character weakness, for instance if they are a covered alcoholic, but not relevant for this kind of trust. Do people know you give an honest answer? That would be integrity. Do they know you see things through to the end, or do you drop things when you get resistance? That would be courage. Other character traits of a tester include ability to communicate, and dealing with ambiguity.

And the third measure of trust is commitment to causes. A person could be honest and earnest, but wouldn’t lift a finger to save a spider if they don’t like spiders. Others will trust me or not if I am dedicated to those values that the team shares. This can vary from place to place. I have worked where the tester was ‘supposed to be the police’, as well as places where the tester was supposed to describe the quality level to management so they could make a proper decision. Popular commitments in agile include delivering value to the customer, continuous improvement, engineering for current (not potential needs), and always-working software.

Why do We Need Trust?

We do not hear many arguments against trust. But we do not always hear for a call to gain trust. Without trust, everything is more expensive in both money and time. For example, terrorist attacks in Mumbai and New York in the past decade created new, more expensive agencies to combat the potential for attacks. I have personally witnessed the cost in time every time I travel from an American airport. The example is extreme, but it scales down to our work. For instance, if I am not trusted to create tests then I will have additional review processes, sign-offs, etc.

Without building that trust, even when the competence, character, and commitment are present, you will pay the no-trust taxes. In a new relationship, the trust must be built. An assumed trust, one that is assumed upon meeting, can be duplicitous – other assumptions come with it.

How do We Build Trust?

How to build trust isn’t a simple question. That comes having competence, character, and commitment. When the currency is low then we will find building trust difficult. Those things can grow in time. If we study our craft, if we study our domain, we will gain the competence that convince our stakeholders that we ‘know what we are doing.’ As we mature, we build character from making the right decisions. As we question our beliefs and motives, we develop the commitment that other respect.

On the other hand, we build trust from others as we improve ourselves. We work in various domains – we have different levels of knowledge in those areas. We start at different trust levels in our relationships. We work with people who have different general tendencies for trust based on their experiences. Domain risk also plays into trust. I will be careful no matter who I am working with to build a pacemaker.

Lowest Trust – When we work with somebody that does not trust us, deserved or not, we can build a foundation of that trust by being polite, and simply helping them. Do not ask questions except for those that will help you do the task correctly.

Low Trust – Learn about them. Questions should be inquiring but not challenging. Your interest in them, and sharing some common experiences. Though you should focus more on them. What are their motives for what they are working on? What are their commitments?

Medium Trust – When you are at good level of trust, you can make suggestions to help them. THEN BACK OFF. Expect them to ignore your suggestion. In the occasion that they take your suggestion, be available to answer questions about details. Success isn’t necessary, but a big investment into a failure can lower the trust level.

High Trust – Once you have a high level of trust, you can act on their behalf if you tell them appropriately about what is done. Give them a report on what you will do, what you have done. For those working on Agile teams, this can sound like a ‘standup meeting’.

Highest Trust – When you are at the highest level of trust, you can just act on behalf of somebody. You know their interests and how they would decide themselves.

You can be at different levels of trust at different times of a relationship. It can go up or down for various reasons. If you haven’t interacted with somebody for a while, you might treat the trust level as if it atrophied. If you are a hired expert, you can probably skip the lowest trust level and start somewhere else.

Planning to Be Trusted

By evaluating the trust levels that your stakeholders have in you, you can begin planning on how to build a higher level of trust. The work you do when implementing a trust-building plan will actually make you better and more trustworthy. That trust is a cornerstone to becoming more effective as a software tester.

Trust me.

 

Issue & Story Tracking

Everywhere that I’ve ever worked at had a defect tracking system, requirements system, and sometimes merged into one. Some were off the shelf, some were homemade, and others were services. I never felt the need to install one for work, but I did want to see what was involved with doing this, including how to integrate it with other products in the test stack.

I didn’t look around much for an open source solution. I know Bugzilla is commonly used. I also looked at Mantis and Trac. I decided to go with Redmine because it’s a Ruby On Rails app.

Installation

The biggest issue was to identify which ports to use. I already had a Puppies application that I was testing as part of my Cucumber and Cheese book. I added a Graylog2 application, also Ruby On Rails for the web interface (server component is java).

I originally chose to use sqlite3 because it was already installed on my system. I knew that I could use IRB to crack into the database if I needed to. Turned out that I did. I had to create an admin user (default one did not work). I eventually switched to MySQL.

Integrations

I integrated it with Git. I had trouble getting it working until I discovered that I needed to point it to the .git directory of my project directory. By including issue id’s in my checking comments, the issue automatically associated the issue with the checkin. The comment showed up on the repository page and the issue page. It supports diffing, too.

I was able to install a Jenkins Plugin (technically it is for Hudson but works on Jenkins) to integrate with my Jenkins. This allowed me to identify which builds the associated checkins would be built. I also installed a Redmine plugin to Jenkins could also track builds on Jenkins to show Redmine issues associated with the build in aggregate.

It also supported multiple projects, and sub-projects. The wiki and news seemed relevant for keeping track of project information.

There is role based access control. That probably isn’t necessary for an agile team so I ignored this capability. Also non-agile (my opinion) is time tracking and Gantt charts.

Conclusion

I found all the features to be useful. If I were going to build my own stack then I would like using this component.

Watir Podcast 53

I recorded a great interview for the Watir Podcast with Llewellyn Falco about Approval tests (originator of the idea that fed my blog post on The Gold Standard), Teaching Kids Programming, and Agile in general.

I hope that you enjoy it!

Monitoring (Graylog2)

In testing software, I am always concerned about the risks. Especially the risks that get skipped all the time – performance testing and tuning, security, and those secret problems that nobody looks into. Logs can reveal those symptoms of future problems, like high cholesterol is a future problem for a person’s health. Not just the errors that did not get to the user interface, but the trends of cpu & memory usage.

I’ve used a new tool (new to me) called Splunk in the past few months. It’s a super logging system that doesn’t identify anything except it remembers what it is told. It’s versatile in the sources that it can capture from because of it’s web service interface. And what a way to search those logs, the output is beautiful for somebody that is looking for trends & problems.

Graylog2 is an open source alternative. Splunk may be free for many people and their use levels, but I wanted to go naked open source in my investigation of this kind of tool. Though it may not be the easiest for a person like me, I chose to work with this.

What is Graylog2?

Graylog2, in the form that I currently know it, is a graylog2 server (java), mongodb, graylog2 web server (rails), and a ruby gem called gelf. The server and the web server both use the same mongo database, which can be changed by parameters in the command line (typically a production, development, and test environment), and ElasticSearch (search engine). The logs are sent in through Gelf (though David O’Dell has identified other ways to get logs submitted) then stored in the logs.

The use can log into the web interface to created “filters” to make finding messages and activity trends easier.

In addition, users can ‘search’ for logs by creating what appear to be mongo-like queries to the database through the web interface.

Installation

This was a bear. Not any particular part (ok, I’m lying, some parts were hard), but the whole thing was monstrous because there are so many parts involved in something like this.

Graylog2 Server

This was the easiest part of the installation. I downloaded & unzipped, installed openjdk-6-jre, and mongodb. I had to modify my sources list to properly install mongodb, an activity that I hadn’t done in about a year of deep Linux exposure. So far so good. It required ElasticSearch, which wasn’t hard for my to install. In fact, I don’t remember doing anything to elastic at all. I had some issue with getting the server started properly (claimed the port was being used), which I eventually overcame by killing the java process from the first attempt to start.
I had to create a new database instance in mongodb, which was a learning experience because it’s different and I had never used it before.

Graylog2 web interface

This was not as hard to get started. I downloaded & unzipped the rails app. This probably sounds funny but I don’t have much experience using rails. I ran rails s to start the app, had to bundle install, and eventually added the port parameter because I have too many rails running at the same time (redmine). The toughest part was getting the database settings in sync with those on the graylog2 server. Somehow I had not user but it wasn’t asking me to create one. After a couple hours of fooling with mongo db (I learned more about it than I originally intended, not a bad thing), I created a new “environment” on mongo db by creating a new one in mongoid.yml and starting with “rails s -e production”.

GELF

I thought that I was going to be installing some kind of monitor or creating a daemon, both of which I hadn’t done in earnest (unless you count autoit hacks). I looked at monit but decided to use the GELF that seems to integrate nicely with the server. To get that running, I downloaded the gem for it, and modified an example script that sent messages to graylog2. The key lines were these:

n = GELF::Notifier.new("localhost", 12201)
n.notify!(:host => my_host, :level => msg_level, :short_message => msg, :_ip => my_system, :_method => my_method)

The script wasn’t hard to create, but getting the right inputs while processing a log file (I was prototyping from /var/log/syslog) took some time.

Overall, I thought that I could replicate this by parsing almost any long, certainly all the log4j default formatted logs. I know that I could also track resource levels (cpu, memory, network usage, etc.).

Summary

I am really pleased with what I learned from this experiment, but even more so about the possibilities for using something like this to keep track of all the “unseen” information. David Cooper once told me that metrics without a decision to be made are just numbers. I mostly agree, but there have to be decisions that don’t get made because people are completely unaware of the information around them. I hope to wise enough to use it in healthy doses.

I am disappointed that I didn’t get the email notifications working. I hooked it up to my gmail account but never saw an email despite high doses of “fake” log entries being jammed into the server. If I had more time, I’d be sniffing to see what is being sent to gmail (and replied) because the logs I saw were useless. Ironic, huh?

In addition, I would like to have that ability to have a rules engine that acts upon information. If the memory climbs too high, better to reset than let it freeze up. I did not see anything in that arena here. Maybe there is something else on the Test Stack for that?

Continous Integration (Jenkins)

I fancy myself an automated tester. What’s so automatic about it if I have to run a command to make the test run? I guess it’s not. So how to I change that? In the past, I have created schedulers and such to kick off tests. Then I made listeners that would figure out if a new build existed.

Those were Mickey Mouse (please Disney, don’t sue me) solutions compared to the ones I started working with for the past four years – integrated continuous build systems, including Cruise Control, Hudson, Jenkins, and Bamboo (my chronological experience). None of those were my doing. Even when my framework was integrated, somebody smarter than me created that solution.

So in favor of not being left in the dark, I felt I should be able to create the same kind of integration. Step 1 is to install a server. I chose Jenkins, not for any particular reason other than I thought that I would be spending more time using it than figuring it out. I think that I was right.

Basic Set Up

At first I started installing the Ubuntu native Jenkins, then I decided it would be easier to download the jenkins.war file. First feature was to get it running. OK, that’s not a feature, but it was important. I hate apps/app servers that use port 8080 so I changed it.

java -jar /devroot/tools/jenkins/jenkins.war --httpPort=5050

I did not have to install any database for it. I will research that more. I added Jenkins GIT plugin to support integration with GIT. That was easy. Then I was able to link my learning project (downloaded Jeff Morgan’s Puppies app) via file link as:

file:///home/dave/dev/puppies/

I set it to poll every minute (hourly doesn’t seem like continuous integration to me).

Advanced Set Up

Finally, I created a command script (what happens when something in the GIT repository changes) with something to do:

cd /home/dave/dev/puppies
rails s &
cucumber --tags @full

To verify, I checked in a change. Here was my ultimate output (I didn’t mind the failures because the cukes are in disarray):

8 scenarios (8 failed)
45 steps (9 failed, 6 skipped, 1 undefined, 29 passed)
2m41.479s

You can implement step definitions for undefined steps with these snippets:

Then /^I should see the following error messages: "(.*?)"$/ do |arg1|
  pending # express the regexp above with the code you wish you had
endBuild step 'Execute shell' marked build as failure
Finished: FAILURE

After I proved to myself that the command scripts ran for check-ins, I added a little bit more. I set up basic authentication for users, allowing everybody to do anything (it’s just me). I also started working on an ssh key, but I didn’t finish that yet.

Summary

Jenkins was easy to install, set up for my repository (even easier for svn and cvs, though I am not sure why), and easy to create mock scripts. I found it easy to integration my test framework. Jenkins even knew that it failed.

I would recommend that any tester that is working on automation should feel comfortable installing and integrating with Jenkins.

Watir Podcast #52

Listen to @zeljkofilipin discuss Watir, test automation news with me on @watirpodcast #52 http://watirpodcast.com/?p=379  & http://watirpodcast.com/?p=382