UBC offers an excellent BCom Major in Business and Computer Science that combines technical and business knowledge that is necessary to run modern technology businesses.

Some of the key points from the session included real life examples of abstract concepts that had been covered previously in the class and in other classes in the program.

The video is embedded below.

Optimus as an organization, and many of Optimus’ employees individually, supports a number of education and technology causes around the city including TEDxKids and Science World. Please feel free to contact us if you want to know more about our community involvement or could use some of Optimus’ expertise to support your education and technology cause.

We are using these charts on iOS, Android, Windows Phone and iOS to power our social app for investor relations.

The post How to Display Yahoo! Finance Stock Charts in your iPhone App appeared first on OptimusMobility.

End users’ time is the most important element in the successful implementation of business intelligence in any organization. The cost of  a BI project is the amount of money spent on planning and implementation plus the amount of time  needed from end users. If you are not prepared to invest enough in either, then you are going to be disappointed with the results.

End User Requirements

In order to keep this post simple, I will use developing external reports as an example. In this sort of project, end users need to provide the following:

• Report design: details like font size, layout, report border colours and logo placement.
• Input parameters and columns: details like column names, parameters names, parameter values and default parameter values.
• Usage scenarios: help report writers write the logic by providing all possible scenarios.
• Test cases: help validate the report using all possible scenarios.

Requirements Documentation

We use a “Universal Specification Document” to capture information that is common throughout the project. This is usually a one-time discussion with the end user and it covers things like branding and fonts.

We use “Report Requirements Document” and “Report Design Document” for every report to be developed. The purpose of these documents is to help both the end users and Optimus business intelligence team with the following:

• Capture all the information required in the report writing project.
• Be efficient in developing the report.
• Save a number of report iterations, meetings and reduce the time and expense required to develop the report.

Feel free to contact us with any questions you may have on our process and templates or learn more about our report development services.

The post The Secret Success Factor in Business Intelligence Projects appeared first on OptimusBI.

Testers naturally want the product to be perfect, but letting testers get their way in that respect just doesn’t make business sense in most situations. With most software projects, the software needs to be good enough. If it takes time or costs money to make it any better, then it is costing you money and you need to weigh the cost of launching with the bug unfixed against the cost of fixing the bug and delaying launch.

If you are testing a system where failure results in catastrophe, like airplane systems, then you can stop reading now. No, please stop reading.

Once you are past catastrophe, you need to consider what is good enough and then structure and automate your test cases to ensure that you are catching the right bugs.

In order to help you catch the right bugs, we often structure our automated and manual test suites into three classes: critical tests, important tests and nice-to-have tests.

Critical Tests

The first thing you need to do is figure out what is the critical functionality in your application. Any tests for critical functionality need to pass. These tests also tend to be great candidates for test automation since you will be running them frequently.

For an ecommerce site, critical tests are any tests related to purchasing and normal shopping activities from browsing and learning about products to purchasing and everything in between. Affiliate and customer retention activities would also probably qualify.

As a business, you want your testers to catch everything in the critical basket and make sure that they get fixed as soon as possible. Any error caught here is costing you money or is destroying your credibility as a business.

Important Tests

The next thing that you want to cover is important workflows. Once you get to important workflows, perfection becomes optional.

As a business, you need to decide if the bug is big enough to delay release. Often it is not, particularly if there is a decent workaround.

As with any decision, you need to weigh the costs of fixing against the costs of not fixing. Some bugs discovered in an important test

Important tests are also good candidates for automation, once you’ve automated critical tests of course.

Nice-to-Have Tests

Now we are getting into features that most people don’t use. If you can fix these bugs before release, then do it. But never stop a release because of a bug in this list.

If you want to automate these test and have the budget, then great. It will help you be more proactive with the quality of your software. But, if it is not in the budget, then skip it with no regrets.

Usually the decision to automate nice-to-have tests depends on your software development methods more than anything else.

Software doesn’t happen in isolation from business and neither should software testing. Make sure your software testing efforts support your decision-making.

The post How a Properly Structured Test Suite Helps You Make Better Decisions appeared first on OptimusQA.

If you are embarking on a self-serve BI project, or you are concerned that you could be getting more from self-serve BI, then these are important user-centered points to keep in mind.

1. Understand the needs of self-serve BI end-users.
2. Ensure the data is correct.
3. Train end-users to use the tools.
4. Prioritise your reports.
5. Give detailed requirements.
6. Validate your reports against usage scenarios.

A brief summary on each of the above points is as follows:

1. Understand the needs of self-serve BI end-users

   Before starting any self-serve BI initiative, you should understand the needs of end-users. Senior management, business unit heads and any other stakeholders should be involved in determining the needs.

   Early involvement will help eliminate redundant reporting. This also provides an opportunity to map out the business units who can be satisfied with single report like Employee Performance Reports that can be shared with the Department Managers and HR.

2. Ensure the data is correct

   Big companies accumulate data sources and data can very quickly get out of control.

   Data sources often include internal applications, external feeds and various software as a service applications. Having a single version of correct data is a must.

   This can be achieved by developing a data warehouse or a central database. Having correct data in one place is a key first step to giving your organization the tools to make good decisions.

3. Train end-users to use the tools

   Training should be provided to the end users on the self-serve BI tool. This will help them understand the capabilities of the reports. Training is critical as end users may end up creating ineffective reports.

4. Prioritise your reports

   Management should sit down together and decide which reports need to be made and order the reports by priority. The reports will provide maximum value as the highest priority reports get developed and deployed first.

   This will help prevent end users from getting overwhelmed by a large number of new reports all at once giving them time adapt to the tool.

5. Give detailed requirements

   Detailed requirements are necessary in the report development process. This step requires effort from both the business analyst and the end user. Having detailed white boarding session(s) will reduce significant amount of time in the iterations after the report is developed.

6. Validate your reports against usage scenarios

   Test cases from the end users help significantly in the successful development of the report. End users should provide test cases comprising of all possible scenarios. This also helps in combining business logic with the application logic and result in correct query writing.

We have worked on many self-serve BI reporting projects. Contact us and we’ll be happy to share our experience with you and address any questions you may have.

The post 5 Steps to Better Self-Serve BI Reporting appeared first on OptimusBI.

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 OptimusMobility.

They are having many of the struggles that you see with development teams trying to make the switch like overcoming resistance to change, understanding the value of each part of the process and agile as a whole, and figuring out how to integrate testers into cross-functional agile teams.

We have been helping them a bit with their switch trying to show how Scrum is supposed to work while working with them and also setting up and automating test cases for them.

We often see teams that are switching to some flavour of agile struggling with integrating their testers.

The biggest obstacle to these testers often isn’t unwillingness to change or a lack of skills, but rather the missing backlog of years worth of automated tests that are essential to agile QA. Their testers aren’t able to deliver despite having the skills to do so because they just have too many urgent test tasks covering immediate changes that prevent them from setting the automated tests that they need for long-term success.

If you are switching to cross-functional agile teams while working on a software code base that doesn’t have a mature automated testing suite, then consider budgeting a few sprints for test automation.

It seems like a very odd and narrow niche, but we actually do business setting up the automated testing for teams transitioning to agile so that they don’t have a mountain of test debt to catch up with before they can get back to delivering quality software.

We help them by compressing a year’s worth of test automation in to one month. Suddenly, those testers that were frustrated and seemingly incompetent are confident and capable because they aren’t playing catch up with their automation.

This in turn lets them devote more attention to figuring out agile making the switch more likely to succeed.

The post Quality Considerations when Switching to Agile appeared first on OptimusQA.

Her main point in the article is that successful software projects, distributed or otherwise, ultimately rely on team and company culture. The characteristics of a successful testing program are the same whether co-located or distributed. The only difference is that distributed teams have to work harder to get results.

I don’t want to repeat everything she says in her article because she does that quite well herself. Many of our core values are our responses to the challenges that she identifies because they are the same challenges that we see everyday.

So how do we help deliver quality software when the keys to a software project’s success are team and culture and most of our testers are on the other side of the world and work for a completely different company than clients like you?

Rapid Feedback

The first key to getting quality software identified in Lisa’s article is rapid feedback.

Working with agile teams of all flavors has taught us the importance of rapid feedback. Our agile testing processes were developed to meet the feedback needs of agile teams.

While we can’t give the immediate feedback that you’d get with developers and testers sharing a room in a cross-functional agile team, we do get overnight results from our offshore testing team.

And if the project needs, then we have an onsite Test Lead (either and Optimus contractor, or a client employee coached by us to manage onshore-offshore communication) who can run automated tests as necessary if there is a need.

Separation isn’t always a bad thing either.

Focus is also important to success and communication and focus don’t happen at the same time. If you are offshoring your testing, then you get a big chunk of focus time in the middle of the day with overlap at the beginning and end of the day where all of the important communication happens.

Building the Distributed Team Culture

The second key to getting quality software is team culture.

How do you build a distributed team culture when the distributed part of the team is outsourced?

Another of our core values that directly responds to this challenge is our commitment to integrating seamlessly with the client team.

Lisa calls this especially critical in offshore situations. We agree.

While we haven’t gone so far as to schedule regular face-to-face meetings between our India testers and client developers, we have had a number of senior testers and CTOs visit with the testing team while on holidays and getting to see a more local flavor of New Delhi at the same time.

Video communication isn’t always possible, but we try to keep our communications as open and transparent as possible.

Onshore Test Leads also help bridge the culture gap in a distributed team. Our Test Leads get close to the testers that they work with and they also get to know the client teams as well.

Lisa goes on to mention a number of practices and techniques for making distributed testing work including pairing, using communications technologies, and keeping work visible.

While we haven’t tried pair work with client developers during overlap time, we are certainly willing to try.

Visibility is a key part of every step in our process and detailed documentation ensures that you continue to benefit from our expertise even after our engagement ends.

All of the other practices that she lists are important parts of our processes.

• Our technical team communicates regularly with yours.
• Our management team ensures that your management team is kept in the loop too.
• And our use of local Team Leads also helps us understand your culture and adapt to it.

Quality in an Agile World

The quality processes that we have developed are learned through decades of experience in outsourced software testing working with both agile and waterfall teams.

Ensuring quality goes beyond just doing the testing. It requires a commitment to integrate with your team and your processes. Otherwise, testing and action become disconnected and ineffective.

The post Offshore Distributed Software Testing appeared first on OptimusQA.

Step 1: Show Hidden Files

The first step is to configure the Finder in OSX to show hidden files. This gives you the ability to drill into your Library and down to your simulator where your iOS app is being run. From here you’ll be able to access all files in your iOS application including files that would be synchronized with iCloud.

1. To do this, open up Terminal and enter the following command:
   defaults write com.apple.Finder AppleShowAllFiles YES
   
   
2. Then relaunch Finder (CMD+Option+Escape, select Finder, and choose relaunch)
   

You can now see hidden files in Finder.

Step 2: Run Your SQLite Enabled Application in the iOS Simulator

1. Open up Xcode
2. Open up a project that contains a SQLite database (there is a good sample project here)
3. Run the application in the iOS simulator
   

Step 3: Navigate to the Folder that Contains your Simulated iOS Application

1. Open up Finder
2. Navigate to the following folder: /username/Library/Application Support/iPhone Simulator/5.1/Applications/*your app code*/Library/Caches/
   1. Note that “5.1″ will be whichever version of the simulator you’re running and that you may have to dig through the app codes to find the right app. Also, in the Caches folder your database may be contained in a sub-folder.
      
3. Here you’ll find the actual running copy of the SQLite database that your iOS app is accessing. You can open it using a Firefox plugin or any SQLite database editor. MesaSQLite is a very good one.
4. Once you have the database open, you can make changes and view changes from your app as they happen.

The post How to Access the SQLite Database in iOS Simulator appeared first on OptimusMobility.

We just published a couple of case studies showcasing some interesting work that involved QA strategy elements and I want to highlight them here because there is a lot more to our QA strategy service than just creating a test plan.

QA Strategy for Junior Test Team

The first strategy case study that I want to highlight involves a company that had a test team composed almost entirely of junior testers. Their testers were doing a fine job of finding bugs. But the problem was that they weren’t finding the right bugs often enough.

An Optimus senior consultant visited with the company and determined what tests needed to be run while educating the junior client team to help them understand and better evaluate technical risks.

Meanwhile, the Noida team automated these tests running the first set of tests before handing them off to the client.

In the space of a month, the company’s QA practice went from inadequate to robust. And they did this without having to hire and retain expensive and difficult to find senior talent.

Perhaps the biggest benefit is that the client’s QA team now has an understanding of what to prioritize and why. The improved QA practices gives them a model for them to learn from and let the lessons crystallize.

Continue reading: QA Strategy for Junior Test Team

Incorporating QA in Upstream Engineering

The second strategy case study that I want to highlight involves a company with slightly more mature QA practices, but was looking to better integrate their QA efforts within agile development.

This is a good time to remind you that Optimus has software, BI and mobile-focused practices and our QA practice can draw on experts from the other practices when we need specialist knowledge like experts in agile development for example.

The client was already doing agile QA. Or they were at least trying to do it. QA practitioners were integrated into cross-functional agile teams and they were testing their team’s code as they wrote it making testing in integral part of each sprint.

As an aside, when you outsource agile QA with us, the testing is typically performed in our offshore facilities overnight. It’s not as intimately integrated as with in-house agile QA. But it keeps up with the pace of your agile teams just fine.

The problem was that the client didn’t have some key high-level testing infrastructure in place like proper test environments and appropriate automated tests, and they didn’t want to disrupt their QA practitioners who were still trying to figure out agile.

Our solution involved supplementing their QA staff with some of our consultants. Their staff would devote as much time as possible to the high-level testing infrastructure tasks we proposed without disrupting their agile teams, so that they would understand enough to own the new infrastructure while our staff ensured that the project wouldn’t take too long.

Finally, we wanted to use the project to demonstrate how agile is done and help them with their adoption of agile.

Continue reading: QA Strategy: Incorporating QA in Upstream Engineering

So, yes. We do write test plans and test cases. But QA strategy at Optimus goes way beyond just that and you should definitely contact us if you find yourself struggling on the strategy end.

The post QA Strategy: More Than Just a Test Plan and Test Cases appeared first on OptimusQA.