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:
- general website testing. (javascript, C#, ASP.NET and CMS integration tests)
- (live) ERP integration testing (customers rarely want to pay for test environments).
- 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:
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,
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!