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.

Quality Considerations when Switching to Agile

One of the clients we’ve been working with lately is in the middle of switching to Scrum.

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.

We don’t need testing, we’re agile

It should surprise no one that I don’t agree with the “we don’t need testing, we’re agile” crowd. I work with a QA shop after all and we are no strangers to helping agile teams.

Even Test Driven Development benefits from a little extra testing. Unit tests are great for making sure that all of the little bits work the way they should.

But anyone who has worked on a large software project knows that putting things together can expose a whole new world of bugs to squash. Small changes in one isolated part of the application can cause something to break in a completely different and only tenuously related part.

As you move from fully automated testing in to partially automated testing the need for a separate testing resource increases.

It doesn’t make sense to automate every functional test. If you’re going to have to change the tests over and over because of changes to the features, it doesn’t make sense to automate.

Agile practices in particular is supposed to embrace change. If you know that there is a lot of uncertainty surrounding a particular feature, then it’s probably not worth the effort to automate the relevant functional tests in sprint one because you’ll end up spending more time writing test automation than you would just testing manually.

As testing gets more and more manual, having someone to do the testing other than the developer that wrote the code becomes more and more important. It is a lot easier to see the flaws in the work of others. This is true of anything. Simply knowing your intent makes it easy to miss flaws in your own work.

You can automate performance and load testing and monitor application and component performance so that you know when you’ve introduced code that might need some work. But as the application grows in complexity so does the expertise needed to analyze performance and load tests. Developers who can set up and analyze performance and load test data for complex applications are few.

Once we get to fully manual types of tests, the “we don’t need testing, we’re agile” argument really falls apart.

You can argue that acceptance testing is part of the process. But exploratory testing is going to find a whole new class of bugs that automated functional, performance and unit tests just can’t find.

And usability testing? I wouldn’t trust anyone to make the right decision for end-users all of the time which is why we test.

Agile practices are generally great for producing quality software with a minimum number of defects. We welcome software practices that improve software quality even if it means less testing for us. But agile is not immune to bugs. We’ve worked with some fantastic agile teams and we’ve helped them produce even better software.  Just like in a waterfall model, as applications grow more complex, so too do the testing needs of agile teams.

The post We don’t need testing, we’re agile appeared first on OptimusQA.

Outsourced Agile Testing with Optimus

Software testing and agile development are still learning how to get along.

You have some agile development practitioners who believe that being agile somehow means they don’t need QA. Agile practices like test driven development and the improved responsiveness help reduce the number of bugs in a product, there is still a lot of room for software testing.

It seems like the most successful integrations of dedicated QA professionals in to agile teams make the QA practitioner an equal member of the team. At the start of the sprint, the QA practitioner will begin writing user stories and preparing tests. And once this is done, she grabs whatever code that she can and begins running tests.

To be successful in this role, the QA practitioner needs to have strong technical skills and the team needs to structure their sprints to start delivering testable code as early as possible.

This level of integration is clearly not possible when working with a predominantly offshore testing team like Optimus. However, working with agile development teams over the years, we have refined our onshore-offshore hybrid outsourcing to integrate well with agile development teams.

Individuals and interactions over processes and tools

The agile manifesto values individuals and interactions over processes and tools. This value is difficult to reconcile with outsourcing your testing to an offshore team.

To be honest, our solution isn’t perfect either. But it is a lot closer to the core agile values.

We use our local presence to insure that your software quality remains in focus and that your developers have a QA Lead that they can speak with whenever necessary. We embed the QA Lead in your development team. The QA Lead takes part in SCRUM meetings and looks after the immediate day-to-day testing needs of the project while staying on top of the changes to the product and code base.

Then, at the end of the day, the QA Lead communicates with the offshore testing team making sure that they know what’s happened in the last day and, most importantly, what has changed.

Overnight, the offshore team then run whatever manual and automated testing is needed based on the day’s work and report any issues for you and your teams to deal with in the morning.

Having a portion of your software testing performed over night is in many ways better than having QA practitioners in your agile teams. There isn’t as much pressure to deliver testable code early in the sprint giving your programmers at least until the end of day to deliver. Developers can also focus more on development without getting distracted by bug reports coming in during the day.

Our QA methods may not be agile according to the strictest definitions, but they work well and we haven’t run in to an agile shop yet that complained about things just working well.

The post Outsourced Agile Testing with Optimus appeared first on OptimusQA.