Client Pay Portal
 spider code bugs

What App Developers Never Tell You About Software Testing

You might be surprised!
All successful software projects are written with the same four basic steps since the beginning of software development: 
 
  1. Idea Conceptualization
  2. Requirements Gathering
  3. Code Writing
  4. Project Testing

No matter how the project team organizes, the language/framework selected or the project management technique used; these four basic steps are always the foundation of successful projects.
          
One of the pre-engagement requirements questions our design/development teams always ask prospective clients is, “what browsers do you want to support?” A frequent answer that we receive is, “all of them.” While this response is straightforward and seemingly obvious, it typically marks the beginning of a (sometimes) difficult conversation concerning TESTING!
 

Understanding the Basics of Code

There are typically three main layers of code in a software project:
 
  1. A database layer – where the information is captured and saved.
  2. A server-side code layer – which manages interactions with files, services, and data. (This server layer is dependent on the software language used and varies widely from one project to another.)
  3. The application's user interface – which is arguably the most important aspect of any successful project.


Why Quality Testing Matters

Quality testing involves thoroughly assessing all three layers of an application to make sure each is working correctly and achieves the level of performance that meets the project's business goal. Software Testers put applications through their paces to assess their functions/features, performance and the ease of use (among other things). Unfortunately due to the wide variety of frameworks, languages, variety of applications, and ever changing software development trends there is no one unified testing platform/tool for each of these pieces. Different types of software applications have uniquely different testing capabilities and tooling required.
 

Applications Testing

Typically only have to target the latest version of the devices operating system or at least one particular version. However, the weakness of installed applications is if you need that application to run on multiple devices; you must rewrite the project. In this rewrite, you must specifically target the capabilities and nuances of each of those device’s unique operating systems. Testing of these projects typically involves using automated tools that put all of the application’s functionality through its paces to make sure it works as expected. Usually, very little concern is placed on how the application looks or where the images display.
 

Web Applications Testing 

The power of web applications is that you can develop an application on one platform and deploy it to many others without additional rework. However, web projects have their own unique set of challenges. Let’s look at some:
 

User Interface Testing 

The user interface of a web application runs within web browsers developed by several different companies, and no two browsers share the same capabilities or agree on how things should work. Web applications are comprised of HTML scripts, JavaScript, Cascading Style Sheets (CSS), images, and data components, among other things. Each browser has unique ways of processing and displaying these elements. Of course, this is the power of the free market, but with great power comes great testing difficulty!
 

Browser Testing

There are five main browsers used today; Chrome, Internet Explorer, Firefox, Safari, and Opera. Each of these browsers has continually released new versions and capabilities and features since their introductions. Therefore, testing challenges exist even within a single web browser family. 

To adequately test a web application, you must load/test each page on the site using that particular browser. Unfortunately, since changes can exist between versions of the same browser, you must test with the specific version of that browser as well. Typically testing the page requires observing it for any layout issues, checking the functionality of the page, confirming proper performance, and validation of the data.  For example, if a web application contained 30 pages and fully testing each page took 15 minutes to perform, a full manual test would take nearly 8 hours to complete. Now consider that there are currently 93 different combinations of browsers and major release versions of them. It would require nearly 700 hours of testing to determine whether the site could run on all browsers and their versions available on just one operating system.
 

Browser Chrome Internet Explorer Firefox Opera Total
# of Major Browser Versions 41 11 33 8 93


Obviously supporting every browser ever made is unreasonable and unrealistic – because of the ROI expectations on most projects. Since there is no “official best practices guide”, what browsers should be supported for a web project today? The answer usually comes down to features, budget, and targeted market. Minimally today’s web applications should support HTML5, CSS3, and JavaScript frameworks, such as Bootstrap.

When in doubt a reasonable starting point is the trusty ole’ Pareto Principle and a plan to support the top 80% of all browsers/versions currently in use. Depending on your source of browser statistics, the list today minimally would include:

  • Chrome v.36 & newer
  • IE v.9 & newer (note: version 8 is disowned by Microsoft)
  • Firefox 35 &  newer
  • Safari 8 & newer
  • Android 4 & newer

All of these would include Desktop and Mobile device usage.

As you can see working with web technologies can increase the opportunity for your application to be quickly deployed across a variety of devices and operating systems. However, it also comes with a whole new set of complexities and considerations.

 

The Cost of Testing

No matter the application development approach every project will have a different baseline for testing efforts. The business risk and complexity of the application will determine the testing approach required. A good starting point is to factor in approximately 20% of the overall project budget for testing. You may be able to increase or decrease the level of the testing effort required based on the risks associated with the project.

Testing always has and will always continue to be a fundamental building block of software development projects. Testing is not unnecessary overhead cost that can be reduced by using the latest fad in software development techniques or tools. The truth is you want (you need) your application development team to test your application thoroughly. Testing should be a critical selection criteria when choosing your team.  If the users feel that the application is not ready, they will quickly lose their trust in the application as they start to experience problems, and that loss of confidence will ultimately cause the project to fail. If your users don’t use the application, your project has failed. 

See, I bet your app development company never told you all this about testing software…  

Author

Wiz E. Wig, Mascot & Director of Magic
Wiz E. Wig

Director of Magic