software

Some tips for one-person software test teams

Last week I hosted a panel on time management for a local software testing group, IWST (Indianapolis Workshops on Software Testing). One of the questions asked during the meeting went like this: “I just started a new job and I’m at a company where I’m the only tester. Any tips for making that work?”

The entire panel was quick to point out that you’re never alone, and that you always have a team to work with. Brian Ball, a software engineer with Software Engineering Professionals, said that it’s important for you to realize you’re part of a larger team — whether they feel like it or not. He said you need to let the rest of the team know that you’re concerns are really their concerns.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, pointed out the following:

“What you really need to do in those situations is identify who are the stakeholders around you who care about the results of your work and the results of what’s happening, and find a way to leverage their expertise, their ability, their commitment and their passion towards what you do. Now that’s a problem that is magnified when you have technical expertise in some area of what you do, and the people around you — the stakeholders — don’t.”

Slaughter also pointed out that one of the most important things you can do is to help people give you information in a way that enables you to do your work better.

“You need to realize that you might have this expertise or this area of technical facility [and they do not]. You need to go back to the stakeholders and identify ways to communicate better. Maybe they need a form to fill out. Maybe they need a tracking system, your ticket tracking for the request. Or maybe you need to find a way to give them information in a more organized fashion, so they can find it more easily so they are not constantly calling you.”

Chris Wingate, principal software engineer for Liberty Mutual, summed up his thoughts on the question the following way:

“To me is seems to come down to two things…and those are trust and education. So you’re the only tester in your organization at the moment, and so it’s very important to build the trust in your competence with the rest of the team — with the developers and the managers. That way when you say, ‘Yes I can do that.’ or ‘No I can’t do that for these technical reasons.’ you don’t have to spend a lot of time explaining all of that and rehashing all of those things that you continually do.

“The other thing is educating the rest of the team about what your capabilities are, what timelines are, and they go together… you have to educate your customer in terminology. Educating your customer is going to help improve the communication and help make you more efficient.”

You can find the complete audio for the panel members’ advise for one-person test teams on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

STPCon wrap-up: SpeedGeeking, testing Web 2.0 applications

It’s been an amazing week here in Boston while attending the Software Test&Performance Conference.  Friday morning, we ran SpeedGeeking; in the afternoon, I gave my testing Web 2.0 talk, then it was time for dinner and some amazing conversation, and, eventually, sleep.

Similar to lightning talks, SpeedGeeking is a series of seven-minute talks, in rapid fire, one after the other, with one big “BUT”.  Instead of having the whole audience of 100 some-odd people, sitting through the talks in order, we split the room into seven different tables and had the speakers walk around. They chose not to use powerpoint but instead using old-fashioned flip charts and markers.

Justin Hunter, David Gilbert, James Bach, Michael Bolton, Jon Bach, and Scott Barber all lined up, waited for the bell, and … pandemonium ensured. I was stuck between Jon ad James Bach - yes - “inside the Bachs.”

My talk was on productivity on test teams, how teams measure the time they spend testing, as compared to support activities like documentation, status, meetings. Some were surprised to find that as little as 10-30% of time is spent actually testing. Thus, to improve throughput, many test teams don’t need to adopt a fancy methodology or purchase a tool. Instead, they could simply spend more time testing. James Bach covered his “Huh? Really? So?” approach to testing certain claims, while Michael Bolton talked about Testing Vs. Checking. David Gilbert talked about testing as a social, humanistic activity. Aside from some issues with the acoustics, I was really happy with how SpeedGeeking turned out.

Ironically after being stuck “Betwen the Bachs” at SpeedGeeking, the next session I attended was a keynote called “Testing outside the Bachs”, where Jon and James explained exploratory testing

In my “Testing Web 2.0 Applications” talk, I discussed the user-centric web including, ironicaly, blogging, where the buisness model is to have the user’s themselves develop the value, with the tools acting as a enabler.  I covered techniques such as testing with a dirty environment, segmenting the tests, and testing race conditions.  I’ve also placed the slides for the talk online here.

Then I went out to dinner with a few attendees, where I asked for a blueberry beer and got regular beer with physical blueberries in it.  (I was expecting a blueberry flavored beer.) I guess I didn’t specific enough with the requirements, eh?

Start with a software test plan template, then throw it away

There’s nothing more intimidating than a blank sheet of paper. Writers know this to be true, but so do test managers. The easy way out is to pull out a template and to start filling in the various “recommended” sections and details. An even easier approach is to pull out a past test plan and to just start changing project names, diagrams, and technologies. However, these approaches miss the point.

Recently while writing a test plan for a new project, I’ve noticed an odd habit I’ve developed. Ten years ago, when I wrote a test plan I started with a template. Four years ago, if I wrote a test plan I started with a blank sheet of paper. I noticed that when I write a test plan today, I look at templates, decide not to use them, and then end up pulling in pieces of them anyway.

The planning process isn’t about producing a document. Okay, well it shouldn’t be about producing a document. I recognize that in some companies it is. Instead, it’s about thinking about the problem. Software development problems are difficult and solving these problems requires time spent in research, comparing options, and prototyping. Our planning process, in the early stages, is about exploring those options and elaborating on what we think we’ll need to do (and when we’ll need to do it).

I find templates keep me from thinking about the actual problem. Instead they get me thinking about formatting and populating sections that aren’t yet filled in. When I’m using a template, I’m thinking about polish - not content.

However, there’s value to templates. They’re useful checklists for what types of things you should think about. I forget stuff just like anyone else. I’ve gotten a lot of good ideas from templates. So I’ve developed a habit of using a template to “prime the pump.”

I take an initial look at my templates and past test plans and use that to help get me started on problem solving. I’ll then switch over to a blank sheet of paper and start typing out my ideas and thoughts about what we need to test and how we should test it. Later, when I feel I’ve got most of my content, I’ll go back to a template and start pasting the content into the appropriate sections.

This technique keeps me from focusing on polish at the wrong time. There’s nothing wrong with polish, I just don’t want to be thinking about what font to use when I should be thinking about how I’m going to find or generate test data. This technique keeps me free from distractions when what I really need to be doing is focusing on the problem. This helps me deal with some of the intimidation of the blank page, but also allows me to be focused on the difficult topics when that’s what needs to be done.

VMware teamed with SpringSource takes cloud computing head on

The VMworld 2009 opening keynote began like a rock concert with pulsing music and a light show as the morning’s keynote speaker, Tod Nielsen, took the stage. Nielsen, VMware’s Chief Operating Officer, introduced the conference venue with exciting news for the company’s multiple products and services.

None of which measured up to the audience’s response when Nielsen was joined on stage by Steve Herrod, CTO and vice president of R&D for SpringSource. Herrod reviewed VMware’s plans for SpringSource, which he’d already blogged about in August.

SpringSource, a commercial open source company, started by creating tools that competed with Java; but in the last few years has released a more diverse tool developer. Combined with the VMware infrastructure, Herrod said, SpringSource’s software will bring advanced development and storage capabilities to data centers.

“I am very excited about this,” said Rob Zylowski, Director IP for GlassHouse Technologies Inc. “With VMware and SpringSource working as one, they will be formidable competition for Apple’s cloud powered initiative.”

Chris Wolf, Burton Group senior analyst, is another industry expert who voiced enthusiasm, Twittering and blogging about the SpringSource-VMware combination throughout the opening day of VMworld. On his blog, he wrote:

“Rod Johnson did a tremendous job with the SpringSource demo. Giving application owners an interface to provision an app locally, or to an internal or external cloud was spot-on. IT service delivery requires IT operations to give application owners and individual business units interfaces that they understand… this is a technology VMware ships should begin working with in their labs.”

Stay tuned for additional blogs, videos and impressions from VMworld.

Agile expert advises on agile transition snags, PMO problems

Recently, I spoke with Alex Adamopoulos, CEO and founder of emergn about his company’s new agile development transition consultancy program, AgilePMO. In these remarks from our interview, Adamopoulos offers advice on agile development process adoption and his views on agile.

Emergn, is a new company, but Adamopoulos’ experience in the software service field is extensive. He is a 20-year veteran and an active blogger.

What is your agile philosophy?

Adamopoulos: A transformation program. If I think about the guiding principles of an agile engagement, they’re the same fundamental principles of a well-run global company.

What are some common problems within PMOs (Project Management Offices)?

Adamopoulos: Even when I was embedded in the outsourcing community, I thought that large enterprises had a methodical process for why they’d select a vendor, manage a project, etc. I discovered that not only did a lot of them not have them, but the ones that do have them are typically by line of business.

Could you offer a hypothetical example of a company with a PMO problem?

Adamopoulos: A good example would be a top bank, in the top three. Their investment banking side, which drives more than half of the revenue, has a PMO, and that PMO is only operated by three people. It’s fragmented across two geographies. Then, if you go to asset management side, you discover that they have one-person shops or half-person shops. That is common for eight out of 10 of our clients.

Usually, they have no metrics or measurements in place. The metrics that exist are rudimentary project metrics that do not even translate into economic numbers or business value that a CIO can sit with his boss and say, “Here’s why we are making these decisions and how they are affecting our company.”

So, it would make sense for them to explore a way to drive it more efficiently. Right?

Adamopoulos: Clearly the largest problem we see is that there is no single project or program governance in place. There is no methodology for how programs should be governed. There is a lot of waste. We see morale being affected.

What are common snags that occur in transitions to agile?

Adamopoulos: Typically, it becomes a land grab. it is very difficult for some organizations to change their existing behavior and their business psychology. Asking them to collaborate and communicate, and be more dependent upon the business in several areas [is a big deal].

The biggest risk is the psychological impact that agile can have on an organization. Right or wrong, many have already settled into their comfort zones. Agile is a very disruptive methodology, not just at the software level but at the cultural level as well. The larger risks are people asking, “How are you going to impact my job, and why? What does it mean to me in terms of the responsibilities I might have?” There needs to be a lot of coaching in the transitioning people out of their current working mindsets and into something new.

Who are emergn’s target customers?

Adamopoulos: Today, the traditional customer for us is in the application development areas of IT; but we are starting to branch out with the AgilePMO product. Our primary target is the enterprise client, meaning the tier-one enterprise, the $1 billion-plus players. That is where the majority where our business is today. Is it likely that we’ll do things below that? Probably, but it would have to be very specific, because agile enablement reshapes a company’s sourcing strategy. Those are pretty important programs, ones that aren’t taken lightly, and we’ve found that the larger companies are more ready to do those than the smaller players.

The economy has been a help for us as opposed to a hurt; the whole drive of saving money, reorganizing, efficiency has supported our model. So, organizations that have very fragmented sourcing programs are the primary focus for us.

How long do you customers need emergn’s consulting services?

Adamopoulos: I am pretty sensitive to the consulting side. I have been a customer. I don’t believe in having people from the B-team or sit there for one, two years and billing against my company.

Maybe I sound old-fashioned, but we definitely want to drive value. For some companies that may take one year or even half. We are currently doing one large scale agile transfer program for one of the UK’s largest utilities that is a 24-month roadmap, but that is something we defined up front.

British Airways is a great example. We did an entire agile transformation for them. Since they are an airline, they have a gazillion projects going on. We have begun applying a number of initial successes into some points of business. How long they’ll take? I don’t know, but in their case they want to see their entire organization become as agile as possible.

CAST 2009: The challenges of regulation, an interview with Jean Ann Harrison

Veteran software testing and quality assurance pro Jean Ann Harrison will be presenting a software testing case study based on her experiences at a medical device study at this year’s Conference for the Association for Software Testing (CAST), slated for July 13-16th in Colorado Springs.

In her session — titled “A Balancing Act: Satisfying Regulators, End Users, Business Leaders and Development” — Harrison plans to provide guidance to testers who have to deal with conflicting priorities between developers, project managers, customers/patients, and regulators.

“Priorities clash and inevitably software testers are in the middle of a battlefield between developers trying to get their work done and delivered while project managers are trying to make a deadline, customers/patients want to make sure the product works as expected and the regulators demand the proper documentation delivered in a sequential timeframe.” Harrison went on to share some of the questions she hopes to answer in the talk. “How do testers balance all these shareholder’s priorities? How can testers decide which direction to take as the project matures? Which shareholders’ take precedence over another?”

With 10 years of experience in software quality assurance and testing and three years testing embedded software on portable devices, Jean Ann Harrison has gained broad experience in various software testing processes and has worked in varied contexts including large multi-million dollar corporations, venture capital, and start-up companies. Harrison is currently works for CardioNet, Inc. where her primary role is testing software embedded in medical devices that provide diagnostic data for physicians to determine their patient’s heart condition.

“I developed the talk through my own learning process as a software tester working in a regulated environment for the first time. What to do, what not to do, what one can expect, and how to handle the demands of a regulated company helped formulate my subject. And most companies producing software usually have some sort of description of what is wanted, needed, or expected when the project is completed. Most companies usually have some method of traceability of software requirements, software design, and product information. In a regulated environment, the role of documentation is the centerpiece of any project.”

When asked to expand a bit on the challenges of regulation, Harrison continued:

“First, a single source location for documentation must be identified, implemented and then monitored. Then documentation is distinct in a regulated environment by the level of detail provided, the sequence of submittal of documentation, identifying appropriate reviewers to approve the documentation, and a historical record is maintained for traceability purposes. This process is extremely formalized and dates of submittals are critical to the project. Non-regulated environments tend to be more relaxed and even the most formal processes have allowable slips. In regulated environments, slips are not acceptable, and contingency plans must be implemented to explain deviations. If regulated environments do not meet regulators demands, the certifications are rescinded.”

One of the things I found most interesting about my interview with Jean Ann Harrison was her biggest influence for the talk, which came not from the field of testing, but instead from political science. Harrison majored in Political Science 25 years ago. She’s found that the analytical thinking skills her professors emphasized play a large part in her success.

“In the four years and loads of courses, exercises were given to force students to practice analytical thinking. Software testers are constantly required to analyze how to do something, how to improve, what is the data telling you, analyze different perspectives, create. Over the years, my analytical skills have evolved but certainly were given a solid foundation because two professors teaching the subject of Political Science felt the skill was critical to the coursework. One exercise that was given to me in a course called Research Methods, I use today to train and mentor software testers. It is simplistic in nature but very difficult to implement. The exercise requires them to generate a new hypothesis that they personally have not read about, been trained in, or been given any sort of research material on. Then they are required to describe and prove the hypothesis using empirical means.”

When asked why she chose CAST as the venue for her talk, Harrison shared that this year’s theme for the conference, “Serving our stakeholders,” is directly relevant to some of the lessons her current company is learning, as it’s experiencing growth. “Each department is learning who the customers are,” Harrison says, “How we can better be of service, and what can we learn from our mistakes.”

For more on the upcoming show, check out the CAST conference website.