VanQ – Vancouver’s Local Software Quality Assurance Community Reaches 700+ Members and Counting

VanQ Software Quality Assurance group was formed over 10 years ago with a small community of local software developers and testers. This month we are celebrating a milestone as VanQ has now hit over 700 members.

Ed Dahl co-founded VanQ with the mission to build a strong local Software Quality Assurance community. Over the years the organizers have changed, but the mission has remained intact. Optimus Information took on carrying through this mission over two years ago and it has been a great way to connect with local and new software developers and testers. Our monthly Meetups bring out anywhere between 50 – 80 members with equal parts new and familiar faces. VanQ has proven to be a great way for new QA professionals to connect with seasoned professionals and become involved in this thriving community.

Over the years we have seen a number of great leaders, from a range of backgrounds and industries, share their ideas and experiences. We have also had a variety of sponsors join us in bringing the community together such as Hootsuite, Boeing – Aeroinfo Canada, Vision Critical, SOASTA and Mobify to name a few.

We have been able to capture a number of the Meetup presentations on video. Here are a few of our most recent Meetups. You can find the full archive at

Overview of the International Software Testing Qualifications Board (ISTQB)

For this Meetup, Gary Mogyorodi from the Canadian Software Testing Board in Toronto came out to speak with our members about the ISTQB, benefits of the ISTQB, Syllabi and Extension, the ISTQB footprint, the Canadian Software Testing Board, and the ISTQB Partner Program. Watch the complete presentation here:

Essential Skills for Test Automation & Load Testing

This past May, Alex Siminiuc, Freelance Tester with, shared with us his thoughts on the skills needed for test automation and load testing. Alex has been a Software Tester since 2006 and actively blog’s here: Watch his complete presentation here:

Vision Critical’s QA Strategy: Prevention Rather Than Cure

Stuart Ashman, Vision Critical’s QA Director gave VanQ a presentation on how they attempt to ensure they ‘build it right’ as well as ‘build the right thing’. He goes through their process of using white box approaches, automation, risk analysis and strong critical and test thinking. Watch the full presentation here:

After taking the month of July off to enjoy some of the summer weather, we are gearing up for the next Meetup on Thursday, August 13, 2015. For this one we are excited to partner with Electronic Arts Games, TestDroid and the Vancouver Unity Games Meetup group for an exciting talk on ‘Driving Quality Through Test Automation of Mobile Apps and Games’. We will be hosting this Meetup at The Pint Public house. Join VanQ today and we hope to see you at the next Meetup:

We are always looking for topic suggestions, speakers, sponsors and venue hosts. If you would like to get involved with VanQ get in touch with us.

Are You Overlooking These Areas When Testing Your Mobile App?

Some people think testing mobile apps is easier than testing web applications or desktop applications because most mobile apps tend to be less complex. However, just because something is less complex doesn’t mean we testers can relax and assume that it is bug-free. Here are some common areas for bugs to hide that mobile app testers usually overlook.

Have you missed any of the following?

1. Keyboard buttons, such as “Done”, “Next”, “Search”

Sometimes, your app provides an on-screen button and a keyboard button to perform the same action, for example, “Done”, “Next”, and “Search”. Don’t just test the on-screen buttons and forget about the keyboard buttons! Some users may tend to use the on-screen buttons whereas some tend to use the keyboard buttons.

Make sure your app works with both on-screen and keyboard buttons.

2. Mobile app gestures

Every mobile OS platform has gesture and multi-touch support so that users can perform tasks more efficiently. And these features keep evolving. Sometimes, your developers associate app-specific tasks with different gestures, but sometimes, your app inherits the standard gestures without you knowing. For example, swipe to remove a row in a table.

Even if a gesture is not associated with a task, you may still want to try it out.

3. “Back” or “Cancel” button

Make sure there is a “Back” or “Cancel” button and it is enabled in any workflows.

Your users may want to visit the previous screen or exit from the current workflow.

4. Switch phone orientation during screen loading

It is common for apps to crash when you rotate the phone orientation while the app is loading. This is caused by apps that don’t handle the objects or data population properly when instantiating or destroying a view, resulting in a crash.

Make sure the app has been coded properly and isn’t subject to this all-too-common crash.

5. App update and re-installation

When you test a new release, do you have app update and re-installation tested as well? Usually we are too busy with testing the new features and regression testing so we forget or skip testing app update and re-installation.

This is especially important if your app stores data in its local database.

You may think it is unlikely to find any critical bugs in these areas, but as a tester, you should never hold an assumption and overlook any seemingly-alright parts. If you did not test any of the areas mentioned above, test them and you may find some surprising bugs.

If you have anything to add to the list, feel free to leave a comment and share with us.

The post Are You Overlooking These Areas When Testing Your Mobile App? appeared first on OptimusQA.

Introduction to Automation with Perfecto Mobile

The team at Perfecto Mobile was nice enough to provide me a few hours to test out their automation and do a follow up to my Introduction to Perfecto Mobile post.

So lets start exploring their automation  capabilities.

Perfecto Mobile provides some predefined, high-level commands for automating test scripts on both native and web-based mobile applications.

Users can also create their own commands or use Perfecto Mobile’s record and play features for creating scripts.

I tried many of the predefined commands like installation, uninstallation, browser go to, button click and other commands related to text login functionality. I really found Perfecto Mobile automation to be easy and efficient in terms of script creation.

Just to play with the predefined commands, I automated a simple visit Google scenario.

  1. Select any device to test the application from the Device Dashboard. I selected iPhone 4S from the devices list.
  2. Select ‘Home’ predefined command.
  3. Select ‘Browser go to’ command and enter the application URL in the URL field. In this case,
  4. Then run the test and watch the browser open Google’s home page.

The installation/uninstallation type of command is for installing native apps on the devices. It took three to three and a half minutes to install the apps that I tested on the real devices.

You can test your application both on emulators or real devices. They provided both devices for testing.

Perfecto Mobile also provides advanced features like record and play, checkpoints, loops and data tables for full control. I tried these features out on an HTC X1 and a Samsung SII.

Finally, I tested my web application on iPhone 4S and native application on Android HTC X1 before running the scripts on different devices. They provide their automated test results in the same format as manual testing.

Due to time limitations, I was not able to go deeper in to the automation but I got a good look at their basic automation commands and workflows. I look forward to going deeper and  getting more detailed knowledge of Perfecto Mobile’s more advanced features in the future.

The post Introduction to Automation with Perfecto Mobile appeared first on OptimusQA.

Mobile Quality After QA is Done

The bad news about testing mobile apps is that it is complex. The worse news is that it is a moving target.

The difference between mobile and desktop markets is that the mobile market is much more fragmented with lots of new devices and new versions of operating systems coming out each day.

That means that just because you launched a stable app doesn’t mean your app will continue to be stable. Desktop software had the same problem except that operating system changes aren’t that frequent so the moving target of a stable app moves a lot more slowly.

Crash Analytics: Ongoing Mobile QA

To ensure the ongoing quality of a mobile app we leave the standard testing tools aside and move to crash analytics. Tools like Flurry, BugSense and Google Analytics let you monitor and help you diagnose app crashes.

As new devices emerge, you can monitor their stability and their popularity among your users and respond to issues as they emerge.

And if your QA efforts missed anything, then you will know right away.

The post Mobile Quality After QA is Done appeared first on OptimusQA.

Writing and Coding Calabash-Android Test Cases

Building on my calabash-android setup post, I want to explain how to start writing calabash-android test cases in the ‘feature’ files and their respective code in ‘step definition’ files.

After you install the Calabash-Android gem then a directory structure is saved at the following path:


In this folder: “C:\Ruby193\lib\ruby\gems\1.9.1\gems\calabash-android-0.4.3\lib\calabash-android\steps” you should find various .rb files which contain the pre-written code for various mobile app events such as touch, swipe, scroll down, enter text in input field number and wait for events.

Such pre-written steps help a lot in writing test cases in the plain English format of Cucumber.

Feature File and Step Definition

Here is an example of a feature file and step definition content for testing login.

Feature file content

Scenario: Login Functionality
	Given I am on the Login page
	When I enter invalid username and password
	 And I press Login button
	Then Error message should appear stating “Invalid username or password”

Step definition file content

Given (/^I am on the Splash Screen$/) do
	wait_for(180) {element_exists("button id:")}
##This row will wait for 180 seconds before loading the login page after installing the app on your mobile device or emulator.

When (/^I enter invalid username and password$/) do
	steps %{
		Then I enter "" into input field number 1
		## This row will enter text in the username field (If it is the first input or text field on the page.)

		Then I enter "" into input field number 2
		## This row will enter text in the password field (If it is the second input or text field on the page.)

		Then I wait for 5 seconds
		## This row will make the app wait for 5 seconds

And (/^I press Login button$/) do
	steps %{

		Then I press the "Log in" button
		## This row will press the button with text “Login” on it

		Then I wait for 5 seconds

Then (/^Error message should appear stating “Invalid username or password”$/) do
	steps %{
		Then I see “Invalid username and password”
		# This row will check for the text: “Invalid username and password” on the page.

Now calabash-android will read these step definitions and will work with the app according to them.

In this way calabash-android and its pre-defined libraries easily automates the mobile app testing on an emulator or real device.

Common Calabash for Android Issues

Challenge: Check for text that appears twice on the same page but with the second instance not in the viewable area.

Solution: Check that the text appears correctly in the first instance then scroll down the page and check for the second instance.

Feature file content

Then I see “abcdef”
This I scroll down
Then I see “abcdef”

Pros of using calabash-android:

  1. It is absolutely free.
  2. As it is based on the Cucumber framework the test cases are very easily created in simple language.
  3. Support for all the basic events and movements on the mobile are present in the libraries.
  4.  It has a thriving forum and Google Group: “Calabash Android”.

Cons of using calabash-android:

  1. It takes time to run on an emulator or device as it always installs the app first before starting the first scenario.
  2. If a step fails then the subsequent tests in the scenario are skipped.
  3. It is still in its nascent stage. Support for many complex scenarios or events is not supported. For that either you have to code your way in Ruby or wait for these supports to appear on the scene.
  4. We must have the code of the app for identifying the ids of various elements.

The post Writing and Coding Calabash-Android Test Cases appeared first on OptimusQA.

Selenium Android Driver Setup

The Selenium Android Driver lets you automate testing of web apps viewed through Android browsers using Selenium. It aims to provide a friendly API that’s easy to explore and understand, which will help make your tests easier to read and maintain. It’s not tied to any particular test framework, so it can be used equally well with JUnit, TestNG or from a plain old “main” method.

Android Driver allows you to run automated end-to-end tests that ensure your site works correctly when viewed from the Android browser. Android WebDriver supports all core WebDriver APIs and it supports mobile-specific and HTML5 APIs.

Android WebDriver models many user interactions such as finger taps, flicks, finger swipe and long presses.


  1. Download selenium jars and android-server.apk
  1. Download selenium jars and android-server.apk file from Google Code.

selenium-downloads Selenium Android Driver Setup

  • Create a new Project.
  1. Open Eclipse IDE and go to File -> New -> Java Project.
  2. Name the project as AndroidTest.
  3. Click Finish to create the project.

create-java-project Selenium Android Driver Setup

  • Create source folder for storing test scripts.
  1. Right click src folder under the project and select New -> Folder. Name the folder as com and click finish.
  2. Create a folder called core under the com folder.
  3. Similarly, create a folder called test under the core folder.

create-source-folder Selenium Android Driver Setup

  • Create Library folders for storing jars.
  1. Right click project folder and select New -> Folder. Name the folder as libs and click finish.
  2. Right click libs folder and select New – > Folder. Name the folder as libs and click finish.

create-library-folder Selenium Android Driver Setup

  • Copy the Selenium jar file into the project.
  1. Copy Selenium.jar and Selenium-srcs.jar in the AndroidTest -> libs folder.
  2. Copy other jars files in the folder AndroidTest -> libs -> libs folder.

copy-jar-files Selenium Android Driver Setup

  • Add the jar files to the build path.
  1. Right click the project folder and select build path -> configure build path.
  2. Click add jars.
  3. Navigate to the location of jars and select the jars.
  4. Click ok once you are done.

add-test-case Selenium Android Driver Setup

  • Adding a test case to the project.
  1. Right click the com.core.test folder and select New – > Class.
  2. Name the class as TC1.
  3. Click Finish.

add-test-case Selenium Android Driver Setup

  • Write the Test Script.
  1. Import all the selenium libraries into the project.
  2. Write the test script like in the two samples below.
  3. Remove the errors and warnings.
package com.core.test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.testng.annotations.Test;

public class TC1  {

  @Test (groups="run")	
  public void testGoogle() throws Exception {
    WebDriver driver = new AndroidDriver();
    // Open
    // Find element by its name
    WebElement element = driver.findElement("q"));
    // Enter something to search
    element.sendKeys("Optimus Information");
    // Now submit the form. WebDriver will find the form for us from the element
    // Get the title of the page
    System.out.println("Page title is: " + driver.getTitle());
    // Sleep for 10 seconds
    // Quit the driver
public class TC2  {
	  private static WebDriver driver;
	  public char result2;

	@Test (groups="run")	
	  public void testGmail() throws Exception {
	    driver = new AndroidDriver();
    	String useremail =  driver.findElement(By.cssSelector(".V.Y.XD.Ji")).getText();
    	System.out.println("User Email is " +useremail);
    	if ( useremail.equals("") )
    	  System.out.println("TestCase2 Passed");
    	Assert.assertEquals('P', result2);

  • Configure Testing XML.
  1. Create testng.xml in the folder com.core.test.
  2. Make entries into the xml as shown below.
<!DOCTYPE suite SYSTEM "" >
<suite name="Google Test Suite">

  <test name="TC1:To verify the google Home Page">
        <include name="run"/>
       <class name="com.core.test.TC1" />
  <test name="TC2:To verify that user is able to Login to Gmail">
        <include name="run1"/>
       <class name="com.core.test.TC2" />

  • Install Android Web Driver app on the Device.
  1. Copy android-server-2.21.0.apk to the phone.
  2. Install the app on the device.

install-web-driver-app Selenium Android Driver Setup

  • Connect the device and start the WebDriver application.
  1. Connect the device to your pc using USB (Debugging mode).
  2. Start the WebDriver application.

start-web-driver Selenium Android Driver Setup

  • Port Forwarding.
  1. Open the command prompt.
  2. Go to directory containing adb.exe.
  3. Enter the following command: adb forward tcp:8080 tcp:8080.

port-forwarding Selenium Android Driver Setup

  • Execute the Test.
  1. Right click testng.xml and select Run As -> TestNg Suite.

execute-test Selenium Android Driver Setup

  • Observe the Test Case running on Device.
  1. Test case is executed in the Web Driver’s in built browser.

observe-test Selenium Android Driver Setup

  • Analyze the results.
  1. Double click the test-output folder under the project.
  2. Open index.html and emailable-report.html to get the results of the tests

google-test-suite Selenium Android Driver Setup
testng-report Selenium Android Driver Setup

The post Selenium Android Driver Setup appeared first on OptimusQA.

How to Quickly Set Up Android Testing on Calabash

Calabash-android is a great little test automation tool for functional testing of Android applications that uses the simple English test script creation of Cucumber to automate your application. It lets you automate testing with little or no coding.

Here is what you need to get started with calabash-android.

Install Android, Ruby, Cucumber and Calabash

  1. Install the android-sdk to run the emulator.
  2. Install Ruby on your system.
  3. Run the command “gem install cucumber” in cmd to install Cucumber on your system. After successful extraction check its version and update if necessary.
  4. Run the command “gem install calabash-android” in cmd to install calabash-android on your system.

Configure your System

  1. Set the Android path to the following in system variables:
    ANDROID_HOME=C:\Program Files\Android\android-sdk
  2. Set the JAVA_Home path to the following in system variables:
    JAVA_HOME=C:/Program Files/Java/jdk1.7.0_17
  3. Set the ANT_HOME path to the following in system variables:
  4. Set the path to the following in system variables:

Open your cmd and Install the Mobile Application

  1. Navigate to platform-tools directory.
  2. Copy and paste your application inside this directory.
  3. Open the android-avd manager and create a new emulator.
  4. Start your emulator and wait till it completely loads.
  5. Open cmd and navigate to platform-tools. In cmd enter the following command:
    &gt;adb install your_file_name.apk
  6.  After your app is installed, verify that it is present in menu screen of your emulator.

Create a New Directory

  1. Create a new directory using the following command:
    &gt; mkdir D:\FirstProject
  2. Now generate the folder structure with feature file, step-definitions, support and lib using the following command:
    D:\FirstProject&gt; calabash-android gen
  3. Now sign your apk using its keystore path, password and alias:
    D:\FirstProject&gt; calabash-android setup

    Be sure to note the complete path to debug.keystore. When you are asked to enter the keystore location, enter the full path including the name: i.e D:\Calabash\keystore_name.

    The system will ask for debug.keystore of the application, the password and the alias to sign your apk. .calabash-settings file. The folder structure will be created upon completion.

  4. Now write following code in your feature file-> my_first:
    Feature: General functionality for InfantAudit

    Scenario: Create New Store

    Given I am on the Splash Screen

    Then I press the “Log in” button
  5. Write the following code in step definitions:
    $LOAD_PATH.unshift(File.dirname(__FILE__) + '/../../lib') unless $LOAD_PATH.include?(File.dirname(__FILE__) + '/../../lib')
    require 'calabash-android/calabash_steps'
    require 'utilities.rb'
    Given /^I am on the Splash Screen$/ do
    	wait_for(180) {element_exists("button id:'btnLogin'")}
  6. Open cmd and run your code using following command:
    D:\FirstProject&gt; calabash-android run your_file_name.apk
  7. If you will be automating the next sprint of this application then you have to re-build and re-sign application to create a new test server for each sprint using following command:
    D:\FirstProject&gt; calabash-android build your_file_name.apk
    D:\FirstProject&gt; calabash-android resign your_file_name.apk

No Test Server Error

You sometimes get the following error while running apk through calabash which you can resolve using the method described below.

No test server found for this combination of app and calabash version. Recreating test server. /Library/Ruby/Gems/1.8/gems/calabash-android-0.4.3.pre4/lib/calabash-android/helpers.rb:148:in `extract_md5_fingerprint’: No MD5 fingerprint found: (RuntimeError)

Recommended Solution

  1. Copy your “Calabash” folder having “feature” file.
  2. Paste it into your android workspace having gen, res, src folder.
  3. Navigate to new path and again run apk file.
  4. Now, Test server will create inside your calabash folder.

Alternate Solution:

  1. Re-sign your apk file using command:
    -D:\FirstProject&gt; calabash-android build your_file_name.apk
  2. Build your apk file using command:
    D:\FirstProject&gt; calabash-android resign your_file_name.apk

The post How to Quickly Set Up Android Testing on Calabash appeared first on OptimusQA.

Problems with testing on rooted or jailbroken phones

One of the biggest problems for mobile developers is testing on all of the different devices that their app can be used on.

To solve that problem, a number of mobile device lab management and device cloud solutions have sprung up letting mobile developers and testers do automated and manual testing on a large number of devices. These device clouds let users write their tests once and then deploy them to a range of devices.

The problem is that in order to implement test automation on physical devices, many of these solutions need to root and jailbreak the phones.

As a quick aside, iOS devices need to be jailbroken and Android devices need to be rooted.

Rooted or jailbroken phones aren’t good for testing for a number of reasons.

Unreliable Crash Reporting

Rooted and jailbroken phones are more prone to crashes and other performance issues which can result in bugs being reported that are really problems with the device.

This problem is even worse for testing on personal phones because rooting gives apps more access to the system and you don’t know how other apps that are fine on a normal phone are affecting the rooted phone.

Device clouds wipe the phones and reinstall a clean operating system between tests, so this is less of a problem.

Security Risks

Jailbroken and rooted phones are more prone to security risks.

Jailbreaking iPhones introduces code from anonymous hackers. Do you really want to trust that some random code is secure? It is even possible that the jailbreak is the security risk.

Jailbroken and rooted phones are more prone to malware. Jailbreaking bypasses some of the security features of iOS and rooting gives apps more access to Android. Testing on lab-based and device cloud phones will again be better off than testing on personal phones since users are less likely to install random apps and clean installs between tests also reduce the security risks.

One potentially huge problem for lab-based cloud testing solutions is that, once compromised, iOS can install an SSH server. This could let remote hackers tunnel in to your secure IT environment.

Compromised Test Environment

Finally, jailbreaking and rooting changes the behaviour of the phone thus compromising your test environment.

You can test all you want on jailbroken and rooted phones and no doubt catch a number of valid bugs. But you can’t release with the same confidence as you would on non-jailbroken phones.

If you are okay with the potential consequences, then by all means test on jailbroken phones. But know the risks. And know that there are lots of options now both for test labs and in the cloud that don’t require jailbreaking or rooting.

The post Problems with testing on rooted or jailbroken phones appeared first on OptimusQA.

Overriding User Agent in Google Chrome

Google Chrome gets updated a lot, but their October 23, 2012 update added some awesome new features that I had initially missed until I found myself needing them recently and going searching for a quick solution.

The most exciting additions are the ability to override user agent and dimensions making Chrome a great tool for development and ad-hoc QA for mobile websites.

Accessing the Overrides

  • At the top right of Chrome click on the Chrome Menu and select Tools -> Developer Tools to open the Developer Tools window or pane.
  • In the bottom right corner of the Developer Tools window or pane, click on the gear icon gear-icon Overriding User Agent in Google Chrome.
  • In the Settings menu, select Overrides.

This gives you access to all of the override options.

Overriding User Agent and Screen Resolution

One of the neat features is that if you have User Agent and Device metrics selected, the Screen resolution automatically adjusts to your user agent letting you quickly check a website against the available device emulators.

Chrome currently includes the following generic and specific emulators:

  • IE 7-9
  • Firefox 4 and 7 for Mac and PC
  • Firefox 14 for Android Mobile and Tablet
  • Chrome for Android Mobile and Tablet
  • iOS 5 for iPhone and iPad
  • iOS 4 for iPhone and iPad
  • Android 2.3 on Nexus 4
  • Android 4.0.2 on Nexus 7
  • Blackberry Playbook 2.1, 9900, BB10
  • MeeGo on Nokia N9

I don’t recommend you use these in place of proper compatibility testing on enterprise web projects, but they are great for some quick ad-hoc testing when you make small changes to a site, particularly on responsive websites.

I can make some changes and then very quickly cycle through a bunch of devices. It is not as good as testing on real devices, but its ease really means there is no excuse not to quickly test several different devices and resolutions.

If you want to improve the quality of your website, show anyone and everyone who makes changes to the site these features in Chrome.

Other Overrides

Chrome also now allows you to override geolocation and device orientation, and emulate touch events and CSS media.

The geolocation override isn’t very effective since most sites use IP routing information to figure out your location rather than the reported location of a device.

The emulate touch events option seems to work fine, but if you close the Developers Tools window it reverts back to mouse events only.

The CSS media queries emulation works okay. Google emulates the media queries faithfully. That means that it doesn’t modify the styles in the way Chrome normally does, like removing background colours, so be prepared to test using more than just the emulator. It does let you use Chrome’s normal, and excellent, debugging tools on print stylesheets which instantly make it a worthwhile tool.


The post Overriding User Agent in Google Chrome appeared first on OptimusQA.

What is Crittercism? And why does Google think it’s worth $12 million

Mobile app performance management company Crittercism just announced they raised $12 million in Series B funding from Google Ventures and other investors.

With all of the hype surrounding the funding I thought it would be nice to take a closer look at the tool to see who it is for.

Why is Google investing? Isn’t this a competitor to Google Analytics for mobile apps?

Google Analytics does have some crash reporting features, but Google Analytics is meant to give app owners insight in to how users interact with their apps.

Crittercism is focused on monitoring performance of your app in real time and it does this in much greater detail than Google Analytics.

Their error monitoring goes beyond GA’s basic crash reporting adding features like breadcrumbs that tell you what a user was doing before a crash to go with your standard device and operating system crash reports.

These features alone make Crittercism a compelling option for mobile application performance optimization. The new features announced along with their new funding round are really exciting.

They are adding tracking of network conditions and third-party cloud services.

Tracking down the cause of a crash in a mobile app is difficult. The problem could be with the app, the network, the app on a particular OS or version of the OS or device, the app under particular network conditions or with the servers that power the app. Any tool that can help us isolate the problem and get a full picture of the conditions that cause the bug is greatly welcome.

The tool is clearly designed for app owners who want to continuously improve app performance, but it is clearly useful for QA shops like us trying to help find and fix apps suffering from performance issues.

With the mobile market growing rapidly this type of tracking is going to become even more important for businesses.

The main drawback is that all of the best features are at the Enterprise pricing level, but you get what you pay for and GA is still pretty good for free.


The post What is Crittercism? And why does Google think it’s worth $12 million appeared first on OptimusQA.