The Best Development Styles for Preventing Stakeholder Misalignment


Traditional discovery methods don’t do enough to overcome the risks of stakeholder misalignment.

The best development styles are context – and behavior-based development philosophies that create shared understanding between developers and product owners.

Every business is unique. Even companies operating in the same industry have different operational needs. While this isn’t a problem by itself, it does make working with technology partners more complicated.

There’s often a disconnect between developers and other stakeholders. Developers have to understand exactly what’s needed before they can build it, and getting to that point requires domain-specific knowledge they can only get from their partner.

This is where the breakdown happens. Stakeholders come to the table with different ideas about what the product should look like and how it should work.

When a developer doesn’t make a point of reconciling these misaligned expectations, it can result in budget overruns, damaged reputations, and even project failure.

Traditional discovery methods don’t do enough to overcome the barriers in understanding, though.

Instead, context – and behavior-based development philosophies should take precedence.

The Problem with Misaligned Expectations

Working around misunderstandings might sound like a simple annoyance, but it has wider consequences for developers.

Features that don’t do what the client needs have to be reworked, and new ones get added last minute. Such a stressful experience damages the client-developer relationship.

Clients are less likely to use the same company again, and the developer may even have trouble winning new contracts.

The consequences go beyond budget overruns and damaged reputations. In 40% of bug tickets developers find that the documentation isn’t clear enough to help resolve the issue.

That adds to the time – and expense – of maintenance.

Contextual Development Philosophies

A well-designed development workflow helps get all stakeholders on the same page. It enables developers to hit requirements better, assess performance more accurately, and produce solid documentation that results in more efficient maintenance. Here are some of the most effective methods in use today:

Example Mapping

Example mapping is a method of guiding a conversation to create a shared understanding among stakeholders.

It’s also known as “Three Amigos sessions”, which refers to the primary perspectives used to examine an increment of work before, during, and after development:

  • Business: What problem are we trying to solve?
  • Development: How might we build a solution to solve that problem?
  • Testing: What could possibly happen and how would we handle that?

Three Amigos can be used to write acceptance tests before implementing the corresponding functionality.

Acceptance Test Driven Development (ATDD)

ATDD emphasizes communication between testers, developers, and product owners, bringing the product owner into the test design process before any coding is done.

Tests are phrased in business-specific terms instead of engineer jargon. Plain-speech feedback comes quickly and is easy to incorporate going forward.

This focuses development on actual business goals. It also facilitates clear communication, so everyone understands what is happening, what should be happening, and where things are going wrong.

ATDD is a contextual approach to exploring software requirements. Stakeholders suggest scenarios of how the software will be used, then use those to define requirements and design functional tests.

The process sometimes even uncovers stakeholders who were missing from the process.

Having realistic examples rather than technical abstracts improves communication between clients and developers.

Behavior-Driven Development (BDD)

Under this evolution of Test-Driven Development (TDD), software is built incrementally according to a user story.

Developers create features and adjust design specifically in response to real-world behavior and feedback. The process is dynamic and responsive:

  • A product owner explains part of the process.
  • Developers write a corresponding feature.
  • Testers check whether the feature supports the user story.

BDD uses a structured language called Gherkin to create explicit, easy-to-understand requirements which can be read using Cucumber, a test automation tool.

Here are some of the most common Gherkin keywords and how they’re used in context:

  • Feature describes the feature being tested.
    • “An error message alerting users who make mistakes on the contact form.”
  • Scenario is putting the behavior being described in context.
    • “A user is filling in the contact form.”
  • Given sets the beginning state of the scenario.
    • “If the user enters letters into the phone number space”
  • When describes an action the user takes.
    • “When the user hits send”
  • Then details the testable outcome.
    • “The form reloads with the invalid entry outlined in red and an error message explaining how to correct it.”

There are about ten keywords in all with other uses. (For example, “and” can be used to expand any other other operators.)

The most important thing, though, is that BDD and Gherkin acceptance tests guide stakeholders in choosing where to start development, deciding how to test, and understanding why tests fail.

Final Thoughts

Good communication is the antidote for nearly all major problems that can derail projects.

It follows, then, that the best development philosophies for enterprise software development revolve around improving communication and understanding among stakeholders.

Taking the time to prevent misalignment from the start leads to more productive development and a higher quality final product.

At Concepta, we measure our success by the success of our clients. That’s why we use contextual development methods to be sure our products support specific business goals. Set up a complimentary appointment with one of our development team to find out what we can do for you!

Request a Consultation

CrossBrowserTesting Review: The Good, The Bad, And The Alternatives


CrossBrowserTesting is a cloud-based testing platform for websites and apps.

It provides powerful tools for exploring how a website performs on a variety of devices and browsers, and it’s considered a staple for many developers.

Why is CrossBrowserTesting Important?

User experience has taken center stage in the battle for customer acquisition and retention. It’s more important than ever to make sure every user is having the same experience, no matter where they are or how they get to the website.

The quest for uniformity is made harder by the huge variety of browsers in use. Besides the “Big Five” (which, as of 2018, include Chrome, Firefox, Safari, Internet Explorer, and Edge) there are scores of alternative browsers that may be more common within a particular customer base.

To complicate matters further, new internet-ready devices are being invented every day. Developers have to plan for traditional computers and laptops as well as tablets, phones, and wearable devices. Even fitness equipment and some appliances can access the internet now.

There’s no practical way to manually test every browser and device that might be used by customers. However, it’s risky to ignore the less popular options. The average person uses 3 different connected devices over the course of a day.

If they happen to find the site or app on an unsupported platform, they’re unlikely to return through another device later.

CrossBrowserTesting provides a range of manual and simulated testing services on more than 1,500 devices and browsers. Developers use it to check whether their clients’ websites are rendering properly across the board.

CrossBrowserTesting provides a full, explorable picture of how well the product functions, ensuring better quality and a more consistent user experience.

Strengths of CrossBrowserTesting

What developers like about CrossBrowserTesting is that it’s easy to use. They can test their layouts on a huge combination of operating systems, browsers, and resolutions simultaneously. It shortens the amount of time they have to spend on testing without lowering quality.

CrossBrowserTesting uses real browsers instead of emulators. It’s also one of the very few tools offering manual testing on physical iOS and Android devices, with coverage for the Nexus, Galaxy, Tab2, and hundreds of other devices. Developers can swipe and interact with the devices during their tests.

Automated screenshot comparisons and testing videos give developers an overview of their site’s status. They can perform apples-to-apples comparisons and quickly identify platforms that need more attention.

Additionally, CrossBrowserTesting offers Selenium automation for mobile and desktop browsers.

Weaknesses of CrossBrowserTesting

Virtual machines for mobile devices can be painfully slow (though they’re still faster than individually testing each device). It’s also not easy to edit end to end testing.

Some developers have also had problems with CrossBrowserTesting’s documentation. They report typos, structure issues, and some misleading examples that caused unnecessary confusion.

What Else Is Out There?

While CrossBrowserTesting is a powerful tool, most developers use a variety of different tests to get fuller coverage. Here are some popular alternatives:

SmartBear TestComplete

SmartBear owns both CrossBrowserTesting and TestComplete. TestComplete offers more powerful testing options across technologies, and it’s easier to create tests. However, the code editor provides badly-formatted code and some users have struggled with frequent crashes.


BrowserStack is a testing platform that boasts a large variety of developer tools and supports many different devices and browsers. Reliability has been an issue for some, though: the test client runs differently on different operating systems, and the virtual machines reject new tests instead of queuing them when overloaded. is an end-to-end testing tool built on Node. It’s easy to debug with a highly supportive community. The problem is that Cypress doesn’t support more than one browser instance and doesn’t support native events (such as file uploads).

Future Outlook

In a world where digital transformation is key to staying relevant, developers are pushing to work faster without sacrificing quality. CrossBrowserTesting helps them stay on schedule while still creating a dynamic end product. With results like that, it’s not going anywhere.

At Concepta, we know that testing isn’t just something to cross off a checklist. It’s an integral part of development that directly impacts our clients’ bottom lines. That’s why we use test automation tools like CrossBrowserTesting to make sure users are getting the same great service wherever they are. Set up a free, no obligation consultation to discuss testing your company’s products to find out how they perform in the real world!

Request a Consultation