Introducing a (new) test method to a team
- by Jon List
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 experience 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.
Thanks!!
(TL;DR: read the bold parts)
