A Sneak-Peak Into Real App Testing Process With Techugo

Testing is not an option for your app….we heard this quite many times…

But how does this testing really happen in the background of app development?

Well, that’s really a question, because most of the information over the internet only speaks of the process which is a documented process, but no one gives a real insight of what actually takes place in the Testing.

And this is what every client wants to know that how the App Testing takes place within the app development company. So we have requested Lakshman Kumar- Senior Test Engineer with Techugo, to give a brief out about the app testing.

So below mentioned are some of the excerpts from the intense discussion we had together over a cup of coffee….

What is the first most step you take?

The moment we are awarded any project, an initial project familiarity meeting is arranged, wherein we discuss the client and his project requirements? What are the project duration and delivery time-frame? Who is the targeted audience? What are the supposed challenges? Required technology and many other technical aspects?

The best part here is that in such meeting every single individual involved in the project i.e; manager, Tech leads, QA leads, developers, testers etc. are present and each of them are encouraged to give any input or feedback to improve the app usability, which if find appropriate, can be discussed with the client to be integrated in the app.

I worked before as well with different app development companies across the nation, but such open environment I have found only with Techugo.

Greatt…then what is the next step?

From the SRS (software requirement specification) project plan is developed. The responsibility of our (testing team) is to create a software test plan from this SRS and project plan.

The developers start coding from the design and the project work is bifurcated into different modules and these project modules are distributed among the developers.

In the meantime, we have to create test scenario and write test cases according to the assigned modules.

We try to cover almost all the functional test cases from SRS.

The data can be maintained manually in some excel test case templates or bug tracking tools.

Ohhh long process? Then what you do?

Yes, it is a long process, but trust me this only helps our developed apps to gain popularity and success with an ease.

When developers finish the individual modules, those modules are assigned to the testing team.

My team performs the smoke testing on these modules and if they fail this test, modules are reassigned to the respective developers for a fix.

For the cleared-checklist modules, manual testing is carried out from the written test cases.

If any bug is found that gets assigned to the module developer and get logged in bug tracking tool.

On bug fix, a tester does bug verification and regression testing of all related modules.

If bug passes the verification it is marked as verified and marked as closed. Otherwise, above-mentioned bug cycle gets repeated.

Then what is there next in the bucket?

Well, then different tests are performed on individual modules and integration testing on module integration.

These tests include Compatibility testing i.e testing application on different hardware, OS versions, software platform, different browsers etc.

Load and stress testing are also carried out according to SRS.

And???

Finally, system testing is performed by creating virtual client environment. On clearing all the test cases test report is prepared and the decision is taken to release the product!

So this was a brief outline of the process of Testing.

But what if somebody wants to keep a checklist?

In that case, you can follow these steps

• SRS Review: Review of the software requirement specifications
• Objectives are set for Major releases
• Milestone Date planned for the Releases
• Detailed Project Plan is built. This includes the decision on Design Specifications
• Develop Test Plan based on Design Specifications
• Test Plan: This includes objectives, the methodology adopted while testing, features to be tested and not to be tested, risk criteria, testing schedule, multi-platform support and the resource allocation for testing.
• Test Specifications: This document includes technical details (Software requirements) required prior to testing.
• Writing of Test Cases
• Smoke (BVT) test cases
• Sanity Test cases
• Regression Test Cases
• Negative Test Cases
• Extended Test Cases
• Development – Modules are developed one by one
• Installers Binding: Installers are built around the individual product.
• Build procedure : A build includes Installers of the available products – multiple platforms, like ” Diawi.com “.
• Testing
• Smoke Test (BVT): Basic application test to take decision on further testing
• Testing of new features
• Cross-browser and cross-platform testing
• Stress testing and memory leakage testing.
• Test Summary Report
• In this Bug report and other reports are created

• Code freezing
• No more new features are added at this point.

• Testing: Build and regression testing.
• Decision to release the product
• Post-release scenario for further objectives.

That’s all…and this is the exact step-by-step strategy we follow with each of the projects with Techugo.

Thus, if you want your app to be developed and well-tested to avoid the risk of app rejection from the stores and the users, then get in touch with the Techugo, would be your perfect choice.

Thank you, Lakshman for your time, we will surely keep a note of this information and hope that our readers would also enjoy reading it….

You can reach us at:
sales@techugo.com
Skype: aks141
Skype: ankit.techugo