Jean Barmosh and Jimmy Jacobson are correct. I just want to elaborate with my experiences:
1. Integrated and System Testing is a requirement for large companies and stable products. For small startups where you have 2 developers who are essentially rapid-prototyping, it is often an incredibly stupid idea and complete waste of resources. Tests take time to write and manage. You need to decide a tradeoff on what is more important now -- product features or automated tests? With one engineer, that is going to have a huge impact on your velocity. If the product is changing 3-4x a week under the current velocity with 1-2 developers , you're looking at only being able to do 1-2x deployments if these engineers are responsible for these tests. You're also looking at spending a few weeks at 0-1 deployments for the core set of tests to be initially written.
2. No matter what you automate, you should still have a human go through with a Visual + UI/UX QA . Integrated tests rarely cover everything - CSS will often break, and randoms buttons/links will 404.
3. Having engineers test their own work is a generally bad idea. Most will have "tired eyes", look at the pages and simply not realize obvious mistakes. They've spent the past week so focused on the left side of the page, that the right side of the page could be completely missing. Then you have the "cultural shift", where something that is acceptable (or a great idea!) to an Engineer is *entirely* unacceptable to a non-engineer.
As someone who has managed many development teams -- and someone who believes in frequent ships -- your characterization of the situation worries me. The notion of only 1-2 people being responsible for the product AND doing multiple weekly product releases is troubling. "Lean Startup" methods and frequent ships are great -- but even with automated build+deploys , there's a certain amount of admin overhead and oversight that should be going on. I'd be inclined to think that this engineer is either being overloaded by the greater team or biting off more than they can chew. The idea of dropping on additional testing requirements to them seems like an untenable situation. If something does break, you're taking a potentially frazzled engineer and throwing him into disaster recovery mode.
If there are only 1-2 engineers responsible for the product , then there are probably 1-2 non-engineers who should be helping out to reduce the workload on the product development team. Personally, I would probably have them (i.e. you) start to work on building out the Selenium tests and I would target 1-2 product deployments a week (unless there are critical bug fixes, which are always ASAP). My rule of thumb has always been that you shouldn't target more than one deployment per-engineer per-week. ( if you have a small, advanced team that built out a huge testing and deployment structure, this doesn't apply. ).
I agree with all the testing recommendations and strategies that people have been noting above. At 3+ engineers, this is a totally different story -- but at 1-2 engineers ? From a resource management perspective, it just worries me.