Technical FAQs for "PrizmDoc Viewer"

Implementing specialized viewing technology saves time and resources during the development process so FinTechs can get their products to market faster. By selecting the right integration partner from the beginning, they can put themselves in a position to scale capabilities in the future without suffering unexpected costs or compromising performance. 

Viewing Integrations and the Problem of Scale

FinTech developers often turn to API-based viewing integrations like Accusoft’s PrizmDoc because they provide the tremendous power and flexibility that modern financial services applications require. Whether it’s file conversion, robust annotation, document assembly, or redaction, FinTech software must be able to provide extensive document processing features to meet customer expectations.  

In order to implement those advanced viewing capabilities, the developer usually needs to set up a dedicated server as part of their on-premises infrastructure or in a cloud deployment. One of the biggest advantages of API-based integrations is that customers only have to pay for the processing resources they use, but this can also pose some challenges when it comes to scaling application capacity. 

As FinTech companies expand their services, they need to be able to deliver document viewing capabilities to a larger number of users. If each viewing session requires the server to prepare and render documents for viewing, costs can quickly escalate. As server workloads increase, viewing responsiveness may be affected, resulting in delays and slower performance. 

While some users may still need to use server-based viewing to access more powerful imaging and conversion features, many customers simply need a quick and easy way to view and make minor document alterations. FinTech developers need a versatile solution that can meet both requirements if they want to scale their services smoothly. 

Introducing PrizmDoc Hybrid Viewing

PrizmDoc’s new Hybrid Viewing feature provides FinTech applications the best of both worlds by offloading the document processing workloads required for viewing to client-side devices. Rather than using server resources to convert files into SVG format and render them for display, Hybrid Viewing instead converts files into PDF format and then delivers that document to the end user’s browser for viewing.  

Shifting the bulk of document processing work to client-side devices significantly reduces server workloads, which translates into lower costs for FinTech applications. 

For documents not already in PDF format, the PrizmDoc Hybrid Viewing feature offers new PDF viewing packages that pre-convert documents into PDF for fast, responsive local viewing. 

By reducing the server requirements for rendering files, FinTech providers can easily scale their applications without worrying about additional users increasing their document processing costs. PrizmDoc Hybrid Viewing also eliminates the need for separate viewing solutions implemented to work around server-based viewing, which allows developers to streamline their tech stack and further optimize customer experiences. 

5 Ways Hybrid Viewing Enhances FinTech Applications

PrizmDoc’s Hybrid Viewing feature provides FinTech developers with several important benefits that improve application flexibility and deliver greater value to their customers.  

1. Resource Savings 

Hybrid Viewing minimizes server loads by offloading the bulk of the processing required to view a document to client-side devices. Reducing server requirements translates into lower costs and frees up valuable processing resources for other critical FinTech workloads. 

2. Scalable Viewing 

Shifting the processing work required for viewing to local devices allows FinTech applications to scale their user base with minimal cost. 

3. Enhanced Performance 

Offloading document preparation to the end user’s device improves viewing speed and responsiveness, especially for large documents. 

4. Increased Productivity 

Diverting workloads to client-side devices allows application users to process, view, and manage multiple documents faster. FinTech developers can leverage Hybrid Viewing to provide a better user experience that helps their customers to be more efficient and productive. 

5. Improved Storage Management 

For documents not already in PDF format, Hybrid Viewing can utilize PDF-based viewing packages that are significantly smaller than conventional SVG viewing files. Files can be pre-converted for fast, easy viewing without taking up extra storage space. 

Enhance FinTech Applications with PrizmDoc Hybrid Viewing 

PrizmDoc’s new Hybrid Viewing feature allows FinTech developers to seamlessly scale their application’s viewing capabilities without having to deploy new servers or rethink their cost structure. Shifting document processing to local devices provides end-users with faster, more responsive performance, especially when viewing lengthy documents. By keeping viewing-related costs low, FinTech developers can focus their resources on developing new application features that help their products stand out in an increasingly competitive market. 

To learn more about how PrizmDoc’s Hybrid Viewing can benefit your FinTech application, talk to one of Accusoft’s PrizmDoc specialists today.

Most software developers turn to third party integrations like Accusoft’s PrizmDoc to incorporate document processing capabilities into their applications. Since developers are frequently pressed for time and resources, it doesn’t make sense to build document lifecycle features from scratch when they can easily deploy a proven, scalable solution that provides all the tools they need. An API-based integration like PrizmDoc can quickly add industry-leading viewing, editing, collaboration, conversion, and assembly features to an application, which allows developers to focus on other features that will help their software stand out from competitors.

Pros and Cons of Server-Side Viewing

All that document processing power has to come from somewhere, and in the case of solutions like PrizmDoc, most processing is handled by a dedicated server. The server may be self-hosted on the developer’s local infrastructure, a dedicated private cloud, or a public cloud that’s shared by multiple customers.

There are plenty of advantages to this model. Scalable infrastructure is available for the heaviest document processing workloads, but customers only have to pay for the resources they actually use. A dedicated server also makes it easy for applications to manage document storage and avoid version confusion.

Server-side resources can also pose challenges for some applications. If the server is constantly being used to prepare and render documents for viewing, customers may find themselves utilizing more processing resources than expected. Scaling viewing capabilities for multiple users can increase resource usage because each session places additional processing requirements on the server, especially if users need to make annotations, redactions, or other alterations to files.

Viewing multiple, lengthy files server-side can also impact performance. PrizmDoc’s HTML5 viewer, for instance, converts and renders documents in SVG format. While this format offers outstanding quality and flexibility, load time may take longer and it also takes up server storage space.

Introducing PrizmDoc Hybrid Viewing

The new PrizmDoc Hybrid Viewing feature solves these challenges by offloading the processing work for viewing in PDF format to the end user’s device. This is a hybrid approach between server-side processing and client-side processing, with all of the viewing capabilities handled by the client-side device. This drastically reduces the server resources needed to prepare files for viewing, which translates into cost saving and improved performance. Since all viewing is handled by the browser on the client-side device, Hybrid Viewing offers much greater responsiveness for a better overall user experience.

For files not already in PDF format users can take advantage of the new viewing package which converts any file format to PDF. This not only allows documents to be viewed more quickly in the future, but also reduces server load and storage requirements.

5 Key Benefits of PrizmDoc Hybrid Viewing

The Hybrid Viewing feature works within PrizmDoc’s existing viewing package infrastructure, making it a simple and streamlined solution for both new and existing customers. Shifting viewing processing from the server to client-side devices provides applications with several important benefits.

1. Cost Savings

Transferring the processing work required for document viewing to an end user’s device reduces server workloads. Since customers pay for the server resources their applications utilize, minimizing server requirements for viewing can deliver significant cost savings over time.

2. Better Resource Management

All file types can be used with this new Hybrid Viewing feature. The new PDF viewing package pre-converts all file types into PDF only, rather than creating SVG files with large amounts of data. This saves both processing time and storage resources. Developers can take advantage of this flexibility and resource savings to implement additional application features that leverage PrizmDoc’s capabilities.

3. Increased Productivity

Shifting document viewing workloads to client-side devices allows applications to process, view, and manage multiple documents faster. This helps end users to do their jobs more efficiently and get greater value out of their applications.

4. Enhanced Performance

Hybrid viewing not only requires fewer resources, but files can be viewed and manipulated faster with enhanced responsiveness. For applications that need to provide editing features such as annotations, offloading processing to client-side devices minimizes load times and lag for a better overall user experience.

5. Scalable Document Viewing

By handling document viewing capabilities on local devices instead of the server, scaling capacity becomes far less resource intensive. File conversion only needs to be performed once, so adding more users doesn’t increase the overall server workload.

What Hybrid Viewing Means for PrizmDoc Users

The new Hybrid Viewing feature allows PrizmDoc users to get more out of their integration than ever before. For customers who have long relied on desktop-based PDF.js viewers due to concerns about server workload or performance, the Hybrid Viewing feature provides a localized viewing solution that streamlines their tech stack and leverages the full capabilities of PrizmDoc. By minimizing server requirements, developers can unlock the potential of their applications to scale their document lifecycle features without worrying of runaway costs.

Hybrid Viewing is available for PrizmDoc Server v13.15 or greater and can be used for self-hosted, private cloud-hosted, or public cloud-hosted deployments. To learn more about how it can provide the flexibility your application needs to scale with user demands, talk to one of our PrizmDoc specialists today.

Data privacy continues to be a significant concern for businesses, employees, customers, and stakeholders alike. Privacy breaches can expose problems with document management and digital document security practices. They can also pose significant risks and costs to companies and stakeholders.  The importance of ensuring the secure sharing of confidential documents can’t be stressed enough.

When developing an application with SDKs or APIs or integrating new features into a workflow, developers must be aware of the security risks. Project managers, security engineers, and architects must work in tandem to identify and address all potential security breaches. This holds especially true for commercially-confidential, highly-sensitive, or private documents while in transit.

The Risks of Document Sharing

Document sharing, in general, can present opportunities for malicious actors to attempt to gain access to a competitor’s documents. It could also pave the way for uploading data containing malware accidentally. Protecting the enterprise as a whole should be a priority to prevent loss or compromise of customer-sensitive information. This is vital because even minor damage to a company’s reputation can have a devastating impact. 

When building applications with document sharing capabilities, developers need to think about the inherent risks that come along with allowing users access to upload and edit documents. Fortunately, there are a number of practical steps that developers can take to share sensitive documents securely without putting confidential information or mission-critical data at risk. 

5 Ways to Ensure Confidential Documents Are Shared Securely

1. Strengthen Application Security

Any conversation about document security needs to start with a focus on the application’s cybersecurity architecture. If document management software contains multiple vulnerabilities or doesn’t provide the necessary controls to safeguard data, it will be difficult to share sensitive documents securely. Here are a few best practices developers should have in place to create a secure application ecosystem: 

• Perform threat-modeling any time there is a major design change in the application or ecosystem to identify potential new threats.
• Encrypt customer sensitive documents both in transit and in storage. Ideally, the keys will be held by clients with an emergency access vault backup system, so that even the software developer cannot access any sensitive customer data. This way, even if an application or data centers are breached, customer documents will still be protected.
• Spend more time testing releases for weaknesses and allow security engineers and architects to weigh in on the product feature roadmap. Security patches and improvements should be given the same value as other new product features.
• Conduct periodic audits or external penetration testing to ensure that applications and customer data cannot be compromised.

2. Design Applications with Segregated Access

Secure documents and sensitive information should only be available to the people authorized to view or edit it. Access to one document should not allow someone to access other documents stored in the same application. By segregating access to data and assigning specific user permissions, developers can provide the tools customers need to manage their assets and share sensitive documents securely.

3. Eliminate External Viewing Dependencies

Although many organizations use secure applications to manage their document workflows, they frequently open themselves up to risk by relying on external software for document viewing. Without some way of sharing and viewing documents within the application itself, files will inevitably be shared over email and opened on local devices that may not have the latest security updates in place. Developers can avoid this problem by integrating HTML5 viewing capabilities into their application. This ensures that documents never have to leave a secure environment, even when they’re being shared with people outside an organization.

4. Create Unique Viewing Sessions

One of the challenges with many cloud-based document management systems is that once someone is granted access to a file, they typically retain that access until it is manually changed at a later date. In most instances, those privileges are also associated with the source file itself. This can create a number of security gaps if an organization doesn’t closely monitor access privileges. By implementing an HTML5 viewer that can generate unique viewing sessions for individual users, developers can provide more control over how to share confidential documents. Viewing sessions can be set to expire after use, and since the session is viewing a rendered version of the document instead of the source document itself, system administrators have more control over what aspects of it are shared. They may decide, for instance, to share only certain pages rather than the entire document.

5. Implement Redaction Capabilities

Redaction has long been used to protect private or confidential information in documents. Although organizations still frequently make embarrassing mistakes when it comes to redaction, it remains one of the most effective tools for anyone who needs to share sensitive documents securely. By integrating true redaction capabilities that not only obscure, but also completely remove sensitive information, developers provide applications that have the ability to screen documents for privacy risks before they’re shared with anyone. Performing redactions within the application environment also has the benefit of further limiting external dependencies that could threaten security.

Protect Confidential Documents with Accusoft Integrations

Accusoft’s collection of processing integrations give developers with a variety of document management tools for controlling privacy within their applications. The HTML5 capabilities of PrizmDoc Viewer offer powerful redaction tools and make it easier for administrators to control viewing access. 

To learn more about how Accusoft SDKs and APIs can provide the document management features you need to protect confidential information and privacy, visit our products page today or talk to one of our integration specialists.

Technology trends are moving quickly in the legal industry as firms scramble to adapt to a shifting business landscape. Although many firms and organizations were already taking steps to break away from old fashioned processes and embrace the potential of LegalTech solutions, the COVID-19 pandemic has accelerated change initiatives and forced legal professionals to reassess their foundational business models. To get a better sense of the technology impact on law firms, developers would be wise to review recent tech surveys of the industry that assess how LegalTech software is being utilized.

LegalTech Technology Survey: A Closer Look 

According to a 2020 technology survey conducted by Bloomberg Law, legal firms are seeing tremendous benefits from the implementation of LegalTech tools. Four out of five firms and 73 percent of corporate legal departments have seen an increase in work volume, with both reporting that technology has also improved the quality of their work. On balance, high-value tasks are getting more attention, with 56 percent of respondents indicating that they spend at least somewhat more time on higher-level tasks. Low-value task loads have been reduced by an even larger rate, with 73% of respondents spending at least somewhat less time on less skilled, lower-level tasks.

Critically, these improvements seem to have come without also introducing a new set of challenges. One of the frequently cited concerns about implementing new LegalTech solutions is that it will create workflow disruptions or cause other difficulties with legal processes. In reality, such critiques appear to be largely unwarranted. Bloomberg Law’s 2020 tech survey found that large majorities of respondents did not believe LegalTech added to the number (78 percent) or difficulty (86 percent) of workflow impediments.

LegalTech Automation Needs

Despite the positive technology impact on firms, there are still many tasks being done manually that could be automated with software tools. In 2020, Accusoft conducted a technology survey of legal professionals about how they’re managing productivity and utilizing LegalTech applications. We discovered that while 54 percent of respondents were utilizing digital solutions to view and collaborate on documents, automation tools had yet to eradicate time-consuming manual tasks.

The Technology Impact on Law Firms in Business Terms

Failing to implement effective LegalTech tools, then, could very well be costing many firms business. Longstanding legal business models that focus on profit per partner (PEP) metrics and emphasize short-term priorities are already giving way to technology-driven models that deliver faster, more efficient services at more competitive price points for customers. While boutique “big law” firms may continue to resist automation trends due to the specialized and strategic nature of their business, smaller firms and legal departments will need to reorient their operations to deliver the routine, day-to-day services that most customers are seeking. 

Perhaps unsurprisingly, the COVID-19 pandemic has made many legal organizations more open to adopting technology solutions. Bloomberg Law’s report found that prior to 2020, only 40 percent of legal leaders described themselves as being “very open” to implementing new tech. Following the pandemic, that number has increased to 54 percent, perhaps acknowledging a new reality for the legal industry as existing business models are reconsidered.

Building the Future of LegalTech

LegalTech developers face several challenges as they work on designing the next generation of technology solutions for the industry. The first question almost always comes down to whether it makes sense to build application features from scratch or to buy and integrate proven solutions. Many legal organizations are looking for powerful software tools that incorporate the latest in process automation technology, which often demands substantial development resources to build and implement. For many software developers, it can be difficult to get products to market quickly without cutting some corners here and there in terms of features when they have to build everything from the ground up.

By incorporating ready-made functionality in the form of specialized integrations, developers can dedicate more of their resources to the innovative technology that powers their LegalTech solution. From HTML5 viewing that makes it easy to securely view a variety of file types to collaboration tools that allow for markup and redaction, software integrations can rapidly expand the capabilities of an application to make it more attractive to legal organizations.

Accusoft’s PrizmDoc Viewer allows developers to integrate versatile viewing and conversion functionality into their LegalTech solutions. It also features powerful annotation and redaction tools that can significantly streamline the eDiscovery process. Learn more about these and other solutions in our LegalTech Fact Sheet.

When it comes to your company’s application landscape, there are a variety of tools you already use to streamline processes. But do these tools help you manage your workloads efficiently? Document management is essential to any business. Many companies try to buy a solution and integrate it into their current processes, or build one from the ground up themselves. However, assigning developers to build, test, and maintain your own software isn’t efficient, agile, or advisable.

The other option isn’t really ideal, either. You’ll spend more of your IT budget on applications which are bloated with functionality you don’t need now, and likely never will. That also means investing in applications that lack flexible workflow structure or possibly limiting features and functionalities like advanced search.

The Value of Integration

Business executives are constantly bombarded with new technology alternatives. But before spending your budget on that new, shiny gadget, make sure you consider the more cost-effective, efficient alternative. Did you know that you can integrate SDKs and APIs into your current application to create a better document management process?

Using purpose-built APIs or SDKs for document viewing, OCR, barcoding, data capture, and conversion helps a business achieve important goals for any organization. With these integrations you can:

• Meet compliance requirements
• Provide context to structured data
• Ensure that individuals have permission-based access to sensitive data
• Foster collaboration across departments, clients, partners and other stakeholders
• Make content discoverable through full-text search
• Enable file viewing within your own application without opening a third party software

When an end-user is working within a CRM application, they often need to access a document that relates to a campaign, a datasheet that provides crucial information, or a contract which needs to be renewed. APIs create efficiencies by allowing for documents to be accessed by a user without having to switch from screen to screen.

Work Smarter, Not Harder

Your development team or application consulting partner could likely build this sort of functionality over time, just like you could have walked to work every day this week. You get the picture. It would take hours of wasted time to create a functionality that is only half the solution available elsewhere.

Luckily there’s a way to get the document management functions you need, and price pales in comparison to a DIY build. This alternative is highly competitive with other solutions in the market, yet it’s available without the expensive price tag of a stand-alone SaaS solution.

Accusoft’s portfolio of APIs and SDKs support the kinds of .NET, Java, C/C++, Node.js, and more application languages. Products like PrizmDoc Viewer, ImageGear, and OnTask help you obtain the features and functionalities you really need without the price of the ones you don’t.

You can even test drive what you need for a few days before you invest in it. If your team could build, test, and maintain something that meets your needs more efficiently, at a lower cost, why wouldn’t you jump on it?

Need more information on integrating toolkits instead of building your own solution? Download our eGuide Document Management – The First Step to Digital Transformation today. You’ll be glad you did.

Written by: Cody Owens

• • How quickly can your team take a code base, package it, test it, and put it into the hands of your customers?

• • Can you push a button to automagically make it happen?

• And, once your customers have your product, can you be confident that it will work for them out of the box?

We at the Accusoft PrizmDoc group asked ourselves those questions in 2016 and discovered a wide array of opportunities to improve how we deliver our product.

Here we share how we reduced our feedback cycle from three months to three days, enabling rapid delivery of beta PrizmDoc builds and confident, seamless delivery of release builds.

What is Continuous Delivery?

Continuous Delivery, the movement toward rapid working releases, focuses our efforts on knowing as quickly as possible when to release a change to customers. Whereas Continuous Integration focuses on taking code and packaging it, Continuous Delivery goes a step further by identifying what to do with that package before release.

A common assumption is that when code works in one environment, it should work in others. But through the lens of Continuous Delivery, we have to assume our product is guilty until proven innocent. And how do we prove its innocence? Automated testing in production-like environments. In this way, we can be confident that at release time our product won’t explode on takeoff.

Moving from testing on a small, dedicated environment to a many production-like environments can be complex. But implementing a Continuous Delivery release workflow is well worth the effort. The product will be deployable throughout its lifecycle. Everyone – not just the development team – can get automated feedback on production readiness at any time. Any version of the product can deploy to any environment on demand. And in our case, beta builds can release to customers for early feedback on bug fixes and new features. Together, we realized that these benefits far outweigh the cost of putting up with release pain year after year.

Evaluating Our Starting Point

Like most modern software teams, we believe in the value of test-driven development. We already had many thousands of unit, contract, and integration tests verifying the ability of our products to solve business needs. So, we could be confident that the product could run on some specific environment with some specific configuration. But there were a few key problems we had to address:

• Spawning many production-like environments was uneconomical
• We could not automatically test the GUI of our product
• There were no explicit, automated performance tests against business-valued behaviors

Testing On Realistic Environments

We tackled the expense of production-like environments first. At the time, we were using Amazon Web Services EC2 instances for build agents that could test and package code. On each code change, new instances launched to run tests. While these instances were fast, reliable and cloud-based, they were uneconomical. And because spending gobs of money is effortless when spawning instances for testing or development, access was guarded. Reevaluating our needs, we realized that scalability or flexibility of the cloud wasn’t necessary for testing purposes. We knew we needed to shut off the cloud-hosted cash vacuum – but what was our alternative?

Hybrid cloud is becoming attractive as a best-of-both-worlds solution to cloud-hosting needs. Perhaps a more accurate term is “local cloud hosting” – on-prem value but with most of the features offered by the “real” cloud. To this end, we turned to OpenStack as our EC2 replacement for development builds. With OpenStack, we can still spin up instances, store VM images and snapshots, create load balancers and more without the cost associated with the cloud. A single investment in the local hardware was comparable in cost to one additional year of cloud usage. If it didn’t turn out so well, we could just switch back a year later.

After flipping the switch, we transferred our build agents to OpenStack’s hybrid cloud. Before, some tests took many hours and could only run once per day or even once per week. But with the reduction in testing costs, we now run the dailies at every commit and the weeklies every day. This difference in feedback time is monumental; developers can be confident that their new code won’t fail automated tests a week later after the user story has closed.

As we increased our hybrid cloud test agent workload, we ran into a unique problem. As opposed to running instances in the “real” cloud, we now have to deal with hardware limitations. We have a specific number of physical CPUs available. We have a specific amount of memory to use. This forced us to rethink what tests we ran and how we ran them.

Failing Fast, Failing Cheap

To optimize our resource usage, we need bad commits or configuration changes to fail fast and early. When one stage fails, the next stage(s) shouldn’t run because that build isn’t releasable. We needed a way to schedule, chain and gate test suites.

Enter Jenkins. Jenkins is a flexible build system that enables a simple pipeline-as-code setup for all sorts of purposes. In our case, we opt to use it as the platform that pulls the built product installer, installs it and runs batteries of progressively stringent tests against it. A stage can run tests against multiple nodes. We created production-like nodes that launch from our hybrid cloud and use the built-in gating functionality in Jenkins. Subsequent test stages don’t run following a test failure. Since pipelines are version controlled, we always know exactly what changes affect a given run.

Testing Like A User

By this point, our tests can run inexpensively and easily across production-like environments. This enabled us to rethink what tests we were running and build upon our coverage. At release time, we spent a sprint across two teams just to test deploying the product and pushing buttons to verify the GUI worked. The plain English test instructions were subject to interpretation by the tester, leading to nondeterministic results from release to release. This cumbersome effort was necessary to test the GUI sitting on top of our core API product.

While this manual testing process uncovered bugs nearly every release, it was unthinkable in terms of ROI per man-hour. The late feedback cycle made product GUI changes stressful. A developer might not know that the GUI component they just added is unusable on an Android device running Firefox until the release testing phase three months later. Finding bugs at release time is dangerous, as not all bugs are always resolved before the release deadline. Regressions and bugs might make their way into the product if they’re not severe, or they might postpone delivery of the product altogether.

Automating these types of manual tests improves morale, reduces feedback time and asserts that the GUI either passes or fails tests in a deterministic way. Furthermore, it opens a route to Behavior Driven Development language that centers around business-valued behaviors on the front end of the product. For instance, we use the Gherkin domain-specific language to author tests in plain English that are parseable by a testing code base into real executed test code. Non-technical members of the team can author plain English “Given [state of the product], When I [do a thing], Then [a result occurs]” feature descriptions that map 1:1 to test code.

Today, all major browsers have automation REST APIs to enable driving them in a native non-JavaScript way without a real user. To eliminate the hassle of changing test code between browsers or authoring reliable tools to talk to those automation APIs, we use Selenium WebDriver. WebDriver is available in many popular languages including Java, Python, Ruby, C#, JavaScript, Perl and PHP.
From BDD test code, we execute end-user tests with WebDriver to verify real usage of the product. Because the WebDriver APIs enable “real” user events and not JavaScript event simulations, we can be confident that mouse, touch and keyboard actions actually do what we expect across a range of platforms. On test failures, we take a screenshot and save network traffic logs from the browser to trace the failure back to a front end or microservice source. Some test authors even automatically save a video of the last X seconds leading up to the failure to investigate unexpected, hard-to-reproduce behavior.

Altogether, these new front-end tests enable us to supplant the rote work of fiddling with the product across different browsers and devices for each release. They give us rapid feedback for every commit that the product has not broken for a front-end user. Before, we couldn’t know until release testing. Development confidence goes way up and agility improves as we can guarantee that we won’t have to interrupt the next sprint to fix an issue introduced by new code.

The Value Of Manual Tests

This is not to say that manual testing should be supplanted by automated testing. Exploratory testing is necessary to cover complicated scenarios, unusual user behaviors and platforms that automated tests don’t cover. Not everything is worth the time investment of automating. Bugs found during exploratory tests can be fixed and later covered by automated tests.

Your product’s test coverage should look like a pyramid where unit test coverage is thorough, integration tests are somewhere in the middle, and product-level end user tests are broad but not deep.

As expensive as manual testing can be, authoring and maintaining end-user tests can be expensive if done poorly. Changes to the front-end of the product can break all the GUI tests, though using the Page Object design pattern can mitigate this. Browser updates can also break end-user tests. Poor product performance can lead to unexpected behavior, resulting in failed tests. And not all browser platforms support all parts of the WebDriver spec, resulting in edge cases where JavaScript does need to be run on the page on that platform to fill in the gap.

Keep end-user tests broad and don’t use them as a replacement for in-depth, maintainable integration and unit tests. If a feature is testable at the unit or integration level, test it there!
On the PrizmDoc team, we’ve freed up weeks of regression testing time at release through adding these end-user automation tests. After cursory end-user regression tests, we host a fun exploratory Bug Hunt with prizes and awards.

Who can find the most obscure bug? The worst performance bug? Who can find the most bugs using the product on an iPad? Your team can gear testing efforts towards whatever components are most important to your customers and raise the bar on quality across the board.

Automating Nonfunctional Tests

Performance and security, among other nonfunctional requirements, can be just as important to our customers as the features they’ve requested. Let’s imagine our product is a car. We know that the built car has all the parts required during assembly. We also know that the car can start up, drive, slow down, turn and more.

But we don’t know how fast it can go. Would you buy a car that can only go 20 MPH? What if the car didn’t have door locks? These concerns apply similarly to our software products.

The next step, then, is to automate tests for nonfunctional requirements. Even one bad commit or configuration change can make the product unacceptably slow or vulnerable. So far, we have added automated performance tests using Multi-Mechanize. Many similar tools can accomplish this task so there’s no need to dive into details, but the key point is configurability.

Our customers don’t all use the same hardware, so it doesn’t make sense to test on every possible environment. Instead, we focus on measuring performance over time in a subset of production-like environments. If performance goes below a particular threshold, the test fails. With configurability in mind, if a customer is evaluating whether to use PrizmDoc, we can simply deploy to a similar environment (CPUs, memory, OS type, license, etc) and gather metrics that will allow them to easily plan capacity and costs, which can often seal the deal.

And since performance tests run on every successful change, we can gauge the impact of optimizations. For example, we found that a microservice handled only two concurrent requests at a time. The fix? A one-line change to a configuration parameter. Without regular performance tests, gathering comparative performance and stability would be difficult. With regular performance tests, however, we were confident in the value of the change.

Real Impact

Continuous Delivery has improved every aspect of the PrizmDoc release cycle. Customers praise our rapid turnaround time for hotfixes or beta build requests. We now thoroughly measure the delivery value of each commit. End-user tests verify the GUI and performance tests cover our nonfunctional requirements. The built product automatically deploys to a range of affordable production-like environments. Any member of the product team can get release readiness feedback of the current version at a glance. Instead of a three month feedback cycle, developers see comprehensive test results against their changes within a day. The difference in morale has been tremendous.

If your organization is not quite there yet, we challenge you to start the Continuous Delivery conversation with your team. Hopefully our experience has shed light on opportunities for your product to make the jump. You might get there faster than you expect.