Are you looking for an automation alternative to open source that’s easy to work with for non-developers? Are you also looking for a solution that is easy to design and scale? If so, TestArchitect by LogiGear might be the perfect fit for your team. And after you hear the big announcement near the end of this episode, you’ll be surprised at just how easy it is to get started. Check it out and discover how TestArchitect can help everyone on your team get started with test automation.
About Hung Q. Nguyen
Hung Nguyen co-founded LogiGear in 1994, and is responsible for the company’s strategic direction and executive business management. His passion and relentless focus on execution and results has been the driver for the company’s innovative approach to software testing, test automation, testing tool solutions and testing education programs.
Nguyen is co-author of the top-selling book in the software testing field, “Testing Computer Software,” (Wiley, 2nd ed. 2002) and other publications including, “Testing Applications on the Web,” (Wiley, 2nd ed. 2003). His experience over the past three decades includes leadership roles in software development, quality, product and business management. Nguyen holds a Bachelor of Science in quality assurance from Cogswell Polytechnical College, and completed a Stanford Graduate School of Business Executive Program.
Quotes & Insights from this Test Talk
- I think there's a correlation not only with creativity but also logic as well because you know music has a lot of structure and logic in and understanding the basis of you know the structure the mode the scale and then taking that and improvising based on those structure requires you know creativity but also the craftsmanship. So I think that to me I relate a lot of that into thinking about testing and test automation and solving those problems.
- I think a lot of philosophy about testing particularly in the context of customer driven quality just you know quality means different things to different people the user the customer plays the biggest role in defining and perceiving what quality is. And I think that philosophy still plays very well today. And I thought I that's one of the really well in terms of understanding that I think things have changed a lot since that book was published and a lot of that has to do with the demand of test engineer need to be a full stacked engineer. Which requires not only understanding how programming but having to be able to write script to go around at least you know in one or two languages. So that's a key component in being a good test engineer today whether you do functional automation or API testing or any other type of technical testing — that plays a big part in what we are doing today. Also the other part of that I think that's some big challenges that we are going thru now but I think it's really good development. It's what we're seeing in continuous integration contentious testing and continuous development which is also shift the paradigm of how automation to be done. In the early days. Automation was more thought of as you develop these automation and you run those automation, but now you might be developing that automation. But somebody would take that asset and execute somewhere else. So that that's what we did. We didn't see when we were writing that.
- So when we design Test Architect at that time you know Mercury Interactive with this automation suite dominated the market. But what we were focusing on it wasn't about automating past what we were focusing on is solving the problems in which when you have these tests. The software will change. Meaning that the test will change. So how are you updating these tests? Because creating a test is one thing. They will change and they will change very rapidly. How do you rapidly change the test and maintaining it and updating it so that you can scale and that's that's the thinking behind the design of Test Architect. We want to make sure that number one we design it so that you can easily create a task with minimum requirement on coding. But engineering wise we also want to design that so that it wasn't meant to be a dumbed down test automation tool. It's easy to use but it has to have the built in software engineering method that's embedded in the software and the workflow. And it had to be very easy to update and maintain tests. So we basically applying what Hans came up with this is keyword where we separate, we decouple, the automation in the keyword and the test logic will be written outside of that. And that's the whole premise of how we have been delivering this solution.
- So that the biggest benefits that you get with using Test Architect is when you have very very large test suites that we're talking about thousands and thousands of test and we often you know have these company come to us and they have a problem with improving or increasing test coverage. And when we implement Test Architect you know we do something pretty insane like we get to like 80 85 sometimes 90 percent of test coverage. And the reason that we are able to do that is mainly because of the architecture of the tool enabling a larger pool of test engineer that requires less programming skills. And you have just only one or two developers to support this larger pool. So you technically you have a larger pool of resources so you have more people to write test to scale. That's number one. But then just go back to the old story. All right. But you write them in the end the software changes. And what do you do. So we already have the design in place where this allows us to update the test very rapidly. So at the end of the day really the biggest benefit is the cost of ownership in terms of you know number one being able to have a very large volume of test. And number two it is affordable because it's easier to find really less expensive to have non programming staff who can contribute to the automation effort. And at the end of the day you spend less money and you have a larger volume of tests for your project. And that's that's really to me that's a win. Because you know at automation I mean a lot of people don't think about this but really before you even automate you have to think about you know what success would look like. Sort of like a Stephen Covey of seven habits. You know success would look like . You know is it the volume of the test? Is the cost of owning those volume of the tests? And is if the cost of maintaining all of that? So I think a lot of our clients are benefiting by thinking from that perspective and all the details are just basically implementation.
- So what are you working on releasing a FREE version of Test Architect we are doing a couple of things. The first thing we are doing is restructuring the licensing model. We used to have the professional model for testing Web & Windows and then the mobile version which is testing WEB, Windows, Droid and iOS. And then the enterprise version with this has all those features plus some other distributed testing feature. Now we just did away with all of that. We just have one enterprise version would be a paid version and then we also offer a freemium version which has full features of the enterprise version except there's a limitation on the number of test cases. Which is about 100 test. So we offered two node locks and 100 test as a freemium. So the thinking behind that is number one is if someone need an alternative to open source then we offering something that easy to work with for non programming staff And as I have described already Our Test architect or we designed for easy to maintain and to scale to larger test assets as the business grows. And is this free. And also the other thing thing is we want to deliver. We want to think upcast architect like an industry create automation solutions for teams. And in that we embedded the method and the management in the product and we want to offer that free to you know small business small development teams and the philosophy behind that is we want everyone to be able to automate. Nobody would be left behind and we want to deliver a complex automation that things simplify accessible for all.
- I think the one advice I have is anyone about automation. I will go back and say it again about something I researched which is transferability. Test Automation today regardless of whether you're going to use Selenium or Unified Functional Test, or you're going to you Test Architect. Think about you build a test that will be executed. Or maybe not now but in the near future we'll be executed by somebody else then that person should be able to analyze your tests. Should be able to analyze your results. And should be able to maintain your task and maintain your results. I love to be you know 20 years ago. I want I like automation because like I saw the developers got beaten up with that code But with the automation engineers they could do anything. They never had to worry about it. Now that's changing. So I think transferability requires transparency in the way you design tests. And also think about the business. Really at the end of the day automation is being in the forefront right now because people are seeing it as a business benefit. It's a business solution to compete. Right. So therefore think about your building your test asset as part of the business. It's not about writing code it's not about anything other than you are now part of the business solution.
Resources
Connect with Hung Q. Nguyen
- Twitter: @myswtestinglife
- Blog: LogiGear Magazine
- Company: LogiGear
- LinkedIn: hung-nguyen-1ba79
May I Ask You For a Favor?
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.
Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!
