Just Do It...
You are being asked to do manual testing because you did not help automate the testing. Be glad that it is painful and something that you don't like to do. Hopefully, all the other devs on your team feel the same way. After suffering through the pain of testing manually, ask yourself: "Why do devs at other companies not have to go through all this manual testing?" And I assure you, plenty of companies ship quality software without extensive manual testing. The answer is: automation.
...Then Automate It
If you already have good unit test coverage, then great! How close is it to 100%? Do you have integration tests which assemble modules of your software and test for coordination? No? That's the next step in automation. You will have to use your judgment to decide what modules need special attention.
Finally, do you have acceptance tests? If your software is UI-driven, then you will need something like Selenium/FitNesse/etc. If it is service-oriented, and can be tested with a simple web request, then I suggest something which might be non-standard but which I found to be very useful: write your acceptance tests as performance tests, using Gatling. Ok, this sounds crazy, but hear me out...
Gatling is powerful because you write the test specification in Scala. If Scala isn't your development language, then you will need to learn some basics in order to write tests. But trust me, it's worth the investment! For a performance test, you want to construct a variety of fairly representative requests for your service, and Gatling makes this easy. You can read data from configuration files and generate any kind of request object you like. Then, you can hit the service under test as hard as your test runner workstation can send requests and process the responses (which is generally much faster than the service can handle the requests).
Now I run both Smoke Tests and Performance Tests. They are exactly the same. The only difference is that Smoke Tests run exactly N times, for small N (like, say 3), while Perf Tests run for duration T (like, 15m). Both kinds of tests generate requests randomly. Some people will object that determinism is better for reproducibility, and there is merit to that argument. But I like random generation for coverage, because sometimes you will get "interesting" requests that trigger an obscure bug, and that leaves a log trail that you can investigate.
But you need to know if your software works...not whether it's fast. What does this have to do with correctness? Well, everything! You see, there is one funny thing that happens in large companies which have dedicated testers. The testers end up looking for, and triggering, abnormal/problematic conditions in the code, to see what happens. But really, developers should also be detecting those conditions. Ideally, they should at the least, log an ERROR when something happens that would cause an SDET/SET to file a bug report. Which means that good SDEs and good SDETs should be doing some redundant things relative to each other, which is actually a waste of very expensive time.
Instead of writing an external test that explicitly checks for these error conditions, it's much better for the service to be very aggressive in data validation at all stages of the computation, and to log anything anomalous. Then, part of your perf test will involve checking the logs (I hope you have log forwarding set up, like Splunk or similar). In particular, you want to see if any ERROR or HTTP 5xx occurs during your tests (either smoke or perf). If they do, then you know you have a problem worth investigating.
Now, what you have done is turned your perf test into an acceptance test generator. For this to work well, your request generator needs to have good coverage. Ideally, it should hit all parts of the domain for every request field, even if you shape the distribution to be "realistic". For instance, suppose you run Twitter, and you need to see if the TweetService works correctly. A request will likely just be something like: (username, message). You clearly need to exercise the full range of possible usernames (length, characters allowed, etc.), as well as messages (again, length, characters allowed, embedded links, etc.). Your generator might prefer to create shorter messages on average, but it should still create max-length messages sometimes (meaning, they should occur many times over the course of your perf run).
Although I have used both Selenium and Fitnesse, UI testing is not my forte and I cannot give you detailed guidance here. Unfortunately, I do not think it is possible to generate random tests for UIs the way you can for services. This makes it a very different beast. Even so, automation >>> manual testing. Find a framework, get buy-in from your team, automate your tests, $$$profit$$$!