Agile Testing

by Stan Taylor

Perks in the high-tech workplace

by Stan on 2014/06/11, no comments

My friend Rafe Colburn and his Etsy coworker Melissa Santos have written an insightful article on perks in high-tech companies in which they explore a lot of issues that I’ve thought about over the years. Their thesis:

In an industry where culture is often allowed to be defined by perks, managers need to [be] mindful of the fact that for many people, perks underscore the differences between members of the team rather than bringing them together. They also need to think about what a company’s perks indicate to potential employees about the culture.

I’m one of those employees who often feels ambivalent about company perks–especially team-building events, and within that category, especially events that take place outside of work hours. Balancing my responsibilities to my family with my work responsibilities is hard enough when work is confined to defined hours and expectations. An after-hours event often just adds to that delicate balancing act.

Placeholder text goes here

by Stan on 2014/02/24, no comments

content-loremEarly on in my career as a software tester, I learned–the hard way–not to use profanity in my test text when an executive asked me to demo our software to someone outside the company and I had to use my test environment. In the same vein, Rian van der Merwe has collected  instances of placeholder text that have unintentionally  made it into the real world–both in new and old media. It’s great.

Assigning colors to a BIRT stacked bar chart based on series values

by Stan on 2013/04/04, no comments

This has nothing to do with QA, but I’ve been writing a lot of BIRT reports lately; I just solved this problem and wanted to make sure my solution is out there for others who need it.
This is the stacked bar chart that I created:
There are three possible values: PASS, FAIL and NOTRUN, and I wanted to make sure that each value got a specified color: green for PASS, red for FAIL and grey for NOTRUN (not tests showed this value on the chart that I used for this post)
The solution was to select the chart, click on the ‘Script’ tab and enter the code below. The beforeDrawDataPoint function draws the bars. the beforeDrawLegendItem function draws the legend:

* Called before drawing each datapoint graphical representation or marker.
* @param dph
* DataPointHints
* @param fill
* Fill
* @param icsc
* IChartScriptContext
function beforeDrawDataPoint( dph, fill, icsc )
var Condition = dph.getSeriesDisplayValue();
if(Condition == "PASS") {fill.set(0,153,0);}
if(Condition == "FAIL") {fill.set(255,0,0);}
if(Condition == "NOTRUN") {fill.set(204,204,204);}
* Called before drawing the legend item.
* @param lerh
* LegendEntryRenderingHints
* @param bounds
* Bounds
* @param icsc
* IChartScriptContext
* @since Version 2.2.0
function beforeDrawLegendItem( lerh, bounds, icsc )
var Condition = lerh.getLabel().getCaption().getValue();
if(Condition == "PASS") { lerh.getFill().set(0,153,0);}
if(Condition == "FAIL") { lerh.getFill().set(255,0,0);}
if(Condition == "NOTRUN") { lerh.getFill().set(204,204,204);}

Often overlooked test automation challenges

by Stan on 2012/08/08, no comments

The company I work for develops several different products as part of a unified offering. These products need to work with each other and with products from other companies. Each product development team has its own manual QA and automation team, and we have a solutions testing team that ensures interoperability between our products and others. The company has been pretty ‘siloed’–each product’s automation team has worked mostly in isolation from the others.
Until now, the interoperability testing has been all manual, but the manager of that team has embarked on an effort 1.) to get the different automation teams familiar with each other and their work, and 2.) to leverage the automation efforts of the various product teams in the interoperability testing effort.
To that end, we’ve started holding a weekly cross-team automation meeting, with run by the interoperability testing manager with a representative from each product’s automation team. The agenda consists of the following:

  1. Product configuration automation
  2. Test lab usage management (automated check out/in of lab resources
  3. Automation strategy
  4. Test management and reporting

What’s striking is that each product automation team has put in significant effort to address all four of these functions (with a lot of duplicated work!), yet when we think about test automation, we typically only think about #3, the actual automated tests themselves.
Just an observation. When we think about test automation, we need to remember that there are several complex components to it besides the tests themselves.

Clever job-hunting move

by Stan on 2012/08/02, no comments

I can’t say I condone this, but it’s a clever way to see how you stack up against the competition:

After a fruitless job search — endlessly scanning and Craigslist and tweaking resumes and cover letters — he grew more curious about his competitors. So he created a fake Craigslist ad for an administrative assistant position and, in one day, received 653 responses from applicants with a wide range of education and experience.

Sneaky. Not ethical. But sneaky.

Important note to recruiters

by Stan on 2012/05/02, no comments

I frequently received requests to connect on LinkedIn from recruiters I do not know. I decline all connection requests from people I don’t know.
If you’re a recruiter and you want to contact me, please either use the ‘send a message’ functionality on LinkedIn or just send me an email.
When I asked a recruiter friend why so many recruiters used connection requests instead of messages, he pointed out that it costs money to send more than a handful of messages per month. If you’re a recruiter, pay the money to get the messages functionality. It doesn’t seem very professional to me to have you misusing LinkedIn functionality because you’re too cheap to pay for the appropriate functionality.
</end of grouchy old man rant>

“Just Good Enough”

by Stan on 2011/08/10, one comment

One of the automation engineers on our team is extremely thorough. When she does code reviews, she sends back lengthy emails, and she provides a lot of good information regarding coding practices. Her devotion to detail is a real asset to the team. However, she is getting burned out on code reviews and sometimes I think her time could be better spent on her own work.
As a team lead, I struggle with this type of team member? She’s doing outstanding work and almost every point she makes is technically correct and/or a good practice. I can’t very well tell her she’s not doing a good job.
My solution is to realize that she has a different viewpoint from mine. Hers is technical: from a technical point of view she’s almost always right. But I have to balance the technical viewpoint with the business viewpoint. While what she is doing is technically right, from a business viewpoint, it may not be the best use of her time. From a business viewpoint, sometimes the right thing is consciously to let some things slide.
On this team, we’re constantly refining our coding standards and practices. Lately, I’ve introduced the idea of ‘Just good enough.’ This is short-hand for the business viewpoint, a way of balancing the technically correct decisions with the business realities.
A lot of software engineers are happy doing their coding and letting me deal with the business issues. Unfortunately, this is one instance, however, where the engineers have to think about the business perspective as well.