Introducing a (new) test method to a team


A couple of months ago I was hired in a new job. (I'm fresh out of my Masters in software engineering)

The company mainly consists of ERP consultants, but I was hired in their fairly small web department (6 developers), our main task is ERP/ecom integration (ERP-integrated web shops).

The department is growing, and recently my manager asked me to start thinking about introducing tests to the team, I love a challenge, but frankly I'm a bit scared (I'm the least experienced member of the team).

Currently the method of testing is clicking around in the web shop and asking the customer if the products are there, if they look okay, and if orders are posted correctly to the ERP.

We are getting a lot of support cases on previous projects, where a customer or a customer's customer have run into errors, which – I suppose – is why my manager wants more structured testing.

Off the top of my head, I though of some (obvious?) improvements, like looking at the requirement specification, having an issue tracker, enabling team members to register their time on a "tests"-line on the budget, and to circulate tasks amongst members of the team.

But as I see it we have three main challenges:

  1. general website testing. (javascript, C#, ASP.NET and CMS integration tests)
  2. (live) ERP integration testing (customers rarely want to pay for test environments).
  3. adopting a method in the team

I like the responsibility, but I am afraid that I'm in a little bit over my head.

I expect that my manager expects me to set up some kind of workshop for the team where I present some techniques and ideas and where we(the team) can find some solutions together.

What I learned in school was mostly unit testing and program verification, not so much testing across multiple systems and applications.

What I'm looking for here, is references/advice/pointers/anecdotes; anything that might help me to get smarter and to improve the current method of my team.

(TL;DR: read the bold parts)

Best Answer

Evolving the Team's Culture

This might be the most difficult part of implementing testing processes in your organization. Every team reacts to change differently. Some people embrace the opportunity to try something new, and some are perfectly happy in their ways and see no reason to change. I can tell you this: nobody likes a fascist. Forcing people to do things a certain way will likely generate more resistance.

Here are some tips for presenting change in your organization:

  • Provide empirical evidence, such as "We caught bug X before delivering to the customer, and it took us 8 hours to patch it. The customer caught bug Y one month after it was delivered, and it took us a week to patch it." Edit: I see that you mentioned that your client may be concerned with the costs of a test site. See if you can prove that catching bugs early will save the client money.
  • Show the developers how new tools work. A lot of us are developers because we think that technology is fun. Try to share new testing tools/processes like new toys with which to play.
  • Don't set your heart on any single solution. Let the team experiment with various technologies. For automated UI testing, you can use TFS, Selenium, manually going through test scripts, or other options. Keeping the door open to different technologies allows the team to find which tools are good fits, and it also encourages a democratic process that promotes a shared ownership of decision making. Encourage open discussions with the development team.
  • DO NOT expect everything to change at once. Try to focus on one thing at a time. Here is an example of breaking change into smaller stages:
    1. Write some unit tests for the server code that verify that system-critical functionality works as intended
    2. Create a test VM that duplicates the operational environment of your product
    3. Document use cases that can be used to test the GUI
    4. Combine the server code and the client code into a single repository on TFS so that the most recent release is easily identifiable, testable, and able to be deployed
    5. Start executing use case testing whenever new components are committed (automated or manually)

These are just some example tasks. It may take weeks to get where you want to be; it may take months. How exactly your team adopts testing processes is going to depend on your culture. Last but not least,

  • DO NOT give up, but be polite and amiable about it. If you keep suggesting ways to enhance testing processes, the development team might try some of your suggestions on a slow day just out of curiosity.

Technical Solution

I wish I could give you some better information on technical solutions for your situation. I work part-time in a .NET shop, and I can tell you that we use TFS exclusively for continuous integration, i.e. version control for client code (EXTJS w/ ASP.NET MVC 3) and server code (C# w/ Entity Framework), automated UI and unit tests on the release branch, and automated deployment to a test site and a demo site (which will be our production site eventually). As I mentioned above, your specific technical solution(s) will depend largely on your organization's culture.

Good luck!