Software test estimation - Tips to Estimate More Accurately

I am trying to put some points on estimations in a very simple manner, which is helpful to prepare good test estimations. I am explaining how to estimate tasks and general tips to help us to estimate more accurately.

• Try to have your brain storming sessions with Business Analyst, Development and QA team. Here you cover the all points & drill down these to each functional level. Try to prepare a document called WBS which contains the testing points & scenarios to be considered while testing. If time does not permits to do this, then please make sure that you have keep rough notes which will help preparing basic estimation.
• Understand the requirement & scope of the project. List down all types of testing which we need to covered under each deliverable.
• Resource planning in estimation plays a key role to get. The availability of resources will help to make sure that the estimations are realistic. Here you have to consider the leaves for your team member, generally long leaves.
• Recognize in initial steps if we require security or performance testing. If yes, tackle estimating this should be in separate way.Identification of testing environment is one of the important points to be considered in estimation. It might be possible to use same environment for different modules based on your test planning.
  
•  Preparation of test cases, test data based on the different deliverable. Don’t forget to add time to do review & sometimes rework to be done.
• Mostly while estimating we generally missed to add time for bug life cycle. For bug life cycle we basically required time for bug triage & defect management, so Consider the Bug Cycle in estimates.
• Make sure that what kind of activities can be executed parallel which can reduce the effort time by half; saved time can be used for buffer as well.
• Past experience with same would be the added advantage to do better estimation process.
• Estimations Can Go Wrong – So re-visit the estimations frequently in initial stages before you commit it.
  

All the time, put out the some assumption with your estimations:

• This estimation effort is given based on assuming that 5 senior QA members are working on this project. This estimation effort assuming that testing team will get continuous testable build. This estimates vary by + 5%.
• This is testing effort only for functional & UI testing.
• Once the first round of testing is completed then effort for Regression testing will be estimated differently based on the bug statistics.
• Final point to be considered is ‘Buffer’; you have to add some time as buffer. Adding how much time as buffer is totally based on your project complexity & how critical modules are. Think of Your Past Experience to Make Judgments!

Emulated and Real Device Mobile Testing

Depending on your application, you will have to assess whether testing on an emulated device or real device is the best option. Many times it is not either/or decision and the best choice is both. Emulators offer the less expensive testing option, but they have many limitations for mobile testing and may not give an accurate depiction of the mobile user experience.

However, as part of the mobile testing process the use of emulation has an important role. There is certain testing that you can conduct with emulators that are sufficient which include testing for screen size or visual form factor. However, emulation is often an approximation of the rendering and can only get you so far.

Leveraging emulators is a positive step towards real device testing, however, not sufficient for comprehensive testing needs. With cloud-based testing you no longer need to have a bunch of people in a room with different mobile devices.

Testing on real devices gives the tester full functionality of the mobile device. While device types may be more limited than the emulated devices, testers should be able to have access to the real processor and hardware to understand the quirks that some real device have. Without this ability, users may not discover some real life issues that device differences would present in a real environment versus in an emulated environment.

It is important to conduct real device testing when needing to test mobile engagement with the device, launch applications, and interact with device at a more detailed level.

Keynote offers some useful free tools to perform mobile testing. Developers and testers can quickly conduct interactive functional testing on their websites from the convenience of their desktops with remotely accessed real devices and an accurate device emulator.

Cloud Based Testing Tools

 IT community along with business community have started unleashing their power by using Cloud Computing. There are Many cloud based tools for various aspects of IT development. Have made attempt to list the top cloud based tools being using for different aspects of testing including test management, performance testing etc. Some of the benefits of using Cloud based testing tools are reducing costs( licensing, infrastructure, usage charges...), Usage flexibility, Selecting right tool for the job as well as getting started immediately etc. Here is the list.

CloudTest 

 SOASTA CloudTest offers a single, integrated platform for functional and performance testing. Designed for testing modern Web and mobile applications, CloudTest’s patented visual test creation environment enables rapid creation and editing of even the most complex tests. By leveraging the cloud, tests can be distributed globally, executed at any scale, and run affordably. And real-time analytics provide immediate, actionable intelligence – a requirement for testing live production environments. The SOASTA CloudTest Platform offers a comprehensive set of components and access options that enable teams of any size to execute frequent, scalable and affordable functional and performance tests from inside the lab through to live production.

 Parasoft SOAtest

 Parasoft SOAtest automates web application testing, message/protocol testing, cloud testing and security testing. Parasoft SOAtest and Parasoft Load Test (packaged together) ensure secure, reliable, compliant business processes and seamlessly integrate with Parasoft language products (e.g., Parasoft Jtest) to help teams prevent and detect application-layer defects from the start of the SDLC. Moreover, Parasoft SOAtest integrates with Parasoft Virtualize to provide comprehensive access to traditionally difficult or expensive to access development and test environments. Parasoft SOAtest is an integrated solution.

CLOUDTESTING 

Cloud Testing’s mission is to make robust Website Content Compliance simple, secure and cost effective. Cloud Testing service allows you to automate the functional and cross browser testing of your websites using the industry standard Selenium framework and real browsers real operating systems.

BlazeMeter 

BlazeMeter is a testing cloud with a sole focus on load testing, designed to simplify performance and load testing for developers and QA testers. BlazeMeter provides developers and QA testers self-service tools to build failure resilient applications.

LoadStorm

LoadStorm is an on-demand load and performance testing tool that utilizes Amazon Web Services for massive scalability. It is a web application that allows developers and testers to generate large volumes of virtual user HTTP traffic against a target server application. Rather than providing a million features, the design goal of LoadStorm is to make load testing as scalable and cost-effective as possible.

Keynote 

Keynote is the global leader in Internet and mobile cloud testing and monitoring. With Keynote, companies know precisely how their Web sites, content, and applications perform on actual browsers, networks, and mobile devices. Keynotes' unique business model enables you to control your costs and maximize productivity with the high-reliability and cutting-edge performance of its on-demand test and measurement products and services. You can start receiving performance metrics now and resolve critical problems long before your customers are impacted with immediate access to the world’s largest test and measurement network.

TestMaker 

TestMaker is the easier way to surface performance bottlenecks and functional issues in Web, Rich Internet Applications (RIA, using Ajax, Flex, Flash,) Service Oriented Architecture (SOA,) and Business Process Management (BPM) applications. TestMaker 6 rapidly puts the PushToTest Methodology into your hands for a test tool that installs on your desktop, runs tests in grid and cloud environments, and pinpoints root causes and offers mitigation.

Opensource Tools For Security Testing

Its easy to find on a day to day basis that your website is hit with numerous unwanted bots trying to sneek in, hack in all the time with malicious intent. As a website owner myself i get annoyed of such attempts although i realize my every attempt to add new line of code to the website has to be robust enough and has to be thoroughly tested for security to avoid any security vulnerabilities. Recently we started to do a bit of search around free and open source security testing tools available in the industry that development/testing community can use to identify security loop holes. Well if you are having similar issues, here are few of them you could use.

Watcher

Watcher is a runtime passive-analysis tool for HTTP-based Web applications. Being passive means it won't damage production systems, it's completely safe to use in Cloud computing, shared hosting, and dedicated hosting environments. Watcher detects Web-application security issues as well as operational configuration issues. Watcher provides pen-testers hot-spot detection for vulnerabilities, developers quick sanity checks, and auditors PCI compliance auditing. It looks for issues related to mashups, user-controlled payloads (potential XSS), cookies, comments, HTTP headers, SSL, Flash, Silverlight, referrer leaks, information disclosure, Unicode, and more.

Wapiti

File Handling Errors (Local and remote include/require, fopen, readfile...)Wapiti allows you to audit the security of your web applications. It performs "black-box" scans, i.e. it does not study the source code of the application but will scans the webpages of the deployed webapp, looking for scripts and forms where it can inject data. Once it gets this list, Wapiti acts like a fuzzer, injecting payloads to see if a script is vulnerable. Capable of handling following. Wapiti supports Database Injection, XSS Injection, LDAP Injection, Command Execution detection, CRLF Injection and many others.


 Websecurify

 Websecurify is an integrated web security testing environment, which can be used to identify web vulnerabilities by using advanced browser automation, discovery and fuzzing technologies. The platform is designed to perform automated as well as manual vulnerability tests and it is constantly improved and fine-tuned by a team of world class web application security penetration testers and the feedback from an active open source community. WebSecurify supports SQL Injection, Local and Remote File Include, Cross Site Scripting/Request Forgery, Information Disclousre Problems, Session Security Problems to name a few among many others.

 BFBTester

BFBTester is good for doing quick, proactive security checks of binary programs. BFBTester will perform checks of single and multiple argument command line overflows and environment variable overflows. It can also watch for tempfile creation activity to alert the user of any programs using unsafe tempfile names.

Wireshark

Wireshark, formerly known as Ethereal, is used by network professionals around the world for troubleshooting, analysis, software and protocol development, and education. It has all of the standard features you would expect in a protocol analyzer, and several features not seen in any other product. Wireshark supports Multi-platform and runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others. Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility. - See more at: http://www.toolsjournal.com/testing-lists/item/217-10-free-and-opensource-tools-for-security-testing#sthash.xeYRYDtP.dpuf

Wireshark, formerly known as Ethereal, is used by network professionals around the world for troubleshooting, analysis, software and protocol development, and education. It has all of the standard features you would expect in a protocol analyzer, and several features not seen in any other product. Wireshark supports Multi-platform and runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others. Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility.   
 Flawfinder
  Flawfinder searches through C/C++ source code looking for potential security flaws. Flawfinder is designed in Pyton and produces a list of ‘‘hits’’ (potential security flaws), sorted by risk; the riskiest hits are shownfirst. The risk level is shown inside square brackets and varies from 0, very little risk, to 5, great risk. This risk level depends not only on the function, but on the values of the parameters of the function. For example, constant strings are often less risky than fully variable strings in many contexts, and in those contexts the hit will have a lower risk level.

Steps to Learn Perfect Security Testing

It is becoming more common for software applications to be written using web technologies, and for users to want to access them from anywhere, using an internet connection. Security of browser-based applications is very different from how things work with traditional thick-client architecture. There are far fewer boundaries between different web sites inside the browser than between different pieces of code that run on your computer under the control of the operating system. Security testing is therefore a very important part of testing web applications, which means that these skills are growing in demand for QA teams. Even for an experienced tester, web application security can seem daunting. How do you start building up these skills? Where can you turn to for more information?

In fact, security testing is in many ways similar to functional testing. You identify a risk, define what the expected behaviour should be, and then perform some testing to mitigate that risk by demonstrating that the unexpected does not happen. For example, say the system under test is an internet-facing web application, backed by a database. A risk could be that an attacker somewhere on the internet could use the front-end and gain access to sensitive data stored in the back-end (this is called SQL injection). The expected behaviour in this case is that the application will not let this happen – user input will not be directly pasted into an SQL statement that is executing on the database. To test this, you may try manually entering strings that you suspect might confuse the application into executing your commands, or use an automated tool to do this for you, or perform a code inspection to see how an input string will be treated.

The main difference when security testing is one of mindset. When functional testing, you are trying to prove that a feature works for an end-user – it does what they expect, and does not hinder them from completing their tasks. You would probably prioritise accordingly – focus on features that are used more often, used by more users, are considered the most important, etc. As a security tester, your ‘end-user’ is now an attacker trying to break your application. The goal of your testing is to prove that a specific attack scenario does not succeed, for any attack scenario. A significant difficulty here is that proving that a feature works is much easier than proving that a specific feature cannot be hacked by any method. You could use a similar prioritising approach as with functional testing – test only a set of most likely or simplest or most popular attacks for each feature. Another point to note is that popular developer responses to bug reports such as “a user would never do that” and “won’t fix – feature is hardly ever used” are simply not valid when security issues are involved – a potential attacker can do anything they like to perform a successful attack.

In this post, I will outline some tips for building up team skills in security testing.

Basics

1. Understand your own application

It is important to be familiar with the application you are testing so that you can assess where the risks are. Everything else will assume that you have this knowledge – the technologies used by the application, the profile of different users, the abilities you should and shouldn’t have with different levels of access, and the potential data that is stored by the application. The testing you would do is very different for a website that simply displays pictures of cats over the internet to anonymous visitors, versus one which sells pictures of cats to logged-in users who need to enter their credit card details.

2. Understand security terms and definitions

OWASP is a great source for this. The volume of terms and concepts might be overwhelming at first, so just concentrate on understanding some of the terms, preferably the ones most likely to apply to your application. Examples may be XSS, XSRF, SQL injection and path traversal. The CWE/SANS Top 25 lists the most widespread and critical errors that cause vulnerabilities. For an exhaustive list of all known attack methods check out CAPEC.

Build Knowledge

3. Use online training tools

A great way to start learning is to start testing an application which has known vulnerabilities, where you are provided with guidance on how to find them. My preference is for Google’s Gruyere which has separate lessons to cover each concept. You can look at hints to help you find the vulnerability, and the answers if necessary.

4. Learn from others

It is likely that among the developers in your company, there will be some with knowledge of security topics. Ask them to pair with you to investigate the application behaviour. They should be able to demonstrate, for example, that a SQL injection string is not executed on the database server, and why it is not. If it is, then that will be educational for you both. They can also explain to you the design of the application and how it is intended to protect from attacks. If there are many people wanting to learn about security, get them to give a presentation.

5. Learn to use an automated vulnerability scanner

A good commercial option is Burp Scanner; there are also free options such as OWASP’s ZAP and Google’s RatProxy. These work by routing the HTTP traffic to and from an application through a proxy, and then resending the requests with various attack attempts replacing the original values. This can be an effective way of finding certain classes of vulnerability in a short amount of time, but it is important to understand (and make sure that your stakeholders understand) that this is not a magic bullet. The tool is naive, and has no knowledge of the applications business logic – it is simply replaying requests and checking the responses. There are many types of vulnerability that can not and will not be found with this strategy, and use of a scanning tool absolutely does not replace the need for manual security testing.

Automated tools, even expensive ones, find only relatively simple vulnerabilities and they usually come up with a lot of “noise”, or false positives. You need to know enough about security vulnerabilities to be able to evaluate each finding of the automated tool. Taking a scanner report and sending it unverified to the developers is the worst possible thing one could do.

Share Knowledge

6. Pass on what you are learning

As you start to build up knowledge, make sure that others also benefit from it. Give a presentation on some of the basic security concepts. Run a class about how to use an automated scanner. Both developers and testers can learn from you, and you will cement your own grasp on the topics.

7. Convince people that security is important

You may work with individuals who don’t know or don’t care about security issues – perhaps they are new graduates, or have previously worked in places where the software was firewall-protected. It is worth raising their awareness – remind them of the backlash against some big-name companies that have lost user-data. When your testing finds a vulnerability in an application, make sure you demo it, along with the potential exploits that can follow.  A good tool to demo is BeEF – which shows just how much power a simple XSS vulnerability can give you over another user and their browser.

8. Communicate security issues in context

It is important that you evaluate all security vulnerabilities you discover in the context of your application. A cross site scripting vulnerability that is only exploitable in obscure conditions is much less important that a vulnerability allowing someone to run any code on your web server. You may want to establish a scoring system for vulnerabilities you find. One of popular scoring approaches is CVSS. In addition to scoring, consider the business context – what happens if the attack succeeds? Losing pictures of your cats is of less impact (generally speaking) than someone tampering with company’s business records. If you need to prioritise what should be fixed, prioritising based on impact usually works better.

Maintain

9. Use good default test data

When testing a feature, you will probably be creating test data. Instead of using ‘test1′, ‘test2′, etc. or cartoon character names, get into the habit of using attack strings. This way, you’ll find you come across vulnerabilities almost by accident, just when using a feature. If you have an automated tool or import file providing the test data, do the same thing. You can share such data with other testers and developers, meaning they may come across issues without even knowing they are doing security tests.

10. Practice, practice, practice

Like any skill, you will get better with practice. As you start to find vulnerabilities in an application, you’ll start to get a feel for where they are likely to be in future, and will be able to raise them further in advance. Running regular scans against the code will mean you become more effective at using the scanner. Participate in code reviews and you can start pointing out where vulnerabilities are likely to be before even using the application.

When to automate Software Testing

Being a software tester you might have come across various situations where automation is not advantageous at all and manual testing works better in those situations.

Some examples where manual testing is preferred over automation are:

UI keeps on changing very frequently. If automation is done for this UI it needs to be changed every time the UI is changed.
You have a tight deadline to release the software and so there is very less time to automate so you will prefer to do manual testing and release the software.
So you can see that automation does not solve the problem always, however there are certain situations where automation is very helpful for quality software delivery.

Some of the examples where automation is helpful are as follows:

Regression testing: Automation is very helpful in regression testing because the regression test suite needs to be executed every time there is some defect fix to find out that no new issue has been introduced due to that fix. So regression test suite is the best candidate for automation.
Automation supports Agile testing and eXtreme programming: In Agile development there are time boxed iterations of usually 2-3 weeks in which a working software is developed, in each iteration some new features are incorporated which requires full testing of the software, in such situation automation helps to test the whole software in each sprint.
Automation provides rapid feedback to developers during the software development process: Automation does continuous integration and nightly builds which provides daily feedback to developers if anything breaks in nightly build.
Automation is also helpful where there are large number of iterations of test case execution.
Automation helps to find out the defects missed by manual testing.

What are the hidden mobile app security threats to look out for?

Mobile apps are interesting because, in many businesses, they're seen as a cutesy marketing tool that needs to be thrown together on a whim. After all, in the minds of many, if you don't have an "app in the app store" then your business is not legitimate. This whimsical reputation sometimes keeps companies from putting a serious focus on mobile app security.

    Web application security is a relatively new frontier but mobile app security is entirely new.

Web application security is a relatively new frontier but mobile app security is entirely new. That said when it comes to mobile apps running on common platforms such as iOS and Android, many of the same security problems exist in mobile apps that we've seen in Web applications such as:

    Lack of input validation
    Poor session management
    Feeble or non-existent encryption protecting data in transit and data at rest
    Authentication and password weaknesses

In that regard mobile app security is very similar to Web application security.

However, mobile apps are a different beast when it comes to testing. You can't use traditional Web vulnerability scanners – at least in the familiar point-and-click kind of way. There's more manual testing involved using the mobile devices themselves along with some potentially unfamiliar forensics and network analysis tools. Another proven method for testing mobile apps is to perform a source code analysis using tools by vendors such as Check marx or Veracode.

One final thought is about the mobile-enabled versions of your websites/applications. The flaws are basically the same, but in terms of what needs to be tested, you don't want to overlook your mobile-enabled sites/applications.

MORE ON MOBILE SECURITY THREATS

You may also want to check out this illustrated explanation of OWASP's top ten list of security vulnerabilities for the mobile enterprise.

Test them from both traditional PCs as well as mobile devices. You might be surprised at the varying results you get back.

All in all, mobile app security is a great new space to be working in. I'm truly enjoying it. Just stay true to the basics we've known all along: finding and fixing the basic flaws can provide a ton of value. The OWASP Mobile Security Project seems to be a good resource that's shaping up in this area.

Guidelines for writing good and effective Defect Entry.

1. Keep the Defect Summary concise.

The defect summary should be very concise and to the point, developer should not need to scroll through the synopsis. For example, “Customer data import fails when .zip file is selected”. Also it is a good practice to indicate the affected area by putting one or two words before the defect summary. For example “Database: Customer data import fails when .zip file is selected”

2. In description write clear steps to reproduce the problem.

You should provide clear steps to reproduce the problem, the steps should be detailed so that anyone who is trying to reproduce the problem does not face issues in doing so.

3. Describe the test environment in detail.

There are many defects which can be reproduced only in certain environments, so it is very necessary to describe the test environment in detail on which the defect occurred. Whenever the developer looks at the defect he needs to know on what particular scenario did that defect occurred. You should clearly fill out the platform/OS/environment fields and describe whole test environment in the description field.

4. Do not be too verbose, keep to the facts.

While entering the defect description you should keep to the facts, do not put irrelevant information.

5. Attach snapshots and Logs.

A snapshot or defect logs are very important thing because they can clarify the defect by just seeing them, so always take snapshots to the problems occurred and attach them to the defect entries made. Make sure you use compressed images like Jpegs to keep the snapshot size small.Also if your find that the error is logged into the log file, attach it to the defect entry as well. If the log file size is large cut the small section containing the error or compress the log file using zip/tar utilities.

6. Assign appropriate severity and priority.

You should assign appropriate severity and priority to defect. Usually you can follow a rule to assign same priority as severity however this does not hold true for every defect, so you should properly study the severity caused by defect and then assign a priority to it, there are defects which are less severe but they have high priority for example, A spelling mistake on the login page of web portal does not cause any threat to the system functionality however this needs to be fixed because everyone logging into the system will see that error.Severity levels can be tweaked a little bit by organizations as per their defect life cycle guidelines however the general levels of severity and priority are as follows.

Severity:

1-Critical
2-High
3-Medium
4-Low

Priority Levels:

P1 – Fix Defect Immediately
P2 – Give high Attention
P3 - Normal Queue
P4 – Low priority
P5 – Can be deferred

7. Multiple issues should not be grouped into a single defect entry.

Most of the times we find many defects while testing one single area, usually test engineers club multiple issues into one defect which is very bad practice. Never club two issues in a single defect, always create a separate defect for each problem.

8. Do not enter duplicate defects.

There is a possibility that the defect that you just uncovered has already been found by someone and logged into defect management tool. So before logging a defect always search the defect management tool to find out that there is not such defect already logged, also its a good practice to consult other testers who have worked on the same functionality and find that no one else has entered same kind of defect.

Testing mobile applications is different than testing Web applications

In order for imo to grow out of its infancy as a purely Web-based messaging application and spread its wings as a new mobile messaging application, the development team had to overcome a lot of challenges. In part one, Erdal Tuleu, director of engineering at imo, discussed the biggest challenges of moving from Web-based to mobile applications. In part two, Tuleau moves deeper into the differences between mobile and Web-based applications and gives advice on testing mobile applications.

What makes developing and testing mobile apps really different from traditional Web applications?

 In the past it wasn't too common to have more than one station. People usually logged into their laptop or desktop and closed it before going home and logging in again there. Now it's fairly common for people to have more than one station. For example, you can have it open on your laptop and again on your phone. I don't think it's that common anymore to sign out and sign back in all the time. People want to always be online and always reachable.

With that came the challenges of maintaining all those stations. How do you know which station you want to deliver the message to? For example, with our very first mobile version, if you were chatting on your laptop, every incoming message would also beep on your phone, which is pretty annoying. You can imagine an office where everyone's phone is beeping all the time. That was one thing we wanted to improve. Now we do a pretty good job at being smart about which station the user is chatting from and where they're active. We are smarter about where we think you want to receive your messages.

We know which client users are sending messages from and also to some extent we can tell which client they are reading messages on. So from that data we have logic on the back end that can determine where the most important place to send a new message will be.

Another thing is that if users are always signed in, we don't want to bug people at night unless it is really important. I think we can still improve this, but we have a restrict mode feature which lets you pick a time -- you might say I sleep from 11:00 p.m. to 6:00 a.m. -- and then it just turns on by itself every night and doesn't make as much noise when someone messages you. But there are also emergencies, so we need a way to be able to break out of that. That's one thing we added to make customers' lives a little bit easier.

What is your testing process like? How do you go about testing mobile applications?

 Well, we have a lot of devices in the office and we have people using them all the time. Not just the developers, we have pretty much everyone working at imo actually using imo and testing it, too. A lot of us are running around with a whole bag of mobile devices. Right now, I personally have a Galaxy Nexus, an iPhone, an iPad Mini and a Nexus 7 tablet.

We basically all use iPhones and iPads at home and we have a lot of devices in the office. The iOS tends to be easier to test because there is less variation. For Android, we look at market stats to pick the most popular models and buy them for the office and make sure people use them, too. We also put out a beta version on Android to get more user testing.

But it's not all crowdsourced testing. We also do a lot of code testing before it gets released to any sort of user testing. Sometimes we program in pairs and we always require all commits to be code reviewed. So I think it's a good mix between traditional testing methods and crowdsourced usability and bug testing.

After we design and commit a new feature, we'll give it to the employees to test it for a week and give us their feedback before we submit it to the app markets. For example, when we launched voice calls we had everyone call their families with it. That was good because it covered different carriers and different countries, so we got a lot of great feedback from that testing round.

When we first started testing mobile applications, we were less focused on particular features and more focused on reliability. We needed to make sure the app doesn't lose messages, because that is the most important feature for a messaging application. Initially, we had problems with people losing connections because that wasn't a problem in the Web version. So we knew we had to adjust some things to account for frequent lost connections and for long lapses in a connection like when the user turns on airplane mode.

It's a hard thing to test for, because if you miss a message, you don't always know. It was a really good thing that we had the Web client as well so we could see if there was a message lost there. All the conversations get saved to the user's chat history on our servers, so each client can pull them from there. If a client does go buggy and doesn't receive messages, the messages are still there and the user can get them from a client that's working right.

On the client side, if you send a message while you're in a tunnel, for instance, we have the client hold onto that message and try to deliver it once you reconnect. That was a tricky process to get right, but it's very important because users on the train don't want to wait until they get a connection back to write out their message and they should definitely have confidence that the message will be sent eventually. We have a pretty basic protocol that makes sure messages are delivered -- something like a call and response.

FREE Mobile App Testing tools

here are a few FREE tools to help you with your mobile testing objectives. 

•     FoneMonkey 5: The only tool for iOS that records all actions with the iPhone or iPad (while in use) and plays them back as a test script at any time. Enables interactive creation, editing and playback of automation scripts that exercise an application’s user interface.
•     iPhoney: Provides a “pixel-accurate web browsing environment, powered by Safari”
•     W3C mobileOK Checker: Performs various tests to determine level of mobile-friendliness.
•     Modify Headers: From Firefox: “Add, modify and filter the HTTP request headers sent to web servers. This add-on is useful for Mobile web development, HTTP testing and privacy.”
•     DotMobi Emulator: See how your site looks on a mobile web browser
•     Google Android Emulator
•     Android SDK Emulator
•     iPad Peek
•     BlackBerry Simulator
•     Adobe Device Central CS5

Top 7 Process for Testing & QA to Build Bug Free Software

In present time the foremost part of SDLC process is system testing & QA. If testing process is done properly then software or web application works smoothly without bugs. Testing includes systematic planning, SEO friendly design and complete execution to develop quality software.

The main purpose of system testing is to find defects and bugs as to build quality software. Testing execution incorporates functionality testing and usability testing to identify bugs, give warning and locate errors. Proper relation between applications server and database also comes under testing part.

Testing methods consist of unit testing, integration testing and user testing to build quality system. Quality system becomes successful only when systematic planning implemented in testing & QA. The control of whole system depends on testing, intensive testing process convert into smooth execution of software.

System tester must solve the execution time, reduce risk, recover defects and eliminate other bugs that results into successful software and web applications development. There are many software and web development company offering Quality Assurance and Testing Services (QATS) that assist numerous organizations worldwide to achieve business transformation.

Run Android Applications in Windows

 Android is an Linux based kernel and it is developed using Java. Android is limitless and it can be in anyplace. You can find Android even in unusual places. This post tells you how to run Android Application in Windows. Installing it in Windows helps developers to test without smartphone and try apps before installing in smartphone. Here is a trick to run Android application in Windows. There are two ways to do..

#1. Use Android Emulator
An emulator is an application software which visualize the platform. There are many Android emulators available for free. Two best Android emulators are Bluestack and Youwave.

Bluestack

BlueStacks was launched in 2009. It is the best android emulator to run android apps in Windows.  The company is funded with 15M from Andreessen-Horowitz, Radar Partners, Redpoint, Ignition Partners and Qualcomm. BlueStacks was the winner of “Best Software” at CES 2012 for its App Player software.

Bluestack is rich in features, it supports all apps and messagers with Google Play. Bluestack is available for Windows and Mac OS. But it is slightly disappointing with the user interface of Bluestack.

Official Site: http://www.bluestacks.com/

Youwave

Youwave runs on Android 4.0 and also Android 2.3. The special feature of Youwave is the Simulated SD card functionality. The user interface is also very good as it looks exactly like the Android interface.

Official Site: http://youwave.com/

#2. Install Android OS
By this method, you need to install the whole Android Operating System into an Virtual Machine like Virtual Box and VMware. Not all Android versions can be installed in Virtual machines. Only Android versions which are optimized for virtual machines can be installed in VMware.

Steps to Run Android in VMware
Download the Android OS from https://code.google.com/p/android-x86/downloads/list. I have chosen android-x86-4.0-RC2-eeepc.iso for the test. Also download the virtual machines like VMware(http://www.vmware.com/in/) or Virtual Box(https://www.virtualbox.org/).

Open VMware and select “Create a New Virtual Machine”

Now point android-x86-4.0-RC1-eeepc.iso file you downloaded.

Rename the Free BSD and choose a installation directory.

Increase the size according to your wish.

Click Customize Hardware and increase the RAM capacity. I recommend a maximum of 2GB.

Click the Finish button. Android is now created and is ready for installation. Click the “Install Android-86 to Harddisk“. You can also run the Android as a live CD but it need the .iso file every-time. So I recommend installing it.

Now select Create/Modify partitions and press Enter. The following window appears.

Select sda1 and press Enter. Choose any one File allocation. Also install the GRUB Bootloader.

Create the disk image with 512 MB.

You have completed installing Android. Choose Run Android-x86.

Wait for Android to boot and Enjoy.

This version of Android does not support Audio and Ethernet.

Understanding the Concept of Mobile Application Testing

Apple and Blackberry has certainly set your eyes rolling by introducing the folio thin Smartphones in the world of cumbersome handheld devices. And with this, development of android application seems to interest the likes of customer baseline. So from games, weather forecasts, RSS feeds to social networking, smart phones have indeed become the vital part of our own world. But before we can download these smart phone applications it’s important to have some knowledge about the testing process involved.

The mobile application testing is the salient process that assures proper quality of your smart phones and PDAs. In other words it involves the techniques that reveal the hidden bugs from developed applications. Testing is conducted over both softwares and hardware, which includes R&D testing, certification testing and other factory testing.

Process of Application Testing

The process of testing is certainly long, which may involve monitoring the applications, troubleshooting, testing various contents and other services on real headsets. Other than this, the process includes verification of various hardware devices and legalization of various software applications.

The process has certainly motivated various companies to introduce the testing and reporting of bugs and various issues that require to be reported by customers. The attempt to offer customer a flawless application courtesy the technology in hand is certainly on the rocks.

Features

Some of the features prevalent in the prominent testing procedure are listed below.

    Execution
    Developing a proper strategy or framework for testing process
    Harnessing various test scripts and frameworks
    Reporting the issues pertained during the process of testing
    Cross- platform operability and performance testing
    Testing plans and certification
    Conclusion and analysis of report

And the above mentioned steps are indeed the process that is executed by qualified engineers and other equally smart deft software application builders. In order to provide flawless programs and smooth testing operations, it’s imperative to consult experts with the right knowledge. The entire process requires a proper test field run, which picks up the potential customers and carry the testing procedure.

Quality Feedback                                                                                    

The quality feedback is further used to refine various mobile applications, which need to reach certain level of flawless performance to be called as the best quality product. In case the testing fails the application requires a re-structuring rather than the complete procedure.

The complexities that are the process in testing and verification require a complete team of dedicated professionals who can understand the things properly. There are various nuances of mobile devices, which include their manufacturer and networks that they operate. They utilize the proper ACtP3 framework, which comprises of 5 different phases to test mobile application.

To achieve the desired results of a robust, secure and a responsive mobile application, it’s important to look for multiple mobile device platforms. Here are few other steps that include:

This comprises of recognizing the limits and other features of various platforms and devices to build the strong base and initiating the testing exercises.

     Carry out a crash free testing which may help you in providing the stability in application before starting any formal testing.
    A planned testing can ensure the maximum coverage, which may include tests related to start up, UI specifications in cross mobile OS and localization of application.

It’s imperative to pay out certain amount to achieve the level of mobile application testing. Mobile Application Testing is a necessary part of the entire Mobile Application Development process.

How to Find A Memory Leak

To locate a memory leak, use the following process:

1. Find the memory leak – Detect the presence of a memory leak in the system, given a particular reproducible sequence. You should be able to identify a specific process, but demonstrating an overall increase in committed system memory can qualify a memory leak as well.
2. Isolate the memory leak – Determine the exact location in the source code where the un–freed allocation occurs. This can be a lengthy and tedious process, requiring specific tools, trial–and–error, and teamwork with the original author of the code.
3. Fix the memory leak – After the first two steps are completed, this is easy. Fixing the memory leak usually involves adding some code to free the memory in the questionable code path.

The information that can be gathered in the first step becomes very helpful in completing step 2 and step 3.

Checking Memory

Basically, you can spot a memory leak when you detect an unexplained increase in either committed system memory—memory used by various applications—or in memory owned by a specific application. There are several approaches to take for checking the current memory situation, as follows:

• Run the mi command. At the cesh prompt, type mi. This command generates a list of memory usages for each running application. In the Page Summary line specified for each application, you will see “r/w=” followed immediately by a number. This number indicates the number of allocated pages of memory for the indicated application. If this number is unexpected or has grown unexpectedly, you may have detected a memory leak in the indicated application.

Additional tools are available to snapshot the available memory, however, the approaches described above are recommended.
Remember that only unexpected increases in memory usage suggest a memory leak. For example, if you check memory in the Directions application after starting it for the first time and check it again after calculating a complex route, the memory page number increases. In this case, however, it is an expected increase because the Directions application needed to allocate some memory to calculate and store the route. The best method of determining whether or not a memory leak exists is to perform the same operation multiple times within a single application. An application must allocate temporary memory to perform a new task for the first time. Thereafter, the application can either re–use existing allocated memory or re–allocate the same amount of memory if it was already freed. In either case, the total number of allocated pages should not increase at a value greater than the previous increase.

Best Guide to testing your Web application

We’re now living in a time where users expect as much functionality, reliability and flexibility from Web apps as desktop programs. All our data is slowly but surely moving into the cloud, and businesses are looking to the Web for software to easily implement and deploy across the board – whether it’s accounting, CRM or inventory management. That puts a lot of pressure on developers to deliver rock-solid Web apps that users can genuinely depend on for work and play.
That’s why it’s so important to thoroughly test your Web app before launch. Presenting a quality app that doesn’t break, works efficiently and delights users naturally builds a foundation of trust between you and your customers, and they’ll be happy to use it more often and even refer it to peers. Plus, you’ll have far fewer customer support issues to deal with, leading to savings on costs and manpower.
Let’s take a look at how we can test our web apps to ensure that we’re on track for a successful opening day.

What should you test?

Whether your app helps users edit photos, send invoices, connect with friends or track social influence, you’ll generally need to look at four broad areas while testing your app:

Functionality testing

Users expect apps to function accurately, quickly and consistently. That means you have to kick the tires on everything that helps a user achieve a result of some sort. Some common functional elements that require thorough testing include:

Forms: everything from feedback surveys to creating new to-dos, to subscribing to a newsletter. Check that submissions work correctly and are properly connected to your database, and that all fields accept input as necessary.

File manipulation and calculations: image and document uploads, editing and computation functionality and correct output. Ensure that you try as many scenarios as you can think of in which users might try your app, and accommodate them as far as possible. Also, look at how efficient your app is at computing and displaying results, to allow for a smooth user experience.

Search: if your app allows users to search through content, files or documentation, ensure that your search engine comprehensively indexes this information, updates itself regularly and is quick to look up and display relevant results.

Media components: test for smooth and seamless audio and video playback, animations and interactive media (like games and graphics tools). These components should function as expected and not break or slow down the rest of the app while loading or running.

Scripts and libraries: ensure that your scripts (say, for image display or Ajax page loads) are compatible with all the various browsers your audience may use to access your app, and measure their load times to help optimize performance. If your scripts are only compatible with certain browsers, make sure they degrade gracefully on others so that all users get the best possible experience of your app.
Other elements you should check for complete functionality in, include notification systems, user profiles, and administration dashboards.

User interface and usability testing

Not only should your Web app run like a well-oiled machine, but it should also provide a quality front-end experience for all your users. To achieve this, you’ll need to consider all the visual and textual elements that your users encounter, and test them to ensure they are displayed correctly and efficiently. What should you keep your eye on?

Navigation: all links to and from your homepage should be prominent and pointed to the right destination pages.

Accessibility: ensure, as far as possible, that your app is easy to use even for those with disabilities or impairments of vision or motor functions. The W3C‘s Web Content Accessibility Guidelines should help you identify and approach ways to make your app more universally user-friendly.

Cross browser testing: users will likely access your site from numerous combinations of browsers and operating systems, and your app may not display the same way across all of them. Be sure to test as many of these combinations as possible to ensure that your app works as intended, for as wide a user base as possible.

Error messages and warnings: your app is bound to break at some point, even if it’s not your fault. Make sure that your app is descriptive and helpful when users encounter an issue such as a 404 page or an unsuccessful upload.

Help and documentation: not all users will be equally comfortable using your app; some may need assistance the first few times, while others might experience an issue even though they’re familiar with the product. Run through your app to check that documentation and/or support channels are easily found and accessible from any module or page.

Layouts: test your app to make sure it displays correctly and consistently in as many browsers and viewport sizes as possible.
You’ll also want to go over all animations, interactions (such as drag-and-drop features and modal windows), fonts and glyphs (especially web fonts) and of course, front-end performance (page render speeds, and image and script load times) while you’re at it.

Security testing

Most Web apps capture and store data from users, including their personal details, billing information and work/personal files — and these users trust you to keep that data secure. Your app should:

1. Keep private data private
2. Insist on authentication before granting access to data, and limit/allow access data as necessary
3. Ensure that data integrity isn’t compromised.

Hackers can target your app at any time and from anywhere, so it’s a good idea to familiarize yourself with their methods and the kinds of vulnerabilities they look for. The most common attacks launched on web sites and apps include:

Cross-site scripting: when a website is tricked into accepting malicious code, which it spreads to visitors)

SQL injection: when a hacker, through a user input vulnerability, runs an SQL command on the app’s database, leading to damage or theft of user data. These generally occur due to the improper neutralization of special elements used in SQL commands or OS commands.

DDoS (Distributed Denial of Service) attacks: when an app is rendered unavailable to users, usually by flooding the target server with requests so that it slows to a crawl or becomes unresponsive.
Be sure to test for common programming errors that could expose your app to such attacks. Some examples of these errors include missing authentication checks, using hard-coded credentials which hackers can find in source code, leaving sensitive data unencrypted and not locking down web server directory access.
You can test for the above and more, with the help of white-hat security experts or any of a number of web tools designed for automated security probes and tests.

Load testing

Users will expect your app to run as fast as the day they first tried it, whether you’ve got 10 customers or 10,000. Plus, you might experience spikes in traffic at certain times of the day, month or year, or when your promo went viral or you were featured in a prominent publication.
Test your app and its server environment to ensure that your product works well regardless of how many users are logged in (within reason, of course). Most quality Web hosts offer solutions that can scale up to handle additional traffic in real-time, so be sure to look into that when shopping around for a host.

Tips for Improving Leak Detection

The following guidelines can help you find memory leaks quickly in your program. Most of these guidelines are intended to be used with the leaks tool but some are also applicable for use with MallocDebug and general use.

● Run leaks during unit testing. Because unit testing exercises all code paths in a repeatable manner, you are more likely to find leaks than you would be if you were testing your code in a production environment.

● Use the -exclude option of leaks to filter out leaks in functions with known memory leaks. This option helps reduce the amount of extraneous information reported by leaks.

● If leaks reports a leak intermittently, set up a loop around the target code path and run the code hundreds or thousands of times. This increases the likelihood of the leak reappearing more regularly.

● Run your program against libgmalloc.dylib in gdb. This library is an aggressive debugging malloc
library that can help track down insidious bugs in your code. For more information, see the libgmalloc man page.

● For Cocoa and iPhone applications, if you fix a leak and your program starts crashing, your code is probably trying to use an already-freed object or memory buffer. Set the NSZombieEnabled environment variable to YES to find messages to already freed objects.

Most unit testing code executes the desired code paths and exits. Although this is perfectly normal for unit testing, it creates a problem for the leaks tool, which needs time to analyze the process memory space. To fix this problem, you should make sure your unit-testing code does not exit immediately upon completing its tests. You can do this by putting the process to sleep indefinitely instead of exiting normally.

Finding Memory Leaks for iOS Platforms

Memory leaks are blocks of allocated memory that the program no longer references. Leaks waste space by filling up pages of memory with inaccessible data and waste time due to extra paging activity. Leaked memory eventually forces the system to allocate additional virtual memory pages for the application, the allocation of which could have been avoided by reclaiming the leaked memory.

For apps that use malloc, memory leaks are bugs and should always be fixed. For apps that use only Objective-C objects, the compiler’s ARC feature deallocates objects for you and generally avoids the problem of memory leaks. However, apps that mix the use of Objective-C objects and C-based structures must manage the ownership of objects more directly to ensure that the objects are not leaked.

The malloc library can only reclaim the memory you tell it to reclaim. If you call malloc or any routine that allocates memory, you must balance that call with a corresponding free. A typical memory leak occurs when you forget to deallocate memory for a pointer embedded in a data structure. If you allocate memory for embedded pointers in your code, make sure you release the memory for that pointer prior to deallocating the data structure itself.

Another typical memory leak example occurs when you allocate memory, assign it to a pointer, and then assign a different value to the pointer without freeing the first block of memory. In this example, overwriting the address in the pointer erases the reference to the original block of memory, making it impossible to release.

Finding Leaks Using Instruments

The Instruments application can be used to find leaks in both OS X and iPhone applications. To find leaks, create a new document template in Instruments and add the Leaks instrument to it. The Leaks instrument provides leak-detection capabilities identical to those in the leaks command-line tool. The Leaks instrument records all allocation events that occur in your application and then periodically searches the application’s writable memory, registers, and stack for references to any active memory blocks. If it does not find a reference to a block in one of these places, it deems the block a “leak” and displays the relevant information in the Detail pane.
In the Detail pane, you can view leaked memory blocks using Table and Outline modes. In Table mode,
Instruments displays the complete list of leaked blocks, sorted by size. Selecting an entry in the table and clicking the arrow button next to the memory address shows the allocation history for the memory block at that address. Selecting an entry from this allocation history then shows the stack trace for that event in the Extended Detail pane of the document window. In Outline mode, the Leaks instrument displays leaks organized by call tree, which you can use to get information about the leaks in a particular branch of your code.

Allocating Large Memory Blocks using Malloc for Mobile apps

Allocating Large Memory Blocks using Malloc
For large memory allocations, where large is anything more than a few virtual memory pages, malloc
automatically uses the vm_allocate routine to obtain the requested memory. The vm_allocate routine
assigns an address range to the new block in the logical address space of the current process, but it does not assign any physical memory to those pages right away. Instead, the kernel does the following:
1. It maps a range of memory in the virtual address space of this process by creating a map entry; the map entry is a simple structure that defines the starting and ending addresses of the region.
2. The range of memory is backed by the default pager.
3. The kernel creates and initializes a VM object, associating it with the map entry.
At this point there are no pages resident in physical memory and no pages in the backing store. Everything is mapped virtually within the system. When your code accesses part of the memory block, by reading or writing to a specific address in it, a fault occurs because that address has not been mapped to physical memory. In OS X, the kernel also recognizes that the VM object has no backing store for the page on which this address occurs.
The kernel then performs the following steps for each page fault:
1. It acquires a page from the free list and fills it with zeroes.
2. It inserts a reference to this page in the VM object’s list of resident pages.
3. It maps the virtual page to the physical page by filling in a data structure called the pmap. The pmap contains the page table used by the processor (or by a separate memory management unit) to map a given virtual address to the actual hardware address.
The granularity of large memory blocks is equal to the size of a virtual memory page, or 4096 bytes. In other words, any large memory allocations that are not a multiple of 4096 are rounded up to this multiple automatically. Thus, if you are allocating large memory buffers, you should make your buffer a multiple of this size to avoid wasting memory.
Note: Large memory allocations are guaranteed to be page-aligned.
For large allocations, you may also find that it makes sense to allocate virtual memory directly using
vm_allocate, rather than using malloc. The example in Listing 2 shows how to use the vm_allocate
function.



Listing 2 Allocating memory with vm_allocate
void* AllocateVirtualMemory(size_t size)
{
char* data;
kern_return_t err;
// In debug builds, check that we have
// correct VM page alignment
check(size != 0);
check((size % 4096) == 0);
// Allocate directly from VM
err = vm_allocate( (vm_map_t) mach_task_self(),
(vm_address_t*) &data,
size,
VM_FLAGS_ANYWHERE);
// Check errors
check(err == KERN_SUCCESS);
if(err != KERN_SUCCESS)
{
data = NULL;
}
return data;
}

Allocating Memory in Batches
If your code allocates multiple, identically-sized memory blocks, you can use the malloc_zone_batch_malloc function to allocate those blocks all at once. This function offers better performance than a series of calls to malloc to allocate the same memory. Performance is best when the individual block size is relatively small—less than 4K in size. The function does its best to allocate all of the requested memory but may return less than was requested. When using this function, check the return values carefully to see how many blocks were actually allocated.

Batch allocation of memory blocks is supported in OS X version 10.3 and later and in iOS. For information, see the /usr/include/malloc/malloc.h header file.
Allocating Shared Memory Shared memory is memory that can be written to or read from by two or more processes. Shared memory can be inherited from a parent process, created by a shared memory server, or explicitly created by an application for export to other applications. Uses for shared memory include the following:
● Sharing large resources such as icons or sounds
● Fast communication between one or more processes
Shared memory is fragile and is generally not recommended when other, more reliable alternatives are available.
If one program corrupts a section of shared memory, any programs that also use that memory share the corrupted data. The functions used to create and manage shared memory regions are in the
/usr/include/sys/shm.h header file.

Using Malloc Memory Zones

All memory blocks are allocated within a malloc zone (also referred to as a malloc heap). A zone is a variable-size range of virtual memory from which the memory system can allocate blocks. A zone has its own free list and pool of memory pages, and memory allocated within the zone remains on that set of pages. Zones are useful in situations where you need to create blocks of memory with similar access patterns or lifetimes. You can allocate many objects or blocks of memory in a zone and then destroy the zone to free them all, rather than releasing each block individually. In theory, using a zone in this way can minimize wasted space and reduce paging activity. In reality, the overhead of zones often eliminates the performance advantages associated with the zone.
Note: The term zone is synonymous with the terms heap, pool, and arena in terms of memory
allocation using the malloc routines.
By default, allocations made using the malloc function occur within the default malloc zone, which is created when malloc is first called by your application. Although it is generally not recommended, you can create additional zones if measurements show there to be potential performance gains in your code. For example, if the effect of releasing a large number of temporary (and isolated) objects is slowing down your application, you could allocate them in a zone instead and simply deallocate the zone.




If you are create objects (or allocate memory blocks) in a custom malloc zone, you can simply free the entire zone when you are done with it, instead of releasing the zone-allocated objects or memory blocks individually.
When doing so, be sure your application data structures do not hold references to the memory in the custom zone. Attempting to access memory in a deallocated zone will cause a memory fault and crash your application.

Warning: You should never deallocate the default zone for your application.

At the malloc library level, support for zones is defined in /usr/include/malloc/malloc.h. Use the
malloc_create_zone function to create a custom malloc zone or the malloc_default_zone function to
get the default zone for your application. To allocate memory in a particular zone, use the malloc_zone_malloc , malloc_zone_calloc , malloc_zone_valloc , or malloc_zone_realloc functions. To release the memory in a custom zone, call malloc_destroy_zone.

Memory Allocation Techniques for Mobile application

memory is such a fundamental resource, OS X and iOS both provide several ways to allocate it. Which allocation techniques you use will depend mostly on your needs, but in the end all memory allocations eventually use the malloc library to create the memory. Even Cocoa objects are allocated using the malloc library eventually.
The use of this single library makes it possible for the performance tools to report on all of the memory allocations in your application.
If you are writing a Cocoa application, you might allocate memory only in the form of objects using the alloc method of NSObject. Even so, there may be times when you need to go beyond the basic object-related memory blocks and use other memory allocation techniques. For example, you might allocate memory directly using malloc in order to pass it to a low-level function call.
The following sections provide information about the malloc library and virtual memory system and how they perform allocations. The purpose of these sections is to help you identify the costs associated with each type of specialized allocation. You should use this information to optimize memory allocations in your code.

Tips for Improving Memory-Related Performance for Mobile Apps

As you design your code, you should always be aware of how you are using memory. Because memory is an important resource, you want to be sure to use it efficiently and not be wasteful. Besides allocating the right amount of memory for a given operation, the following sections describe other ways to improve the efficiency of your program’s memory usage.

Tips for Allocating Memory for Mobile Apps

Memory is an important resource for your application so it’s important to think about how your application will use memory and what might be the most efficient allocation approaches. Most applications do not need to do anything special; they can simply allocate objects or memory blocks as needed and not see any performance degradation. For applications that use large amount of memory, however, carefully planning out your memory allocation strategy could make a big difference.

The following sections describe the basic options for allocating memory along with tips for doing so efficiently. To determine if your application has memory performance problems in the first place, you need to use the Xcode tools to look at your application’s allocation patterns while it is running.

Test Complete Tool now available for Mobile Support!

•  Test Complete Now Available for Mobile Support.  
• Test Complete now supports automated testing for your applications on mobile devices.
• Support for automated testing of native applications for mobile devices. Android is available now, iOS is expected to be released in February.
• Enhanced capabilities for Microsoft users, including support for Windows 8.1 and Windows Store (formerly Modern UI) apps and integration into Microsoft Visual Studio 2013 and Team Foundation Server 2013.
• Ability to automate testing of applications created with Embarcadero RAD Studio XE5. 
• Learn more on the SmartBear website. SmartBear website. 
• 
  
  
  Ready to try it out? Start a 30-day trial of TestComplete 10 to experience the new capabilities for yourself.