WHO WE ARE
Founded in 1994 by top thought leaders in the software testing industry, LogiGear has completed software testing and development projects for prominent companies across a broad range of industries and technologies.
LogiGear provides leading-edge software testing technologies and expertise, along with software development services that enable our customers to accelerate business growth while having confidence in the software they deliver.
LogiGear is headquartered in the heart of Silicon Valley with the majority of the software testing and software development staff located in Ho Chi Minh City and Da Nang Vietnam. We are among the largest employers of software testing and development professionals in Vietnam, and our close partnerships with universities throughout the country allow us to attract and recruit top software engineering talent.
LogiGear continues to grow as companies realize the benefits of outsourcing their software testing and development. We have been listed among the fastest growing privately held companies by Inc. 500|5000 in 2009, 2012, 2013 and 2014.
The senior executive team has co-authored several top-selling books on software testing and test automation, including:
- Testing Computer Software, by Cem Kaner, Jalk Falk and Hung Q. Nguyen
- Testing Applications on the Web, by Hung Q. Nguyen, Michael Hackett and Robert Johnston
- Integrated Test Design and Automation, by Hans Buwalda, Dennis Janssen, Iris Pinkster, and Paul Watters
- Global Software Test Automation, by Hung Q. Nguyen, Michael Hackett, and Brent K. Whitlock (foreword by Apple Computers co-founder Steve Wozniak)
EuroSTAR Software Testing Conference 2016 Webinar
Test automation has been around almost as long as software has been developed. In the age of Agile and the DevOps arena, having tests fully automated is increasingly becoming a key factor to the success of a project. The best place for the creation of tests is the agile sprint team, where product owners, developers and QA’s work together. Tests and their automation should be ready when a sprint is “done”. However, more often than not teams find themselves in a situation where the functionalities under test are ready, but the tests are not.
In this webinar Hans will go through a number of solutions a team can do to diminish this problem, and what actions to take when it happens. Hans will discuss the following solutions how one can apply better test design to drive better automation, a number of technical strategies, what developers and product owners can do to help, and how to handle the testing and automation work that is still left after a sprint has finished. A key item in handling the test automation work that is left over is that QA’s need to own the testing from the beginning, and should not get stuck in the work of previous sprints, since that will inhibit good cooperation with other team members, making matters worse.
- Get more tests created and automated.
- Make automation manageable and maintainable.
- Keep the QA people in sync with their fellow team members.
Hans has been working with information technology since his high school years. In his career, Hans has gained experience as a developer, manager, and principal consultant for companies and organizations worldwide. He was a pioneer of the keyword approach to testing and automation, now widely used throughout the industry. His approaches to testing—action-based testing and soap opera testing—have helped a variety of customers achieve scalable and maintainable solutions for large and complex testing challenges. Hans is a frequent speaker at STAR conferences and is lead author of Integrated Test Design and Automation.
Automation Friendly Test Design—An Example
A major contributor to success in test automation is test design. If tests have many unnecessary detailed steps and checks, even a skilled automation engineer will not be able to make the automation efficient and maintainable.
Action Based Testing (ABT) uses a modular keyword-driven approach. Tests are organized in test modules and are built up of sequences of actions. In our TestArchitect tool, we define these in a spreadsheet format that is easy to understand.
Well-defined test modules can provide a healthy framework for teams to work with, in particular if modules have a clear and unambiguous scope, the scope is well-differentiated from other test modules, and all test cases, actions, and checks within the test module reflect the scope.
A key differentiation is between business tests and interaction tests. Business tests have a business-oriented scope and should not contain UI details. Interaction tests focus on the interaction between the user (or another system) and the application.
Other than this fundamental distinction, various projects may come up with different ways to organize tests. I want to share a way that we have had good experience with. It is based on the observation that, for many applications, a lot of the tests can be well-organized into two main categories: business objects and business flows.
Business objects are the items that an application works with, such as customers, employees, orders, invoices, etc. Business flows are the (mostly) end-to-end processes that usually hit more than one business object. For example, processing an order can involve the order itself, articles, invoices, payments, etc. Most tests will fit in categories (folders) for business objects and business flows. What’s left over are various tests in categories, such as administration, interoperability, data, etc
Consider an e-commerce site. People can view and order items and buy them with a credit card. Such a site would have business objects: articles, customers, orders, payments, credit cards, etc. As an example business object, let’s assume that the site supports “promotions” in which discounts are given under certain conditions.
- be a discount percentage or dollar amount
- be based on articles, article categories or comprehensive
- have a certain time period
- be rewards for volume or timely payment
- be regional or global
To manage promotions, the site will have various UI functions, either web-based or regular. In the UI there might be specific behaviors to be tested, such as a date can only be in the future.
Carefully organizing and designing tests can be a great contribution to their quality, efficiency, and manageability. In particular, it can help make their automation more stable and maintainable. A business-oriented approach to the test design, for example, centered on business objects and business flows, can be a great start to obtaining a good and automation-friendly test design.