Microsoft Technology Summit – Open Source and Azure and the Optimus Test Harness

Ryan O’Connor presenting the Optimus Test Harness at Microsoft Tech Summit in Vancouver

It was both a pleasure and a privilege to represent Optimus at the Vancouver Microsoft Technology Summit last week.

The tech summit is one of my favourite events. It attracts a lot of people – especially those who are working individually or remotely – and gets them out to an event where they can connect and talk about what is happening with technology and hear about the latest and greatest from Microsoft.

Also, it was an opportunity for me personally to reconnect with a bunch of people I have known from my many years of delivery; people who have moved on to other companies. Vancouver is a tight technology community, with a core of folks who have worked together over the years.

I was especially delighted that Microsoft asked us to co-present, because while the name “Optimus” might be new for some, the people who work here are well known, and so it allowed me to shine a light on some of the cool things that Optimus is doing. (Thanks Microsoft).

Microsoft and Open Source

Mark Godfrey from Microsoft was talking about Open Source on Azure and sharing some pretty interesting facts. Here are some of the stats he presented:

  • 4x growth in container customers in Azure since January, all with Docker on Linux!
  • ~40% VMs in Azure run Linux today
  • 60% of Azure Marketplace Images are Linux based!

optimus-ryan-blog-1 Microsoft Technology Summit – Open Source and Azure and the Optimus Test Harness

Mark was speaking about the investment that Microsoft has made and is making in Open Source. The image above really speaks to the journey. In the middle of his presentation he was explaining that if you are using Open Source software like Linux, Optimus is a great example of how you can work with a trusted partner to test an automation framework on Azure. At that point, Mark simply asked me to join him on stage and talk about the Optimus test harness.

The Optimus Test Harness

We have been helping customers move to the cloud and do their testing in the cloud for a while now. About 85% of our customers are tech companies that offer a product or a service. Most of them have cloud-based apps and a lot of them need to do testing on those apps. Locating something inside their tenant that is closer to the services they provide but also closer to Microsoft services like machine learning makes a lot of sense.

Three Ways We Can Help
  1. Proof of Concept. We can stand up our test harness on a customer’s tenant because there’s no licence fee. This helps customers prove the concept that automated testing might add value to them.
  2. Component Testing. We might test a particular component they are struggling with; for example, all the APIs. We might just do API testing or performance testing of some specific component. In that process, we might be doing end-to-end services. We will build and execute the script as a managed service.
  3. Knowledge Transfer. Or, we might take a more educational approach or a capacity-building approach, where we help an internal team grow in its testing maturity. In doing so, we are teaching, showing and doing. Ultimately, we turn everything over to the internal QA team to manage. Quite often, we end up continuing to provide service because of the value we deliver. The organization realizes that they can free up their resources to do other things and working with us is a cost-effective approach.

Ultimately, our approach is very consultative. We look at what you really need and what services you might want to embrace. For example, we can bundle the services (such as the creation of scripts) and the test harness into a licence fee so that you can purchase it as a capital expense.

The bottom line is that we can get you set up and get you going so that you will be able to do your regression testing with the push of a button.

Getting Started

Microsoft is investing in this approach and have already invested in several PoCs for customers who want to try the test harness. Let me know if you are interested in learning more. We can also help determine if you might qualify for Microsoft funding.

Reach out anytime – we would love to work with you. –

Could BYOD Work for your Enterprise?

With constant advancements in mobility and cloud the Bring Your Own Device (BYOD) technology strategy is not only for Startups anymore. According to Gartner, more than 60% of employees use a personal device for work including smartphones and tablets. When it comes to assessing the benefits and risks to a BYOD strategy there are still fairly mixed reviews. There are just as many reasons to switch to BYOD as there are to not make the switch. Here are a few things to consider when creating a BYOD strategy for your enterprise.

Costs Savings

The first and most talked about advantage of BYOD is the cost savings. Taking this route allows enterprises to phase out capital spending on hardware that will no doubt require upgrading in a few years time. The majority of employees are bringing mobile devices to the office already and are most comfortable with the device of their choosing so this can be a great advantage in saving costs on large amounts of unnecessary hardware.  

Mobile Device Management Software

For IT teams, the task of managing policy, inventory and security is becoming apparent. This is where Mobile Device Management Software (MDM) comes in. MDM allows IT teams to monitor, manage and secure employees’ devices across multiple service providers and operating systems within your enterprise. Most MDM software includes end-to-end security, which allows your enterprise’s IT team to fully manage the mobile apps, network and data used on the variety of mobile devices. Some MDM solutions also include mobile security and expense management. With the right MDM software you can reduce the security challenges that are prominent when switching to BYOD.

Security Challenges

Managing security is arguably the most complicated challenge in implementing a BYOD strategy. With the variety of devices, operating systems and mix of product versions your security policy will need to find ways to ensure everything is secured. There are a number of concerns related to security that your enterprise’s IT team will be managing including lost or stolen devices, mobile threats or internal security breaches. Before implementing a BYOD strategy conducting a full risk assessment can help your enterprise to understand where the greatest risks are and what the related cost will be.


Before implementing your BYOD strategy there are two important aspects to consider that can have a great affect on employee adoption and overall BYOD success. First, it is important to set out the guidelines for cost sharing to avoid any misunderstanding around who is paying for what. Here you need to consider who pays for devices, service plans, software or accessories. There are a variety of structures that can be used for this. For enterprises that require precise accounting there is software available that can monitor usage and cost differentiating between personal and business use. Other cost sharing strategies can be as simple as a monthly subsidy based on a fixed fee or percentage of monthly service plans.

Finally, when setting out to start your BYOD strategy finding a set of guidelines and policies that will work for your enterprise could be the key to success. Here you will want to set out guidelines around what your enterprise considers acceptable use for business versus personal. Some policies can get as detailed as to which apps are allowed or disabling camera and video camera use while on-site. You may want to consider which devices and what type of support your enterprise’s IT team will cover. Opening your policy to any type of device could create more costs and challenges for your IT team. Also important to include are the risks, liabilities and any disclaimers that would be relevant to your enterprise. To consider here would be precautions with lost or stolen devices, personal data loss, regular backing up, ethical use and legal issues if an employee or your enterprise become involved in a lawsuit which data would be required from a device.

Although there is a lot to consider in taking on a BYOD strategy for your company, the pay off can end up being worth it. It can create a competitive advantage and increase employee satisfaction allowing employees to feel more comfortable and empowered with the technology they are using. Adopting a BYOD strategy now can also allow for ease of IT evolution as we move increasingly towards mobile and cloud technologies.

Optimus Information provides both mobile and cloud strategy services and can assist with the implementation of MDM software. For information on how our team can help your enterprise contact us today.

Data Sovereignty in Canada


Most companies operating in Canada can store data wherever they want as long as they take measures to secure personal data.

Service providers working with public bodies in BC and Nova Scotia have stricter data sovereignty requirements including storing data in Canada.

Concerns about accessing data through the PATRIOT Act are misplaced because there are broader mechanisms in place for requesting and sharing data between governments and law enforcement agencies that predate the PATRIOT Act.


The PATRIOT Act was enacted in 2001 and it broadly extended US law enforcement’s powers to access data.

Companies with a presence in the US are subject to the PATRIOT Act regardless of where the data is physically located or where they are headquartered.

Canada offers no protections against the PATRIOT Act and only British Columbia and Nova Scotia have enacted any form of protection against the PATRIOT Act.

Furthermore, Canada, like most countries, has enacted legislation that grants similar powers to Canadian law enforcement agencies and, like most western countries, has agreements in place to share that information with foreign allies.

So, even if your company only operates in Canada and your data resides entirely in Canada, US law enforcement agencies can ask their Canadian counterparts for the data and the Canadian authorities will likely comply.

The main lesson is that if there is reasonable suspicion of criminal wrongdoing, then it doesn’t matter where the data is stored. For typical, non-criminal businesses, locating data in Canada with a Canadian hosting company offers very little additional protection.

Canada’s Patriot Act: PIPEDA

The Personal Information Protection and Electronic Documents Act (PIPEDA) governs how data on Canadians is collected, used and disclosed.

The main obligation for Canadian companies set out by PIPEDA is the requirement that “personal information shall be protected by security safeguards appropriate to the sensitivity of the information.”

You can store data wherever you want, just make sure anything sensitive is encrypted and password protected.

One of the main exceptions to PIPEDA’s protections is law enforcement and national security. That exception extends to sharing data with foreign bodies.

The Office of the Privacy Commissioner of Canada made this clear in a submission to the Office of the Information and Privacy Commissioner for British Columbia titled Transferring Personal Information about Canadians Across Borders–Implications of the USA PATRIOT Act.

“Canadian law often permits government agencies to share personal information that is held in Canada (by government or the private sector) with foreign governments and organizations, even without the consent of the individual to whom the information relates.”

Canada has signed a number of Mutual Legal Assistance Treaties with countries like the US and the UK that provide mechanisms for requesting evidence.

The Department of Justice then needs to apply for a search warrant before obtaining the information and then sharing it with the body that made the request.

British Columbia and Nova Scotia have enacted laws that govern records held by public bodies that apply to service providers working with public bodies. Both laws require that data be stored in Canada.

Freedom of Information and Protection of Privacy Act (BC)

The Freedom of Information and Protection of Privacy Act (FOIPPA) regulates access to records held by public bodies and privacy standards for such records in the province of British Columbia (BC).

Many of the privacy-related sections of the act apply to “officers of the Legislature, their employees and, in relation to their service providers, the employees and associates of those service providers, as if the officers and their offices were public bodies.”

That means that if you provide services for a public body in BC, then FOIPPA may apply to you.

Sections that apply include the data sovereignty provisions of FOIPPA which require that data collected by public bodies in BC be stored in Canada.

In addition to storing the data in Canada, organizations subject to FOIPPA are required to report foreign demand for disclosure to the minister responsible for FOIPPA.

This means that companies subject to the Patriot Act would be compelled to give requested data to US authorities and report the transaction to BC authorities. In practice, US authorities would likely ask Canadian authorities (who are exempted from notification) to share data thus circumventing any FOIPPA protections and responsibilities.

Most of the other applicable sections are related to storing data securely and unauthorized disclosure/access.

The following is the complete list of sections that apply to service providers as listed in the act:

  • Section 30: Protection of personal information.
  • Section 30.1: Storage and access must be in Canada.
  • Section 30.2: Obligation to report foreign demand for disclosure.
  • Section 30.3: Whistle-blower protection.
  • Section 30.4: Unauthorized disclosure prohibited.
  • Section 30.5: Notification of unauthorized disclosure.
  • Section 33: Disclosure of personal information.
  • Section 33.1: Disclosure inside or outside Canada.
  • Section 33.2 Disclosure inside Canada only.
  • Section 74.1: Privacy protection offences.

Personal Information International Disclosure Protection Act (NS)

The Personal Information International Protection Act (PIIDPA) applies to personal information collected by public bodies in Nova Scotia.

The act also applies to service providers defined as “an individual or a company that is retained under a contract to perform services for a public body, and in performing those services, uses, discloses, manages, stores or accesses personal information in the custody or under the control of that public body.”

Similar to the BC law, PIIDPA requires data covered under the act be stored in Canada. It also requires that foreign requests for disclosure be reported to the Minister responsible for the act, but specifically exempts foreign law enforcement agencies that request information through federal or provincial agreements.

In addition, it specifically prohibits storing PIIDPA data in portable devices while travelling unless given specific permission.


At the moment, there are very few data sovereignty requirements that apply to Canadian companies. The most common ones are satisfied by basic security practices that you should already be doing.

Keeping your data in Canada over PATRIOT Act concerns is also unnecessary. Most Western countries already had mechanisms in place where Canadian authorities would provide data that resides in Canada. The PATRIOT Act mostly only asserted the US’s right to unilaterally request data from companies with a presence in the US where they already had the bilateral right to do so from companies in Canada.

The only way that you can guarantee that you are made aware of those requests is by running your own data center, when you receive the subpoena for the data, or if you are working with data belonging to public bodies in BC and Nova Scotia, where provincial data sovereignty laws apply.

As with any post on legal topics here, this is an overview of the laws and does not replace proper legal advice in any way.


What to look for when testing SMS apps

Short Messaging Service, or SMS, components of an application require special attention when developing a test plan. Anything from basic sending of an SMS to user interactions and internationalization can be a source of problems and need to be tested.

Texting may be simple for the user, but not for testers. Here are some of the things that we have tested for on the SMS components of applications.

Service Provider or SMS Engine Setup

The first step in sending an SMS is to either establish a link with a service provider or create your own SMS engine. Regardless of the method you choose, you need to test that you are able to create and send your message and that your message is being sent over the right path.

 Message length

While creating the message you need to watch the message length. Early phones could receive only one message at a time and with only a limited number of characters. As technology advanced, longer, threaded messages became possible.

You don’t control the recipient’s device, so you need to test that longer messages display well on devices that don’t support longer formats or test that your messages don’t exceed the 160-character short format depending on whether you choose to limit your application to short-format messages.

If you choose messages longer than 160 characters, then you need to split the message up for short-format devices and ensure that you clearly identify which message is the first part and which are subsequent parts and, of course, test your implementation.

Reply Options

What is the purpose of sending the message? There are two common answers to this question.

The first is to inform. So a bank might let customers set up SMS notification for when a withdrawal is made. For informational messages, you just need to check that the message content is correct and it gets delivered.

The second is to solicit a response. A shop asking you to rate their service is a good example. SMS messages that require replies need to test some special scenarios.

  • All of the response options function and are correctly placed in the message content.
  • Single and multi option replies function as required.
  • Response is handled properly by the server.
  • Correct action is taken after receiving the response.
  • Invalid responses are handled properly.
  • Response can be entered either with the option text or the digit assigned to the response as required.
  • Case sensitivities of the reply options.
  • How the application handles duplicate responses.
  • How the application handles responses after expiry time.

Format and Content

The message content which is generated should be properly formatted and all the formatting issue should be tested.

  • Special characters should be properly encoded and placed.
  • Line feed characters should work correctly.
  • Line spaces, if present, should be display properly.
  • Reply options should be properly placed and should be identifiable by just reading the message.

Dynamic content

The way you generate your content completely depends on your application. Predefined scripts, sometimes in combination with a database, are commonly used to generate messages in web applications.

Regardless of how you generate the message, any dynamic content should be properly verified.

  • Dynamic content needs to be checked for accuracy. An extreme example is ensuring that the bank withdrawal message should show the balance from the correct account.
  • Dynamic content needs to be checked for length. Entering a long name, for example, shouldn’t break your message.

Opting Out

It is inevitable that some users that join your service will want to opt out of SMS notifications. Opt out mechanisms should be properly tested.

So, for an application where texting stop opts you out of the messages, check the following scenarios here.

  • If user respond with stop term, then unsubscribe his/her device to receive further messages.
  • Also unsubscribing should also make the desired changes in the database.
  • The stop message should be case insensitive.
  • A response from any device that is not registered should result in no action unless otherwise required.

Different Countries

If your application is global, your recipients will live all over the world. You need to make sure that your application works in all supported countries. When sending messages to different countries you should check the following scenarios.

  • Proper country code is added to the message address.
  • Your application complies with local regulations. Some countries restrict the amount of SMS that can be sent over a period of time to preserve bandwidth for emergencies. You need to make sure that your application stays under the limits.
  • The cost for each message depends on the country. You need to make sure that your application records the correct data in database to ensure billing is handled properly.


Reporting is important to any business application. For applications that use SMS, the status of messages can be tracked serving as the basis for delivery reports. You will want to test you are reporting the correct status. You need to simulate various scenarios and then test the reports. Some of these scenarios are:

  • Message sent successfully.
  • Message not sent due to internal failure (ie. misconfigured application).
  • Message not sent due to external failure (ie. service provider failure).
  • Message re-sent.

Check Logs

Log files help us figure out the process flow and are useful for debugging. We need thorough and detailed logs. Logs must be set properly to capture each and every detail from generating the message, initial routing of the message and delivering the message. If any debugging is necessary, you just need to reference the logs for that event and will be well on your way to discovering the source of the bug.

For logs to be a reliable debugging tool, they must be properly tested by simulating different responses. Log file documentation also needs to be prepared if it is not already present.

Generally an SMS log statement is based upon its levels.Various log levels are:

  • FATAL: This indicates that the server or application failed.
  • ERROR: This indicates that application will continue to run but specific functionality that is processed by the current thread failed.
  • WARN: This indicates that application will continue to run but specific functionality that is processed by the current thread may be operating on some data that is not appropriate.
  • INFO: This indicates progress of the specific functionality that is processed by the current thread.
  • DEBUG: This provides fine-grained information about the progress of the specific functionality.The DEBUG level is used to log messages that are useful for customers, support and development to diagnose problems remotely.

The post What to look for when testing SMS apps appeared first on OptimusQA.

Cookie Testing: What and How to Test

Cookie are text  files that gets saved by a web site through your browser on your disk which can be retrieved by the web site that saved them. Cookies are used in a lot of web applications. They are commonly used for remembering your email and password, but allow all sorts of more complex interactions and features.

Cookies are fundamental to the functioning of many of the web’s more complex and interesting sites, but they can also introduce security risks. It is important to test your site’s cookies for both of these reasons.

How to Test Cookies?

Testing cookies is a common task for a software tester as they are essential to many web applications which include informative content and payment transactions.

Below are the steps which should be considered while doing testing:

  • Disabling Cookies: An important part of cookie testing involves disabling cookies on your browser. You need to make sure that cookies are disabled and then access the website checking that the pages that are working properly. Browse the whole website and watch for crashes or other roadblocks. Check that the site has either implemented workarounds for browsers with cookies disabled or that the user is informed that cookies are required to use the site.
  • Corrupting Cookies: Another testing that should be performed is corrupting the cookies. To corrupt the cookies, you find the location of the site’s cookie on your local machine and manually edit it with fake and invalid data. Corrupted cookies can be used access internal information from the domain which can then be used to hack the site. If you are testing banking or financial sites, then testing corrupted cookies should be a priority.
  • Removing Cookies: Remove all the cookies for the website you are testing and check website still works properly.
  • Cross-Browser Compatibility: You should also check that cookies are being written properly on all supported browsers from any page that writes cookies.
  • Editing Cookies: If you are testing an application which uses cookies to store login information then you should try changing the user in the cookie or address bar to another valid user. Editing the cookie should not let you log in to a different user’s account.

Throughout testing, you should always check that a proper error message is displayed.

Cookie testing is really important for the functioning and security of any web application and it should be a part of any web testing plan.

The post Cookie Testing: What and How to Test appeared first on OptimusQA.