Software Warranty & Defect Policy

Black Line recognizes that software developers are human and in spite of significant quality controls being place, system defects that are described in this document may occur. As such, Black Line offers a limited warranty to address system defects that may occur during this time period.

Warranty Terms

  • Black Line’s warranty period is 90 days from the production launch of a system
  • Within this period of time it is the Client’s responsibility to stretch the system and take through its normal pace
  • Black Line’s Warranty extends to the following categories of system defects (see detailed conditions below):
    • Critical/Fatal
    • Reproducible defects
    • UI/Navigational defects
    • Data related
    • Workflow
    • Integration
  • It’s the client’s responsibility to identify and notify Black Line of potential defects within a reasonable period so they can be categorized and addressed appropriately (see categories below for more information).
  • Black Line will leverage the criteria in this document to categorize the defect and determine if they fall into the warranty provisions
  • For non-bugs, or issues a Client identifies as a defect but is actually a non-bug (as defined above), any costs will be communicated and approved with Client before work is performed.

Not Covered in Warranty

  • Integration issues outside the control of Black Line (see Integration section below)
  • Issues arising from on-premise systems (hardware, software, network, etc..) that are outside the control of Black Line
  • Issues related to data converted from legacy systems or integration to other legacy, or not maintained systems

Combating Bugs

  • Black Line employs accepted industry standards for reducing system defects through development practices (methods), toolsets and developer testing
  • To aid in the difficult to find bugs, like intermittent or integration issues, we employ extensive logging and event tracking to provide the data to isolate issues.
  • Testing effectiveness is highly dependent on Black Line diligence and Client involvement

Reasonableness

  • Black Line has a long and deep history of service and software development experience, which has taught us that “reasonableness” is needed with evaluating system defects and warranty issues
  • Black Line’s goal is not to charge more for services, it’s goal is to produce technology that enhances our Client’s lives and is fair to both our Client and Black Line
  • Therefore, we move into every warranty situation with an attitude of reasonableness to address the situation in the most timely and productive manner possible

Bug Categories/Definitions

Bugs, or software defects, can be very difficult to understand and evaluate to the non-technical businessperson. This document is intended to provide some explanation, categorization and clarity of the topic of system defects.  In addition, Black Line’s warranty and policy on system defects to set client expectations on how they are managed.

  • Critical/Fatal
  • UI/Navigation bugs
  • Data related bugs
  • Workflow bugs
  • Integration bugs
  • Browser/Platform bugs

In addition to the above categories, there are other bug related issues to consider.

  • Reproducible bugs
    • These are the easiest bugs to identify as they can be identified by the end user and communicated to the development team with concrete steps to produce
    • This does not automatically mean the bug is easy to address, but makes the software developer’s steps to address much easier.
  • Intermittent bugs
    • These are some of the most difficult bugs to identify as they do not manifest themselves as easily and are not easily reproducible
    • Similar to electric problems on cars, intermittent software bugs are not easy to track down with varying degrees of complexity to track down, reproduce and isolate
    • These type of bugs require a little more diligence on both the software developers and end-users to isolate the conditions that existed when the bug occurred
  • Non-bugs/missed requirements
    • The most often misunderstood/miss-categorized of system issues are “non-bugs”
    • Non-bugs are actually not system defects but are requirements missed, not fully understood or just simply left out of the design process
    • While not comforting to the business owner, or end users of a custom developed system, a missed requirement is not a system defect but a missing area of business (or coding) logic
    • This is an inherent risk associated with any custom software development effort as not every logic/business case can be captured during design/development
    • Business logic, especially if from a mature system, can have logic nuances that were addressed over a period of years and therefore may be too obscure to identify in a first version of a custom system.

Critical/Fatal

A bug that causes a “Fatal” error is one that renders the entire system, or parts of a system, inoperable to the end-user or users of the system.

Examples of fatal bugs:

  • Bugs that have no workaround
  • An entire site is down, no pages load
  • No one can log in to the system
  • Web pages load correctly but display error messages. There is no data on any of the pages
  • Selecting a button, option or menu causes the system to crash each time
  • No one can generate transactions, the system displays an error message every time
  • No data is being pulled in from an external system
  • No one can save any new data

Impact:

Critical bugs usually have a significant impact on business operations depending on the reliance on the system and severity of the bug.  When system functions are rendered inoperable with no workarounds, the impact to a business can be significant.

Possible Causes (not exhaustive):

  • Database Server
    • Database system offline
    • Full disk
    • Database corruption
  • Web server
    • System inoperable
    • Not processing requests
    • Memory or other component failure
  • Internet or Network
    • Unable to reach internet based systems
    • Network/Routing failure
  • Third-party
    • Subscription to third-party service expired
    • Other External system failure (see integration section below)
  • Recent upgrades
    • Infrastructure OS upgrades
    • Software component upgrades rendering core system components inoperable

Response:

  • Immediate attention is needed to assess the source of the failure
  • Typically, a production system experiencing a fatal error points to a significant infrastructure related issue.
  • Resolution times are completely dependent on severity of component failure
  • Cloud-based systems are less susceptible to these sorts of failure because of significant redundancy

UI/Navigation Related Defects

A UI/Navigation is one where a user Interface component does not operate as intended.

Examples of UI/Navigation bugs:

  • A button on a web page does nothing when it is clicked
  • A broken link on a web page (when clicked, the link tries to take you to a page that doesn’t exist, or the link simply does nothing when clicked)
  • Web pages load correctly but there is no data on any of the pages
  • A table displaying data does not load correctly and no data is shown
  • A page does render properly when loaded
  • A page is not properly responsive
  • Clinking on menu items or navigation components does not behave as intended

Impact:

The impact varies between mild, as is the case with a page not rendering properly.  To more severe if a critical system function is not accessible.

Possible causes:

  • Untested areas of the system
  • Not frequently used areas of a system are accessed
  • Adjustments made to graphics files
  • Data content is different than tested or expected
  • New features are added
  • Updates to user interface libraries impact existing controls expectantly

Response:

  • For severe cases, the response is elevated to critical
  • For milder cases, the response coincides with the effectiveness of a workaround

Data Related Bugs

When data that is inserted, updated or outputted in a system is not accurate or not as expected.

Examples of Data related bugs:

  • Data insert, update or delete operations do not work as intended
  • Data validation is not performed as expected leading to inaccurate data being stored
  • Invalidated data causing ripple-effect across other data elements
  • Inserted/Reported calculated data is not accurate
  • Dashboards are inaccurate
  • System generated transactions are not calculating totals properly

Impact:

As with UI bugs, data related bugs can have mild to severe consequences.  A calculated field on a report that is not used much can be mild, a date that impacts critical financial calculations may be critical.

Possible causes:

  • Database schema changes not reflected in associated user entry screens
  • Data validation code not properly scrubbing data before entered in database
  • Calculated field logic not coded accurately
  • Data volume/law of numbers
    • Most significant cause of data related bugs
    • Software systems are uniquely challenged with the ability to test every possible data scenario
    • Software, and business systems in general, typically have significant variation in data characteristics leading to incomplete logic to test those conditions
    • Data “Edge” cases (see edge cases below), that is not accounted for in system coding, error trapping of data validation
    • Transaction volume through a system will eventually expose any defects
  • Lack of sufficient “use case” testing to verify system logic addresses system requirements
  • It is not possible to address every data condition during coding

Response:

  • Research the source data to isolate the “data condition” causing the data bug
  • Adjust program logic to account for the new found “data condition”
  • In some cases, a larger, more systemic data problem may have been uncovered requiring
    • Data remediation for inaccurate data
    • More comprehensive code adjustments or more pervasive solution is needed (across multiple system functions, workflows, etc.)

Adjustments to system testing process to account for new understanding of data

Workflow Related Bugs

Workflow functionality is when data transactions “make their way” through a system in a series of steps and sub-steps.  Workflow functionality is highly reliant on data conditions, or end-user input, to move through workflow processes.

Examples of workflow related bugs:

  • Timing errors, where a workflow task is out of the intended order of the business operation
  • System action is not taken based on specific steps in the defined workflow steps
    • An email notification does not get sent in all cases when an event is triggered
    • An auto-generated transaction does not always get generated as defined
  • Logic to move a transaction from one workflow step to another not always working

Impact:

Workflow bugs can range from the annoying (a notification is not sent as expected) to the severe where non-digital business processes are impacted causing expensive inefficiencies.

Possible causes:

  • New use case or data condition prevents workflow automation
  • End-user capabilities allow circumventing of established workflow rules
  • External data (from integrated systems) is not present as designed

Response:

  • Research the failure and attempt to duplicate the data/system condition
  • Review logs and event data to isolate system state during failure
  • Once isolated address missing logic, defect or implement controls

In some cases, where a root cause cannot be determined, implement additional tracking/logging/monitoring to help with the next occurrence

Integration Related Bugs

One of the most difficult of bugs to address are those related to externally integrated systems.  External systems are outside the control of Black Line and therefore limits our ability to troubleshoot or address system issues.

Examples of integration related bugs:

  • Unreliable external systems produce inconsistent data for Black Line systems
  • Failures in data transfer
  • Inaccurate data
  • Data transferred not conforming to expected format
  • Unavailable/incomplete notification of system issues
  • Performance issues with external systems
  • Unexpected adjustments to external systems impacts BLC developed system

Impact:

Integration bugs are typically very impacting because of the importance of data within the workflow of the BLC system.

Possible causes:

  • External system upgrades
  • External system network issues or outages
  • Integration code failed to communicate as expected
  • New data caused BLC integration code to behave unexpectedly

Response:

  • Research the failure and attempt to duplicate the data/system condition
  • Review logs and event data to isolate system state during failure

In some cases, where a root cause cannot be determined, implement additional tracking/logging/monitoring to help with the next occurrence

Browser/Platform Related Bugs

Browser, or software distribution platform, bugs are related to browsers or operating systems which the custom software is running.

Examples of Browser/Platform related bugs:

  • System fails to load at all on the platform
  • Once running system suddenly fails to run
  • Running system from another computer and getting different results
  • Running system from another browser and getting different results
  • Features that were running just fine one day (on the same computer and browser) suddenly fails to operate as expected
  • The system exhibits “Strange” behavior suddenly
    • User Interface is laid out differently
    • Navigation, buttons, links jump or operate inconsistently
    • Cryptic errors and messages

Supported Browsers and Versions:

  • Chrome: (Current – 1) and Current
  • Edge: Current
  • Firefox: (Current – 1) and Current
  • Safari: (Current – 1) and Current

(Current – 1) and Current denotes that we support the current stable version of the browser and the version that preceded it. For example, if the current version of a browser is 24.x, we support the 24.x and 23.x versions.

Unsupported Browsers:

While sites might run without major issues in older browser versions, we do not actively test our applications in them and generally do not fix bugs that may appear in them.

Similarly, BL does not fix bugs in pre-release versions of browsers, such as beta or dev releases. If you find a bug with a site in a pre-release of a browser, you should report the bug to the browser vendor.

Impact:

Browser or platform related bugs have varying degrees of impact and typically manifest in once running systems failing to operate properly.  For example, a browser is old and features that work just fine in Chrome do not work at all Internet Explorer or Edge.  Or, a once running system appears, for no reason, to not operate properly.

Possible causes:

  • Unsupported/outdated browsers
    • Internet Explorer
  • Outdated or not updated browser versions
  • New browsers or recent updates to browsers
  • Unsupported or outdated operating systems
    • Windows XP
    • Windows Vista
  • Outdated or not updated operating systems
    • Operating systems not having service packs applied
    • Operating systems without .NET versions updated
  • Recently updated Operating Systems or components

Response:

  • Attempt to isolate the problem
    • Switch to a browser that is known to work
    • Switch to another computer that is known to work
    • If the system is used by a team, check with other users
  • If caused by Operating system or browser upgrades
    • Rollback system upgrade

What does Black Line IT mean
It’s the blinking vertical cursor |

It means your IT systems are up, available, and ready for business.
It means we’re standing by, eager to help. It means you’re with a company that looks at things differently.