Perform a quick check against a given application: web, software, game, you name it. This usually takes about 1 day and is requested by users for their final product that was already tested, in order to receive an outside feedback for their product regarding usability, speed and main functionality.
This package is required by clients who wish to validate their e-commerce flows, from cart functionality to checkout processes. It usually takes more time to complete since each site has its own requirements and is usually supported across different devices and browsers, thus resulting in more (complex) scenarios that need to be validated.
CI & TEST AUTOMATION
Either API or Functional automation, this is usually performed against websites or APIs that are already in some sort of final form, prior to some refactoring that will be performed or prior to some future integrations that require a safety-net, just to make sure nothing breaks. This set of tests are usually integrated with a CI machine, giving a way faster feedback than a manual test.
MOBILE APP TESTING
Clients chose this package usually for standalone apps that are dedicated to mobile consumers and want to make sure their app works flawless on phones or tablets, on Android or iOS and are not necessarily supported on web browsers or desktop devices.
Internal teams tend to over standardize their procedures. They get used with the product and tend to focus on finishing tasks. It becomes a formal process that is used to tests things in exactly the same way. Eventually, they start having the 'test to succeed' mindset instead of 'test to break'. It's not easy for managers also. Maybe there's some delay and you need to compensate by bringing more testing resources. You have the budget, but you don't have the approval of getting more headcount because you only need it for two weeks.
External teams usually have fresh eyes and more time for exploratory testing. They focus on finding defects and providing data about the state of the product without necessarily following a scripted path. If planned ahead, they can even shift more of their resources towards a specific project for a short period of time. The downside of an external team is that they might not know the business as well as an internal team or as a final client and might miss some obvious defects if the project is not properly documented.
So, if you're not testing rocket engines or robots performing surgeries, you're better off having an external team. If your product won't leave your business and is targeted towards a specifically highly qualified group of people, maybe you should train an internal team.
Even if you fully trust your internal testing team, we do recommend to spend a little extra effort in having an external team take a look at the product in order to insure that the quality standards you have are met. If you're not sure don't hesitate to drop an email. We'll do our best in helping you choose what's best for you.