No testers (dev tests their own code)
I truly hope that all developers test their own code before they send it anywhere else, but having dedicated testers is also great for a second set of eyes. It might be possible for you to get this second set of eyes without dedicated testers, for an example by doing peer reviews of code.
Regarding the automated tests, consider the following: It will take a lot of time and concentrated effort to write these tests. They will very likely be good but it's a huge undertaking which will soak up almost all of your time. There definitely is a pot of gold at the end of the rainbow but you should really, really limit the scope of these tests to critical functions and execution paths. Build a test suite over time.
It's very possible that lack of tests and testing of code is a reason you have a lot of interruptions but instead of having the goal to test everything you've created before try to establish better goals for new code. If you create a new function create tests for it. If you update an old function and no tests exist: Write them.
Lots of interruptions along the sprints, to do another stuff wasn't planned
I've worked like this as well but what to do really depends on the interruptions. You really can't get away from some of them; ever heard someone say "We'll get the servers back up and running during the next sprint?"
Interruptions are a side effect of several things and there are certain remedies which could help you alleviate the pain. Try to take steps to release:
- Stable code
- Bug free code
- Code which accomplishes the intended task
Some of the previously mentioned things will help with this. Better verification of code stability and that there are no bugs should keep some of these issues away from your table.
Making sure that tasks are properly specified before someone starts coding is incredibly useful and, I find, sometimes not done at all by people. Working in a small company I prefer to walk up to the person who is going to use what I'll be programming and ask them to tell me about their problem. This might not be viable to you and might be completely impossible depending on company size as well as culture. Joel Spolsky has an interesting series on writing specifications.
In addition, just as Ewan said Kanban can be a great tool when you have many tasks coming in from the side line. Simply keep a backlog that's in prioritized order and whenever a new important thing comes in it's put on the top (or wherever else is appropriate).
Sometimes you also have to educate the people putting in new requirements on what an interruption means. If you put people through an exercise where they have to prioritize tasks to be done they'll usually say that everything is top priority and somehow believe that this means that every top priority thing will be done fast. After all, nobody puts effort into low priority. Here it's important to teach people that interruptions take more time, see once more Joel Spolsky in Human Task Switches Considered Harmful. In addition, make people really ask themselves if asking a developer to change that indigo into a magenta color really is as urgent as they believe.
A General Recommendation
If your current process isn't working or isn't good enough, don't be afraid to change it. Keep in mind that if a certain change doesn't work out you can try something else or go back to how things were done before. Don't make huge changes or change everything at the same time but incrementally improve your process. Improve the process like you improve your code.