We’ve recently added some new articles to our knowledgebase and updated other articles with information you may want to check out.
QA Wizard Pro 2013.1 was recently released and we made some documentation updates you may want to check out to learn about new features and enhancements.
Remember, documentation is available on our web site and from the Help menu in QA Wizard Pro. If you have documentation suggestions, please let us know.
Bart Honing, Quality House
This is a guest post from Bart Honing of Quality House. Bart has been working for over 7 years in the field of testing, from developing and implementing test cases to test management in various industries ranging from banking to government.
Since I started off as a software developer, I have a tendency to dive into figuring out how the black box actually works on the inside. This attitude can be of good use when working on test analyses and test execution. But, when starting off on a project aimed at integrating black box components, it can be a challenge to focus on the interfaces instead of the logic within the box. With the increasing complexity of software and the desire to integrate services, black box testing—or system testing—is far from obsolete.
There has been a lot of angst in the testing blogosphere lately on the value of the skills and results that experienced testers bring to a project. For examples, see Pete Walen, Bruce Rennie (this is a very long thread, and may require LinkedIn login), and Keith Klain. All rail against a seemingly growing sentiment within software organizations that testing—especially on-site, experienced, manual testing—adds little value to the task of delivering software to the business.
Most testers who write about this topic painstakingly attempt to define how testers explore software to determine how it works and where the biggest risks lay; and work with the user community to understand how they work and which actual or potential features are most important to them in their work. Testing legend James Bach has been one of the longtime proponents of the thinking tester, and the thinking tester was the theme of last year’s CAST Conference.
I spend a lot of time working with customers and prospective customers on automated testing requirements. Often, people are looking for a quick way to automate everything they have, but this is rarely a good idea. To automate 100% of your testing is not realistic, but automating time-consuming tasks makes loads of sense.
When testing web applications using QA Wizard Pro, you sometimes run into applications that use a large amount of Ajax/JavaScript script to enforce certain rules on fields, etc. This is normal and really does make things easier for the end user. However, these situations add to the complexity of automated testing.
As a technical writer, I write a variety of documents on any given day. I enjoy the variety of writing tasks that come with my job, for the most part, but writing defects is not something I like to spend a lot of time on. (Come on, who really likes writing defects?) So when I do stumble upon a product defect I need to share with our development team, instead of cursing to myself and pretending I didn’t see it, I can just let Defect Scribe explain the issue for me.
The problem I have with writing defects is I’m not always sure if I’m including all the information our developers need to understand and fix the specific problem. When I use Defect Scribe to record the actions I performed to come across the issue, I don’t have to worry about keeping track of so many details. The results have everything I need to submit a thorough defect record in our TestTrack database. I just need to take a little time reviewing the results, adding any notes I feel might be helpful, and then I can create the defect right from Defect Scribe.
But why stop at submitting defects? Here are a few other writing tasks I’ve found I can use Defect Scribe to accomplish.
We offer tools to help developers and testers work more efficiently and deliver working software to their customers more frequently.
