The Gaming Touch

I like to game. I used to love Nintendo, up until Apple decided that they were going to destroy Nintendo, if Nintendo refused to create games for iOS. Apple’s got the platform war won, not only on on mobile phones and tablets, but soon… on gaming consoles too, mobile or not. I predict that Apple will replace the gaming console. I’m not talking about Angry Birds on your TV. I’m talking about real gaming. I’m defining the console experience as having the power, performance, and graphics capabilities of a gamer’s hardcore PC, all on your iPad.

With the introduction of the iPad Air, Apple announced their A7 64-bit architecture processor, a powerful CPU that has the performance required to play console-like games. With the introduction of iOS 7, Apple also introduced an SDK that allows third party hardware manufactures to create gaming controllers for iOS.

Now, Imagine this. You have an iPad and you own an Apple TV that is plugged into your Flatscreen TV. You want to play a game on your TV so you Air-play your iPad to your TV, set your iPad down, and connect your wireless bluetooth controller to your iPad. Instant game console.

What needs to be addressed before Apple finds success in the game console industry? First, lag. Airplay has a few mili-second lag. Second, controllers. This one isn’t a big issue as third-party manufactors will create multiple types of controllers for iOS, they just aren’t available now. Third, games. As iOS becomes even more relevant and mature, game developers will see the monitary advantages of creating iOS games. There are games like Oceanhorn which provide a Zelda-Nintendo-like experience or Republique which offers a unique touch-&-stealth experience.

Black Box Testing

Study: Black-Box Testing

There are many different methods of software testing and it is important for developers to know both the advantages and disadvantages of choosing one over the other. A few of the most common methods of software testing are black box testing, white box testing, and grey box testing. Each of these options can be beneficial and provide great feedback for the developer but choosing the method of choice will greatly depend on the application being tested and the personal preference of the developer.

White box testing, also called glass testing or open box testing, differs greatly from black box testing because the tester will focus on the code of the application (“Black Box vs. White Box” 2008). When using the white box testing method the tester will need to have extensive knowledge of how the code in the application is working. This can dramatically increase the overall cost of the testing process (“Software Testing Methods” 2013). On the other hand, having a tester that is code savvy can help with code optimization and can lead to problems in the overall user experience being solved in a more time efficient manner (“Black Box vs. White Box” 2008).

Another form of testing is Grey box testing, which as the name implies, is a mix of black and white box testing methods. Grey box testing requires the tester to have access to the design documents and the database the application is using. This makes preparing the test data and scenarios much easier. The tester will still be focusing on the user interface and not the code as in black box testing, but the tester will have a better understanding of what exactly the application is doing behind the scenes than a black box tester would (“Software Testing Methods” 2013).

Black-box software testing is a technique that tests apps to see how the apps function to a non-technical user. The tester’s goal is to accomplish tasks set out by a testing plan. The tester knows what he has to accomplish, yet is not aware of how the code functions. The type of user and the type of app must be taken into consideration in order to gain the most useful information from the black box test. For example, a technical app would be easier to use for someone that knows a lot about technology and understands programming. Where as a non-technical user would feel overwhelmed and frustrated by the app. This is an oversimplification of software testing theory, the metrics required for a successful test have to be documented in a software test plan.

According to Laurie Williams in collaboration with, “Black box testing (also called functional testing) is testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.” (Williams, 2006) In black-box testing the tester does NOT have access to the code. Relying only on the external output generated by their direct actions that are inserted into the application. The software test plan should define what outputs are expected when executing certain actions.

Black-box testing focuses on the functionality of the user interface, it also focuses on the users and how they interact with the application. Testers should be seen as internal users that give valuable feedback for your application. Although, most black box testers don’t require technical skills. Some black-box testers have scripting skills in order to automate testing. In order to understand how the testing is accomplished, let’s take a look as some of the roles and responsibilities the tester has. The tester needs to know that every input returns an appropriate output. Aside from looking for functional defects the black-box tester should also look for usability issues. When testing it is important to identify known usability issues found either through testing or through user bug-reporting systems. It is critical to understand what quality is from the user’s perspective and to make sure the tester works with the development team to meet these goals.

The IEEE definition of test case is “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” (Gumaste) Writing a test case procedure to black box test an app primarily focuses on functionality without looking at the source code. The main focus is to look at the application and interact with the UI as a user would. In order to write a test case you have to have an abundant knowledge of the software you are writing it for. The test is essentially set up to have non-programmers ‘evaluate’ the app in normal use cases. The tester only has to be aware of how the app should function and verify that it is working properly, and does not need to have any knowledge of the source code.

As Robert Japenga alludes to in his paper on How to Write a Great Software Test Plan, you will NEVER be able to test enough (Japenga). There is never a way to test every single aspect of a piece of software. He goes on to say that if this fact makes you a little uneasy, than you are starting in the direction of a great test plan. To write a good test procedure you first have to know why you are writing it. The whole purpose is to find errors. If you know anything about the code aspect of developing software you know how complex even the most simple program can be, so you have to be prepared from the start of development to implementing testing procedures along the design path. With this in mind you should prepare a plan as soon as the software is defined. Then you should be focusing on the software specifications. The software specifications state what the core functionality of the app will be, and this is what you want to check for failures. These are the most import aspects of the app from a user’s standpoint. When writing test procedures it is important to have a timeline as to when the app is to progress through the process of development and launch. You then have to identify who will verify all the information that is to be tested, and be sure to have all the hardware needed for testing (Japenga).

According to Robert Japenga there are 5 items that need to be addressed to create a successful test plan. The first is “Definition and Objectives of the Phases of Testing” which focuses on module testing, integration testing, systems/acceptance testing, and best testing. The second is “Schedules” this part defines the phases of the testing plan by answering the questions similar to, what are the dependencies of each phase, and how long will each phase last? The third item that needs to be defined is “responsibilities,” responsibilities addresses who will be creating and executing test cases as well as who will be fixing them. The next item is “Target Equipment Required” this item identifies what equipment will be required for testing. An example would be a physical development server, or a pre-production server. Finally, the fifth area, “Test Equipment Required,” identifies EVERY test equipment required to make the test plan succeed, including what equipment needs to be purchased or rented (Japenga).

Japenga goes on to explain that there is a second part to creating an efficient test plan and that the goal is to define exactly what should be tested. You start off with a Software Requirements Specification document and create test cases from it. Next we create testing scenarios outside the SRS document that encompass the system as a whole. Finally, you use off-design test scenarios that are also outside and not defined in the SRS document. This allows us to see how the software works and makes certain the application is not executing faulty processes (Japenga).

According to Jeff Sandberg, developer of TrustedAd, In order to create a Black-Box Developed application, there are four stages that should be followed. The first stage is to write the documentation first, which allows the application to be defined before you start to program. The second step is to write the actual code, while using the documentation that was created in stage one. After you have an idea of the functionality you want to create and have the code, the next step is to write your tests and test the application. The code along with the documentation should match the tests. The final step is to refactor your documentation AND code and follow through the cycle as many times as necessary to reduces errors and bugs with the application (Sandberg, 2012).

Developers will deduce that Black-box testing is created to minimize the amount of bugs in the user interface, while White-Box testing is used to reduce the amount of errors in programming logic. The combination of the two, Grey-Box testing, allows the tester to tackle both types of testing procedures and test the overall efficiency of the code, yet, Grey-Box testings also allows the tester to test the user experience of the human-machine interface.

Photo by thierry ehrmann.

Eric Garcia
Robert Smith

Read More:
Black-box vs. white-box testing: choosing the right approach to deliver quality applications.
(2008). Retrieved from

Gumaste, V. (n.d.). Test case writing (creation) 101. Retrieved from

Japenga, R. (n.d.). How to write a great software test plan. Retrieved from

Sandberg, J. (2012, November). [Web log message]. Retrieved from

Software testing methods. (2013). Retrieved from

Williams, L. (2006). Testing overview and black-box testing techniques. Retrieved from

iOS Mobile Gaming

Mobile Gaming Industry

Mobile gaming has fascinated the main-stream public since the dawning of the original Gameboy by Nintendo. Since then, mobile gaming systems have become intensively faster, portable, connected, and feature rich. Then came the iPhone, a mobile system that introduced and gave mass-market appeal to a new type of interface, touch. That wasn’t all, it was internet connected too, and efficiently introduced the idea of a centralized app store. Developers soon realized the potential of a mobile computing system and practically overnight the app store become the number one distribution channel for mobile games and other apps.

In the article Mobile Gaming by Jason O.B. and Bernard C. Y. Tan, they wrote the following: “mobile games could generate $1.5 billion annually in revenue by 2009.” Sadly, their prediction would not see the light, as PCMAG found that in 2009 mobile gaming revenue was $540 million. Don’t let that simple statistic cloud your judgement, last year, in 2012, mobile gaming revenue exploded, industry revenue increased from $2 million in 2007 to $4.5 billion in 2012 (INC, McDermott, 2012). Yes, thats a B, as in billion. I say Jason and Bernard were on to something very empowering. I think that the article isn’t as relevant now that time has passed, but their foundation for the importance of mobile gaming is strongly structured.

Mobile gaming development has grown exponentially with the App Store and similar markets, thanks to the great mobile devices we now have available mobile gaming programmers now have a great opportunity to create amazing games and as a bonus gain monetarily. I have a gut feeling that this industry is still in its infancy. There are things that might plague mobile gaming, like the introduction of “in-app” purchases. Which are micro-transaction that enable gamers to purchase digital goods like items, characters, maps, etc. In-app purchases are seen as the devil’s work to gamers. Either way, as I type this, I am downloading the mobile game, Order and Chaos, which is a massive multiplayer role playing game (MMORPG) for iOS and I can’t wait to play.

Photo by Explosivo Films.

Soh, J. B., & Tan, B. Y. (2008). MOBILE GAMING. Communications Of The ACM, 51(3), 35-39.


Twitter Bootstrap with Ruby on Rails

In this short tutorial we will learn how to install Twitter Bootstrap into a new Ruby on Rails app. We will then create simple pages to test our Bootstrap installation.

Include the following line into you Gemfile in your ruby on rails app.

gem 'bootstrap-sass'

Next, run the “bundle install” command in terminal to install Twitter Bootstrap dependencies.
bundle install
Create the file custom.css.scss in your app/assets/stylesheets directory.
In the app/assets/stylesheets/custom.css.scss file you created add the following:

@import "bootstrap";

Now we need to generate a controller so we can setup our dynamic pages. Run this in terminal:rails generate controller Pages home about downloads contactNotice the folder named pages that is created in your /app/views/ this folder contains four files that were created. home.html.erb, about.html.erb, downloads.html.erb, and contact.html.erb which are the parameters(pages) we added at the end when we generated the controller. It is important to know what happens when generating a controller in Ruby on Rails. Aside from creating the views and pages, the generator also creates routes for your pages in config/routes.rb it adds the following lines to your config/routes.rb file:

get "pages/home"
get "pages/about"
get "pages/downloads"
get "pages/contact"

The generator also creates the file pages_controller.rb which is located in app/controllers/ in this controller file a class named PagesController and four method actions called home, about, downloads, and contact are defined.

Now in order to view our site we need to get rid of the default index.html file in your /public/ folder. Delete it using the following command inside the public directory: rm index.html

Next we implement the HTML and CSS code required to make a bootstrap page. In order to keep our pages simple and organized we are going to structure it using partials. First we create a layout partial for the header of our site. In app/views/layouts create a file named _header.html.erb and add this code to it:

<div class="masthead">
  <h3 class="muted">Sky Tutorials</h3>
  <div class="navbar">
    <div class="navbar-inner">
      <div class="container">
        <ul class="nav">
          <li class="active"><%= link_to "Home", root_path %></li>
          <li><%= link_to "About", about_path %></li>
          <li><%= link_to "Downloads", downloads_path %></li>
          <li><%= link_to "Contact", contact_path %></li>

Notice the link_to ruby commands and the code root_path, about_path, downloads_path, contact_path. We will need to define these paths later on.

Now, open your app/views/layouts/application.html.erb file so we can add the newly created _header.html.erb partial code. We are adding this ruby helper code to application.html.erb:

<%= render 'layouts/header' %>

We are also adding a container div to wrap our website and make it a little more structured. Your entire application.html.erb should look like this:

<!DOCTYPE html>
  <%= stylesheet_link_tag    "application", :media => "all" %>
  <%= javascript_include_tag "application" %>
  <%= csrf_meta_tags %>
  <div class="container">
<%= render 'layouts/header' %>
<%= yield %>

Finally in order for our links to work we need to re-route our views. Open your config/routes.rb and change these 4 lines of code:

get "pages/home"
get "pages/about"
get "pages/downloads"
get "pages/contact"

to this:

  root to: 'pages#home'
  match '/about', to: 'pages#about'
  match '/downloads', to: 'pages#downloads'
  match '/contact', to: 'pages#contact'

CONGRATULATIONS! We are now finished creating the structure of a basic website using Twitter Bootstrap and Ruby on Rails. Start you Ruby on Rails app using the rails command:rails server then navigate to your ruby on rails app by going to http://localhost:3000/ you should get a page that looks like this:

Twitter Bootstrap Ruby on Rails Homepage

Twitter Bootstrap Ruby on Rails Homepage

All of the links should take you to different pages(although they are not too different.) It might not look like much now but these are the fundamentals of the Ruby on Rails framework. You can now go into your /app/views/pages/ directory and edit any of the 4 files we generated(home, about, downloads, contact). Once you edit these files you can see the changes on your website.