Posts Tagged ‘developer’

“Drop the Software Testing Baton”

Thursday, January 17th, 2013

A software tester, with a determined look on his face, walks briskly up to your desk and blurts out, ‘It doesn’t work.’  After you sigh, your mind oscillates between responses of, ‘Okay, let me look into it,’ and ‘What the heck do I do with THAT?’

Developing and testing software should be less of a series of hand-offs between tester and developer, and more of a collaborative, ongoing conversation.  Even with the most well-intentioned of testers, the baton is often passed off to a developer because the tester has run out of debugging options.  FAST has eliminated that baton pass forever.  The testing approach and automation that we used on a recent project played a significant role in allowing us to convert a company’s life insurance policy administration system in only five months.  No one on the project could have imagined this pace being possible without efficient and effective testing woven into the entire project.

Empowering the Team

We created a debugging tool easy enough for everyone on the team to use…

  • A failed test condition was no longer the end of the road
  • What went right, what went wrong and precisely where it went wrong was clear as day
  • Corrections were made simply – using spreadsheets  and configuration changes
  • Painstakingly documenting detailed recreate steps became a thing of the past

With the debugger everyone on the team could,

  • grab the exact xml being tested
  • use it to step through the business logic and rules to see what was happening

Testing & Automation

The test driven approach of FAST 8x and the Test Case Manager are the perfect complement to the debugger.  They both offer tremendous value, FAST 8x automation drives testing efficiency while the Test case manager increases effectiveness.

  • FAST 8x: the test driven approach automatically test APIs, eliminating the need for regression testing the application
  • Test Case Manager: tool for actuaries and the product team to test a variety of permutations using the calc spreadsheet independent of the application
  •  Calc spreadsheet: designed for actuaries, by actuaries, an easy to use UI allows the team to create  their own scenarios  and eliminates their reliance on a technical resource to update code

As we used these tools, it was really cool to watch the traditional software development lines between tester and developer disappear!

Benefits

The benefits of using these tools to debug and test business transactions and calculations were numerous.

1)      Transparency of business processes to the business owner with a user-friendly spreadsheet which is easily traversed

  • This transparency promotes a feeling of trust between the vendor and the client

2)      Business knowledge transfer was a by-product of the transparency of the business rules

  • The tool facilitated business process discussions with the client

3)      Continuous testing of the business logic and rules

  • Resulted in a condensed ‘testing phase’ and quicker deployment

4)      Perpetual vendor reliance was eliminated

  • The client quickly internalized how they could maintain these business rules on their own

5)       Small steps and simple calculations demystify complex calculations

  • Logic is not buried deep in layers of code and errors can be fixed by dragging and dropping the appropriate orchestration step into the right place

As a Business Analyst, the tools were cool and fun to use.  They created a great sense of accomplishment across the team – issues could be quickly pinpointed and then corrected through configuration and I could fix bugs on my own!  And as for the Actuaries being able to create and test their own calculations, let’s just say they got as excited as actuaries get…

After the success we achieved, I can’t imagine a project without it!!!

 

Sharon Amos, Business Analyst

FAST

 

7 Ways to Get the Most out of your Off-Shore Team

Wednesday, August 31st, 2011

In the IT industry, off-shore teams have been a major player in the productivity and the sheer work-force of a company. Yet companies continue to have mixed (or worse, no) approach to utilizing their potential for the greatest output. Some companies are happy with adopting a process-over-people approach, satisfied with consistent, standardized productivity in exchange for high turnover rates and impersonal communications; others demand a more robust, personal approach that maximizes individual efficacy and work ethic. In my two major successes with off-shore, I’ve come to realize the differences in productivity and quality lies in the way we manage all of our employees.

We believe that it is important to invest in human capital both in house and off shore. I’ve worked with many major outsourcing firms in India (as well as worked for one) and most have a “process over people” approach. Their main priorities are the hiring practices, training procedures, development process and rates (per hour/day) and not the quality of the individuals or throughput of expected output/deliverable. In my experience with these outsourcing firms, the ones that are the most successful are the ones where the people are treated like people. Point is — they are people too and when treated with incentives that reward their work and input, like anyone, they are far more productive.

How we got the most out of our off-shore teams:

1. Treat them like your own: By treating our off shore workers as if they were our on-site employees, they are enthusiastic about their contribution to our product and work more efficiently to meet our company goals. Some of the ways in which we have treated off-shore like our own are:

  • Pay for company outings
  •  Create a bonus pool to compensate them for their extra efforts

2. Invest in cultivating face to face relationships: By creating and investing in more personal relationships with the off-shore team, they not only feel a greater morale and loyalty towards the company, but will recognize themselves as a part of the big picture. Ways we’ve cultivated face-to-face relationships:

  • Brought them to the US to work in our headquarters in Edison, NJ
  • Sent our employees to India to work with the off shore team
  • Invited them to company meetings and parties when they were here in the U.S.

3. Conducting quarterly reviews to make sure the company and individual targets are met ensures that both the company and the employee are growing and getting the most out of each other

4. Real-time communication as much as possible – skype, IM, video, calls, etc.

5. Retain the good people: I strongly believe that the range of production you get out of an average person vs. good person vs. great vs. elite triples at each level. So, the range of productivity from average to elite = up to 27 times greater (3x3x3). So, when I get the good, great and elite people on my projects, I don’t want to trade them in for average (or god forbid “below average”).

6. Make sure everyone sees the big picture. Sub-teams are always necessary to break down tasks and projects, but they have to feel part of the overall team and understand the big picture. By creating an environment where they feel like an integral part of achieving the company’s overall objective, off-shore developers will take greater responsibility for the quality and success of the product.

7. Let the senior people do the work: many cultures want to be in “management” and not do the development, design or testing – incent people to “do the work” at all levels, and everyone will work that much harder to produce something they can be proud of.

How Do You Define “Good Productivity” for Software Developers?

Friday, July 22nd, 2011

When I started running in my twenties, I was using a treadmill and doing 10 minute miles for three or four miles.  I felt pretty good about that.  Then I ran a five mile race and I found out that 8 minute miles for a longer run were kind of the minimum for a pretty good recreational runner, so that’s what I ran after that.

Now, my son runs high school cross country and 5 ½ minute miles for a 5k (3.11 miles) is pretty much where you need to be to be competitive.  Benchmarks are set and each year new freshmen come in and shave minutes off their times to meet the established standards.

Basically, how good is “good” is a matter of perspective and benchmarks.  Measuring speed, of course, is very easy and very objective.  There are teammates and years and years of records to compare to, so it’s easy to say what good is.

With software development, we really don’t have a great way of measuring “good” productivity.  Sure, we can measure quality and ability to meet commitments, but how do we know the productivity was good?  And how do you incent people to be good?

How can we tell the difference between the developer who runs the 10 minute miles (and he looks good doing it) and the guy who runs the 5 minute miles?  How do we reward them?

Do you ever feel like your developers are walking at a 20 minute mile pace and passing it off as “running”?

 

John Gorman

FAST