It’s easy to get swept up in the thrills of new product development and forget that oh-so-essential step: testing.
Testing Equals Confidence
Until you test, your idea is simply that – an idea. Use tests to validate not just the abilities and limits of your product, but the experiences and benefits that your customers can expect.
Failing to Test is Risky
Quality is EVERYBODY’S responsibility. Failing to test can result in a product that:
- … does not meet customer needs, driving market share to your competitors
- … does not honor business rules, creating havoc when trying to integrate with existing business processes
- … does not perform a duty at a rate that is satisfying to customers, causing poor customer reviews of your product
- … breaks after each new release, leaving customers with an impression that your product is of lesser quality than competitors
The ABCs of Testing (a.k.a. The Scientific Method)
Project teams both large and small have room for testing, and we can keep it simple, yet effective. Here’s a quick way to apply the scientific method in process and application development to ensure your product is both testable and tested:
- REQUIREMENTS: Declare your problem statement
Propose the process or application by creating a list of ideas that will make it successful.
- TEST STRATEGY: Form a hypothesis
Determine how to test the proposed process or application, how to measure if it is complete or not, and document these hypotheses.
- TEST PLAN: Design the experiment
Determine how to create the proposed process or application in a way that can be measured, and write down the specific measures success and failure.
- RESULTS: Collect and analyze data
Build and test the process or application, measuring and documenting performance according to the test plan.
- QUALITY REVIEW: Draw Conclusions
Determine if the process or application met the list of requirements created in the first step.
Test, Retest, Repeat
Plan, schedule, budget, but most importantly perform testing to ensure the best experience for people that use your product or service.
Ready to test and looking for tools to help document your test plan? Here are three ideas:
- Excel Workbook – 1 worksheet per test, easy to email and file share
- Wiki – Organize By Feature, 1 page per test – we like Confluence: https://www.atlassian.com/software/confluence
- Cloud Test Planning – we like Visual Studio Team Services: https://msdn.microsoft.com/library/vs/alm/test/manual-exploratory-testing/getting-started/create-a-test-plan
We have noticed a distinct trend with our clients, business partners, and colleagues; while many of them talk the talk of a design approach centered on customer requirements, most skip the step of asking their customers, taking the path of “I already know” and “if we build it, it will be awesome, and they will come.” If IBM’s move to a Design Centered Strategy is any indication of the popularity of a design-centric approach, then why are so many businesses from startups to public companies paying lip service to design first, but not actually doing it?
This position is not without some justification; customers willing to talk with you are likely to be more amenable to your offering and provide you with a “warm fuzzy” response to any product that you show them. While participating in an alpha testing program for Tamr Catalog, their UX designer didn’t just ask about functionality. In fact, their first question about a prototype was, “How does this make you feel?”.
It truly altered the way I was thinking about the design I was looking at. Instead of focusing on does it have feature a or b, I was now thinking about how the design felt a little cold and “all business,” I was confused about what unlabeled icons meant, and I wasn’t sure what to do first.
And all of this happened in a few short Google video chats, each less than 30 minutes. While they did ask about my requirements, they did so within a lean, design-centric framework, also asking indirect questions to help uncover true pain points.
Don’t be constrained by your existing business model, naysayers that refuse to acknowledge the value of early customer feedback, or doing just good enough. Talk to your target customers to understand the key features that they want.
Dear Prospective Client,
>> I’ve talked to lots of qualified people already. Why should I hire Seabeck Systems?
Thanks for asking!
My name is Peter Loos, and I’m an organizational change agent.
For any Seabeck Systems client, our first step is to develop a roadmap of “People, Process, Tools, and Business Value” that is used to align and bring transparency to business and IT priorities, regardless of the industry or political climate. To initialize that roadmap, I ask people in the business what they do with the information they are requesting from IT. This developmental conversation is used to increase awareness of “need vs. want” for information requested. Together we focus on the business questions to be answered, then work backward to the information needed to answer each question. When the business can demonstrate how the information requested is used for decision making, requirements are captured in a new product backlog, and the project management process kicks in.
Sometimes the business may struggle to define (or to reveal) what people do with the information they request. However, my experience has shown me that this (often difficult) discussion with the business is the only way that IT can elevate a practice of reporting toward a true Performance Management Program. Turning the corner from “building tables, ETL packages, and reports” to “an information factory that supports self-serve access to clean and conformed data” is important, but without clear insight into the questions that the business is trying to answer, the technology investment will ultimately be rendered impotent as the business finds newer and more creative ways to avoid working directly with IT to get the information needed.
If your organization is ready to answer the question “what does the business do with the information requested from IT?” followed by willingness and ability to take action to deliver self-service Performance Management to your employees, I hope you will consider Seabeck Systems as a partner for your team.
The power of BI is that someone actually uses it. No matter how well constructed, your BI program cannot succeed if people do not take advantage of the information that BI yields.
A thriving BI program needs champions: people who can actively promote the program to raise awareness and stir excitement. Your BI champions encourage everyone to learn, participate and make use of BI information for daily decision making. People who participate in the BI program as it evolves provide critical feedback that enhances ongoing BI development, and ensures the relevancy of end results.
Federated BI Team
BI is not the purview of one group. Rather, success is forged by the Federated BI Team, which consists of people from across the organization who understand (are trained in) BI systems and processes. Your Federated BI Team has the capacity to identify knowledge-holders and bring them to the table, break down input and ideas, build user stories, prioritize requirements, and identify the specific objectives required to work toward each goal.
A healthy BI program needs champions who can help sustain interest and solicit input. A Federated BI Team ensures engagement and support across the company, including representatives from business and technical groups.
So where is BI successful? Answer: where people actively use BI information to support daily decision making and adjust company performance.
Got more questions? Try the BI Basics index, or share your questions in the comments.