ZAPTEST’s API testing functionality provides support for SOAP, REST, WSDL, WADL, XML, JSON and other web service technologies. It allows creation of functional tests with combined UI and API steps. ZAPTEST API Studio component provides for request parameterization, authentication, header customization, adding XML namespaces, attachments, and defining advanced response validation. The existing ZAPTEST functionality has the ability to enable UI and API distributed or parallel test execution, and integration with major CI and ALM platforms.
"We are very excited about the new ZAPTEST API testing! Today with the release of the API testing functionality, we will be offering ZAPTEST users the flexibility of testing API Web Services stand alone or integrated with UI testing within the same test procedure. This advances ZAPTEST as a market leader being able to automate any software application, meet any development schedule, and to accommodate any QA and development team skill sets," said Alex Chernyak, ZAPTEST Founder and CTO.
ZAPTEST Free edition download and the self-education tutorials are available at: ZAPTEST Free Edition Download Page
ZAPTEST helps Enterprises to achieve testing ROI over 10X!
Testing is an overhead! However, any organization that drives business digitally can’t afford to release poor quality software. Development-driven testing doesn’t offer quality testing; there are still quality gaps that result in the loss of customers and revenue. Software must be tested by Quality Assurance professionals! The Quality Assurance process needs to allow Enterprises to perform testing just in time and it needs to be cost efficient.
Traditional software Quality Assurance is the long process. It usually starts with test documentation (manual test cases) development that takes about 30-40% of the overall QA time, than manual test cases are passed to test automation (when used). Test Automation takes another 40-50% of the time. And after all QA teams perform test execution the remaining 10-30% of the time is used.
Traditional QA process is long! It requires multiple people and many man-hours. Specifically, typical test automation technologies that are available for QAs are either API, Image, or HTML-tag based object recognition type and require Application Under Test (AUT) to be present for the automation. Another problem is lack of these tools for cross-platform testing, and therefore it requires development of test artifacts per testing environment that result in multiplication of the test artifacts (development and maintenance) to test given business processes. Also, test execution using these technologies is per platform; that requires each batch of tests to run on the particular testing environment at the time (sequential), and therefore prolongs time for AUT go to market.
All these factors make Quality Assurance of the modern Software Development Life Cycle (SDLC) very expensive!!!
I have suspected for some time that Agile Development is bragged about but rarely achieved. I confirmed this at StarEast when I spoke to over 200 testing professionals. Almost without exception, I was told that testing in Agile was being executed two ways:
- At the end of The Sprint or in reality Mini Waterfall
- In The Following Sprint or guaranteed production error mode
While this is not surprising, it is cause for alarm. Testing at the end of The Sprint carries all of the coverage issues and time constraints associated with The Waterfall SDLC and adds the compounding negative effects of biweekly or weekly iterative test crunches. The result is poor coverage and QA burnout. As a consequence, applications will suffer quality issues and delays. I can safely say that the QA professionals living under this regimen are miserable. Worse still, application quality is being assured by the developers’ unit testing instead of QA. Let's just give The Fox the Hen House.
Delaying testing until The Following Sprint is a recipe for disaster. In a small shop it guarantees production errors and rework. In Scaled Agile it's much worse. Not only are post release issues guaranteed but also one error can halt the work of multiple teams with shared dependencies. In a large organization with upwards of 50 teams the impact is devastating both in time and cost. In many cases errors are swept under the rug and dumped into production or passed on to The Next Sprint. The result is technical debt and spotty quality at best. This is clearly unsustainable.
Mini Waterfall and Post Sprint Testing are symptoms of relying on antiquated tools. Most of the tools on the market rely on API calls to existing code. This requires QA teams to wait for the code to exist before creating test cases. Theoretically, a test automation scripter could write test cases every time code is checked in but, as we all know, this is rare. Simply put, QA can't afford to wait for the code to be written. With API and DLL dependent tools QA is destined to fail.
- Mission of Quality Assurance in the development process is to assure quality of software based on the application requirements given by the Business
- Quality Assurance is performed by executing test procedures (Test Cases) based on the application under test (AUT) requirements throughout the given software
- Test Cases designed by Quality Assurance teams (QA) have to mimic the end-user (human) actions through business processes of the given AUT
- Quality Assurance has to represent both, the end-user and the Business
Quality Assurance has to control quality of software applications developed by Application Developers (Devs)!
- QAs have to test applications prior to the applications release
- Applications have to be tested on multiple platforms and environments (Operating systems, combinations of browsers, native mobile apps, hybrid apps etc.) where the end-users will be accessing those applications
- Average allocated QA time in the software development process is short, 10%-30% of the SDLC
- Manual testing is a lengthy initiative, especially considering multiplying test executions per environment
- IT Executives (Execs) would like for QAs to expedite testing
- Test Automation allows to speed up test execution
QA testing should be automated!
- Test automation is the lengthy process (sort of mini software development process)
- Current test automation technologies (tools) allowscript development based on the existing application GUI (AUT has to exist at the time of test automation)
- Many QAs are required to support Agile/DevOps with short development cycles (1-2 weeks)
- QAs don’t have enough time to develop automated testing and to execute it just-in-time (JIT)
- Execs are losing patience for QAs
QA testing should be performed Just-in-Time!
- QAs would like to start test automation earlier (before the AUT is created)
- Many of them are trying to use tools in an alternative way, they are teaming up with Devs to get AUT GUI object parameters (property values) in advance, so they can build test scripts (scripts) before the AUT is created
- QAs are orienting testing towards Devs objects (not AUT Business requirements)
- Devs control the QAs
Execs are outsourcing testing leadership to Devs!
- Devs are leading QAs to test dev requirements (not Business requirements)
- QA Testing is losing focus
- Quality of software is jeopardized…
QAs are pleasing Devs!