FAQs

CONTRACT

Our contract process is simple and streamlined. Once you agree to engage us, we will send you a contract document to sign over mail. On receipt of the same, the engagement gets started.

We usually require 2 weeks to get started from the point we get the go-ahead. However, based on your needs and urgency, we can get started earlier as well.

Because of our model and the significant investment that we make to onboard the team on your behalf, we start with at least a 3 month period. However, we can always make exceptions based on your needs. Do contact us to discuss your particular project needs.

Because of our model and the significant investment that we make to onboard the team on your behalf, we start with at least 3 testers. However, we can always make exceptions based on your needs. Please do contact us to discuss your particular project needs.

ONBOARDING

We usually need your product and software-related document to get our team onboarded. We would also need the existing test if any, cases that you have. We also need time from your team at the beginning of the engagement to go through and understand your software in detail.

We generally suggest a time period of a couple of weeks for the onboarding process. We would need a few hours from your team, depending on the size of your software and the scope of testing to understand the software in detail so that we can test it effectively.

We need your software business requirements documents to understand how your software works. In the absence of them or if your software is not very well documented, we will need time with your team to understand it.

Yes, please get in touch for details. We provide end-to-end testing that can start from scratch and doesn’t need any test cases or test management to have been present prior to engaging us. Our team will provide the test strategy and do the execution.

BILLING

You don’t have to pay anything upfront. We agree to a contract with you and we invoice you at the end of every month, beginning from the first month.

You have 30 days to pay after receiving the invoice from us. Post that, in case of non-payment, we will remind you and will stop working if we don’t hear back.

You are billed a pre-agreed amount at the end of every month. This amount is based on the number of testing resources that have worked for you that month and their rates. All this is outlined in the signed contract. This billing amount never changes without mutual consent from both parties.

 Invoices are raised at the end of every month/after working for 30 days, whichever will be the case as mutually agreed upon previously and mentioned in the signed contract.

You will be billed and the invoice amount will be what has already been agreed upon per the signed contract. There is never overbilling on our part unless agreed upon previously in certain circumstanæs, like additional testing resources to the team. In such a case, either the previously signed contract will be amended or you can email us as well based on which we can agree to the new resource number and rates.

TESTING PROCESS

We can test your app on a variety of devices across the major platforms including both android and iOS. We can also test your app across Mac or Windows PC as well as your web/cloud-based apps across the most commonly used web browsers including IE/Edge, Chrome, and Safari.

We can test your web/cloud-based apps across the most commonly used web browsers including IE/Edge, Chrome, and Safari. We can also test your website for the mobile web including Safari for iOS, and Chrome or Firefox for Android.

Yes, our testers will write cases in conjunction with your product development team as well as our test architect and delivery manager. The test cases will be routinely maintained and updated as needed. Also, they will continue to add test cases based on new features added to the application.

Yes, our testers will execute the test case every test cycle and will produce a text execution report as well as a bug report. Once your development team fixes the bugs, they will retest it to make sure the bug is indeed fixed.

DELIVERY PROCESS

Our team works hand-in-hand with your product team to deliver the test cases and test results. We constantly update you on our testing status and retest the code when a bug is fixed to make sure it has been fixed indeed. We also give a final sign-off on your code before the code release happens.

Yes, please refer to our How it works section and Why us section for details. We provide end-to-end testing that can start from scratch and doesn’t need any test cases or test management to have been present prior to engaging us. Our team will provide the best test strategy and do the execution.

Our team will deliver a comprehensive bug report after every test cycle. They will also deliver an interim bug report after every reported bug has been fixed.

Yes, our team provides a complete QA clear. They will test the entire application and make sure it’s bug-free before providing a QA clear/Go-no-Go certificate.

COMMUNICATION

Yes, our delivery manager will be in touch with your product/engineering manager on a daily basis to update on the status of the day’s work and co-ordinate the activities for the next day. This usually happens through a recurring meeting or a scrum call, if the team is following Agile.

Yes, we normally hold review meetings every month with the management where the delivery manager would present and brief on activities for the past month and roadmap for the second so that there is an opportunity for course correction. This would usually be attended by the delivery head from the QAonCloud side and your management team.

You can communicate with the team using emails/Slack or any other messaging platform that you use. On a daily basis, our delivery manager would also have a call with your team to coordinate.

You can certainly communicate with the testers through email/Slack or any other messaging platform. You can also have Skype of similar calls with them as and when needed.

We use Slack internally for communication, however, the team can use any app that you are already using in your project for internal communication.

Of Course our testers can easily join the app. Keep communicating!

For our internal use, we use Asana for project management. We are happy to refer that to you if you are not using any or we can work with whatever project management tools you are using for your project.

SECURITY & IP

As part of our delivery, you would own all test cases, mind maps, test strategy documents or any other delivery item created. They are yours to share and use as needed.

We are extremely sensitive to the IP of your application and have established processes to keep it safe. Our test centers are secure and follow the security best practices. All the testers are also our full-time employees and sign an NDA with us that covers your software application as well. We ensure that your IP is in safe hands.

All our test centers are secured. We follow the international best practices for this and ensure that your application is in safe hands. Please refer to our Security page for more info.

The QA architect is a domain expert and can provide consulting services on the testing. He would initially prepare the test strategy document and the roadmap for testing, in the absence of testing presence, and can be in review meetings thereafter to advise on the best practices as well as bring the test strategy up to date.

The delivery manager is the one you would be in most frequent touch with. She would connect with you on a daily basis and would be the primary contact point. She would also ensure that the day’s activities are completed and manage the testing team from here.

Yes, our team does Regression Testing on all your existing code to ensure that nothing is broken in existing functionality when you are trying to release new features for your software. This is essential for feature continuity.

Often, when we try to add new features for new releases to our existing software, many times some existing functionality gets broken. This can be catastrophic based on the type of bug and at a minimum will look bad. So it’s essential to retest the entire existing software to make sure that no bug has been introduced as a result of the addition of new functionalities. This is called Regression Testing and is an essential component of bug-free product rollout.

Have More Questions?