-
Jira Integrations are now live!
We’ve been getting this request for a long time and it’s finally live! BetaTesting is integrated with Jira to push bugs from your tests directly into your Jira Server or Jira Cloud account.
It’s simple to map fields from our bugs to various fields in your Jira account, such as title, description, priority level, attachments, and more.
Within each test, you can choose your own integration, so different tests can connect to different development teams.
Contact us for a demo to learn more!
-
Beyond Beta Tests: Collect Data for AI and Machine Learning
Over the past few months, we’ve seen more clients leverage the BetaTesting community (200,000+ participants) to collect real-world data to improve AI and machine learning within their product:
Crowdsource pictures to improve image detection algorithms.
A large car parts company in Europe crowdsourced pictures of car interiors from BetaTesting users to tag images for debris, helping their machine learning algorithm learn if a car was clean or dirty. Within days, they were able to collect thousands of pictures from different vehicle types around the world to improve their product.
Track phone sensor data (e.g. locations, battery, acceleration).
Another customer had users share their schedules throughout the day (at home, driving to work, at work, sleeping, etc) and matched it to their phone sensor data to learn more about their customers and improve their AI algorithms to anticipate customer behavior.
Gather user ratings to improve recommendations engine.
A number of companies have improved their recommendation engines for content by asking a wide variety of testers to rate content and give user feedback around preferences and categories to make their products more personal and targeted for each customer.
Collect software telemetry for PC app over several weeks.
An antivirus product for desktops asked users to beta test their product and provide back-end log files to track the software telemetry internally within their team and learn more about how the product behaved across various devices and operating system versions.
—-
AI and machine learning products need more data than ever, and our platform + community is the perfect mix to source large datasets or hard-to-find niche users to make your products more accurate and powerful. This includes pictures, speech inputs, mobile usage, location data, and much more.
As a team, we are excited to see these opportunities to connect to users in different ways to improve products beyond beta tests. Our community of over 200,000+ people is perfect for gathering any data you need to improve your products. With our tools, you can find the right demographic anywhere around the world and get the exact data you need – within hours or days.
-
BetaTesting Test Design: How to Setup Your First Test Process
One of the most common questions we get asked about our test design process is: “How should I setup my beta test?” How many tasks should I give testers? How many surveys should I setup?
There are a lot of different ways to setup your beta test, and it is usually driven by what you hope to achieve from your test.
QA / Bug Reports / Functional Testing
For technical testing, where you are trying to identify bugs, specific test design scenarios that cover your entire product are usually best. For example:
- Create an account in our app and fill out your profile.
- Go to Settings, click on “invite a friend”, and add their email address to the app.
- Go to ‘Newsfeed’, upload your first picture, and add location tags to it. Submit a bug report if you are unable to complete any of these tasks.
Asking for specific tasks helps testers stay focused and helps our clients find bugs across different operating systems, phones, and browsers that can be resolved quickly.
Usability or UX Testing
If you are more interested in general usability and UX/UI testing, we recommend keeping the test design process more high level and letting users explore your product more organically. For example:
- Create an account and begin using our app.
- Try to connect our app to your Google Home or Alexa.
- Use voice commands to control the settings in the app and share what voice commands you tried.
- Continue using the app every day for the next week and then answer our final survey.
Higher-level test tasks give testers more freedom to explore the app on their own. This provides a larger variety of use cases and opinions from testers. When you want to learn about your app’s design, ease of use, or net promoter score, a test designed to let users figure things out on their own will help you get more accurate scores.
-
Professional Beta Testers vs Real-world Beta Testers
When you run a beta test for your product, there are tradeoffs to consider between professional testers and real-world beta testers. A lot of companies use professional beta testers to help companies test their products, and those testers have deep experience dealing with technical tests that require a deeper dive into a product to find issues.
Before we changed our name to BetaTesting, we built Erlibird as a community of early adopters interested in finding new tech products and providing feedback for them. It made our community a diverse mix of tech-savvy early adopters and regular people. Since then, we have focused on building a community of real-world testers across the world with a variety of tech experience.
We believe using real-world testers leads to better feedback and results for most tests. We are able to recruit testers that actually match the audience for your product, with a true mix of platforms, operating systems, connection speeds, and more that help customers find real bugs and get more accurate UX and UI feedback.
In most cases, companies need quick feedback to iterate their products, see usability videos to learn where users might be getting confused, and test the validity of their new features and products. In those instances, a real-world community makes more sense than a community of professional testers.
-
Sending Effective Beta Testing Invite Emails
At BetaTesting, we’ve sent out close to 5,000,000 beta testing related emails. Many of these have been beta testing invite emails designed with the specific purpose of communicating test details concisely and getting high levels of engagement from our community of testers. We’ve A/B tested, measured results, and redesigned our emails countless times based on those results.
With all of this data, we’ve learned that there are several factors that can influence the effectiveness of your beta testing invite emails. The pay-off is clear: Sending better invite emails will help you attract the right testers that are more likely to become active users of your product now and in the future. In this article, we’ll take a look at some things you can do to improve the effectiveness of your invite email:
1. Work Within Bounds
Understand that your beta testing invite email open and click rates, and your larger beta participation rates are primarily driven by the value of your product.
This is an obvious one (and maybe not the type of advice you’re after right now) but it’s very important to keep in mind that all the marketing/messaging/magic in the world can’t make up for a product that simply isn’t valuable / fun / interesting. If you build an exciting product that is fun and useful, some people are going to get in line to test it. On the other hand, if people aren’t intrigued by your product, the invite email isn’t going to change that. So, when designing the invite email, the goal is to fine-tune the messaging to simply and quickly communicate your product’s value. If you find yourself instead communicating something else (e.g. value your product doesn’t really offer) or leaving important information out in order to increase open/click rates, it’s a sign that you may need to change your product.
2. Communicate Your Product’s Value in One Short Sentence
When communicating your product, LESS WORDS > MORE WORDS
Think of this as the email version of your elevator pitch. Invest some time and effort in coming up with one simple sentence that accurately describes your product and catches people’s attention. Some helpful tips:
- Mention what problem your product solves, or how it might benefit the user.
- Avoid marketing lingo.
- Run A/B tests with different language.
When working with our clients, we have seen that when faced with the challenge of communicating something clearly, everyone’s intuition is to communicate more: more words, longer sentences, links, screenshots, etc. Unfortunately, this has the opposite effect from what is intended because most people are not going to spend the time to read every word you’ve written. More words ends up being more confusing (not more nuanced and complete as you expected).
3. Provide Key Information
What you should include in every beta testing invite email.
Besides communicating a short exciting sentence about your product, here are some other things to include:
- Expectations: Be upfront about how much time you expect the testers to spend engaging / providing feedback. Most people are busy, and they want to know the required time commitment before making a decision.
- Incentives: Let users know what’s in it for them. Although the primary motivation for most testers is to help you launch successfully, they still expect to be compensated for their time and effort. Knowing the incentives upfront will help them decide if the test is a good fit for them.
- Exclusivity: If you are running a private beta with limited invites, mention how many spots are available. The opportunity to be one of the few people that get early access to your product might make it more attractive for potential testers.
- Prerequisites: If there are any prerequisites to apply for your test, you should mention them in the email. (At BetaTesting, we help our clients filter for prerequisites through demographic targeting, and an additional screening survey for refined targeting on any criteria like interests, lifestyle, etc)
- Call to action: Be clear about what you want people to do, and include a “Call to Action” button in your email. For example, if you want people to apply for your private beta, your CTA button could be “Apply for Early Access” (which links to a landing page where users can apply for the test).
4. Measure The Results
A/B test several versions of your invite email to optimize your results.
It is unlikely that you will get the results you want on your first try. You will probably need to refine / re-design your emails several times until they are optimized. If you have a large enough list (thousands of people), you can send a few different versions of your invite to different groups. Each group should be hundreds in the minimum, but ideally thousands in order to obtain reliable data. After you run a few of these tests, you’ll be able to see what works best and you can stick with that version. If you don’t have a big enough list, run some tests with Google Consumer Surveys, or hit the pavement the old fashioned way and ask people on the street.
Finally, remember that while these tips can help you craft better beta invite emails, this is only one small part to achieving high levels of beta engagement. For example, if you are building an email list before you get to the beta stage, it’s much better to stay in touch with your audience and get them excited by regularly sending them interesting content and updates (not just waiting for one big beta launch email).
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Small Changes, Large Impact: How Beta Tests Improved Amazon's App.
When most people plan to run a beta test, they think big. We need to test the entire app for usability. We have to find all the bugs before we launch. Lets rebrand our entire site.
While thinking about the entire product and entire user flow is necessary, sometimes it’s the smallest things that confuse users. A small change to your copy can drive more conversions. A small update in your design might make a key feature more clear. This is where some of the most important changes to the usability and user experience of your product come from.
This example really drives the point home.
Even the best e-commerce company in the world makes assumptions and mistakes that lead to user confusion. To customers in rural India, the magnifying glass icon for search was a ping-pong paddle!
Most of us have biases about product design and assume certain icons are universally known to everyone to mean something specific. But as more and more people get online, in remote and rural areas of the world, those biases need to be tested. Everyone, from Amazon to new startups, needs to beta test their apps and get in-depth feedback to figure out if your product is creating confusion you never thought about before.
-
ErliBird is now BetaTesting.com!
ErliBird is now BetaTesting.com!
Today, we’re excited to announce that ErliBird is officially changing our name to BetaTesting.com.
We launched in 2012 as a way to connect early adopters with new tech startups. While the name “ErliBird” was a great fit then, it doesn’t reflect who we are now.
Over the last 6 years, we’ve moved away from simple product discovery, and built a community of over 150,000 enthusiastic beta testers that love engaging with products and providing real world feedback. We’ve worked with some of today’s most exciting startups and established companies (check out our customers page). Our community has submitted many thousands of surveys, usability videos, and bug reports to help companies big and small launch and improve their apps, websites, and hardware.
To reflect our growth and evolution, we wanted to find a new name that reflected who we are now – and most of all, keep things simple. And BetaTesting.com is as simple and direct as it gets.
Going forward, nothing will change for our users. Your login, access to tests, payments, and everything else will stay the same. We will continue to invite you to tests you qualify for, so thank you for all your support over the years as we have grown.
Cheers,
The Erlibird BetaTesting Team
Learn about how ErliBird can help your company launch better products with our beta testing platform and huge community of global testers.
-
3 Ways to Screw Up Your MVP After Its Release
When your Minimum Viable Product (MVP) is successfully released, you can still screw things up. Here’s how to avoid squandering your MVP and messing up your full product.
The best possible start
Let’s paint a picture where your startup has done everything right, from concept through first release.
You identified a customer problem—a need—and envisioned a novel product solution. You pared your idea down to the essentials that serve an initial target user group, and judiciously scoped a Minimum Viable Product (MVP).
Quickly and nimbly, your team designed and built a spartan but pleasing-and-effective version of the product. You identified how to measure the success of the MVP (i.e., how to determine whether your solution sufficiently meets the user need). Your team releases the MVP to your initial users without incident.
All of the above is difficult enough to do well, but let’s take it one further: your proof-of-concept MVP passes the big test with users!
So, from concept to validation, you have relatively quickly confirmed that your core idea for addressing a customer need is a good one, and that the product is worth building on.
Everything is great. But it’s still pretty easy to screw up from here.
What’s NOT a screw-up
Let’s take a step back and imagine another outcome.
What if the released MVP showed that your product doesn’t effectively solve you users’ problem? That’s not a screw-up. That’s the reason why you went the MVP route to begin with; if the idea was going to fail, you want to fail quickly and cheaply.
But again, that’s not your story. Your core product is effective, and clearly worth moving forward with.
What’s left to screw up?
Ways to screw up your MVP, post-release
1. You don’t fully leverage your MVP as the experiment it is
Even if your main focus was to confirm market viability, there is still a bunch more you can learn from your MVP and its users. Test deeper.
Your measurements met your success thresholds, sure, but what else can they tell you? What else could you measure? How exactly do your users use the product, and how does that map to your expectations? What do your users have the most trouble with? How do they feel about the current product and its potential? What features and enhancements do they say they want the most? What do potential paying customers care about vs. what free-version users do? Etc.
Wring all the knowledge you can out of your MVP while it’s still active.
2. You rest on your laurels, or simply wait too long
The next big step after validating your core idea is to move toward developing your full product.
Don’t wait
If you built your MVP in a not-really-production-ready fashion—which it often makes sense to do, to facilitate cheap rapid development—then it will likely be obvious to you that you need to move quickly to replace it with the real product.
If, however, your MVP was developed in a production-ready fashion and is a suitable foundation to build upon immediately, then, ironically, you’re a little more likely to get complacent and put it off.
Either way, waiting too long to follow up on your MVP is a mistake. It was an experiment of its time, and its lessons get staler and less reliable the farther it gets in the rearview. Planning an MVP effort from the start should include time and resources to immediately follow up on the result.
Don’t stay minimal
Also, don’t lose your way after your MVP test. The lesson of the MVP process thus far wasn’t that the narrowest of core functionality is all you need, indefinitely. Just because you were able to eliminate a bunch of potential features and enhancements from your successful MVP doesn’t mean those features aren’t good, or even business-critical. They just weren’t essential to proving out market viability in your MVP experiment.
Your early adopters were likely only a subset of your target user base; your product may require additional features and smoother edges to satisfy the next set of users. (The early adopters won’t have infinite patience, either).
Your product won’t remain viable for long with just the minimum set of features. (Just checking, if I’d written “Your P won’t stay V if is remains M for too long”, would you have understood what I meant?)
3. You move forward with your head down
You had a ton of ideas that didn’t make it into the MVP. You made a prioritized list of all the features and enhancements that you still want and need to do.
This is your vision for the full product. Your MVP tested the waters. Now that you can dive in, how do you proceed?
Don’t stubbornly stick to your roadmap
Even before your MVP was released, you probably had a well-thought-out roadmap of future features and enhancements to pursue.
But no matter how good your roadmap is, it’s going to be at least a little wrong.
Don’t work on the full product with your head down. Listen to and observe your users, and observe the realities of the market as it’s playing out with your MVP.
Listening and observing will:
- tell you what features you should prioritize,
- show you what needs to be redesigned for usability,
- guide you toward promising revenue streams and away from bad ones,
- inform you as to how your users view your product vs. similar existing products,
- inspire important features that aren’t already on your list,
- and eventually make you realize that some of the features on your list don’t need to be.
Keep iterating
Even though your MVP experiment is behind you, you should continue to apply a similar philosophy to the rest of the product lifecycle.
Keep applying a build–measure–learn approach. Adding a new feature? Get it to market quickly, get feedback, then develop it further or fix it if it’s not effective.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Benefits of Using Variable Fonts
Variable fonts are becoming increasingly viable for use in your web projects. Here’s what variable fonts are, and how using them can benefit the user experience.
Variable fonts vs. the usual way we deal with fonts
When you pick a named font to use on your website, for example “Arial”, “Helvetica Neue”, or “Open Sans”, you’re actually picking a font family (a.k.a. “typeface”).
You might use just a handful of fonts in that font family on your site, e.g. Arial Regular, Arial Regular Italic, Arial Bold, and Arial Bold Italic. Typically, each of these fonts is defined in a separate font file.
So, even though Open Sans Semi-Bold is rather similar to Open Sans Bold, each is represented by an independent font file of roughly equal file size that would have to be downloaded to your site-visitor’s browser. And the file sizes of all those font files can add up.
Variable fonts allow more of a font family to be defined in a single font file. Within a variable font file, font designers develop “master” font style variations, as well as the math-based rules under the hood that allow users of their font to morph between those variations by modifying simple numeric values. The result is a font file that can produce a lot of variation in relatively little file space.
The user-controllable style variations don’t end at thickness and slanty-ness, though. Variable fonts allow font designers to get creative and provide font consumers many more dials to play with.
Some benefits of using variable fonts
Here are some of the benefits of variable fonts.
Faster-loading pages
Less font data to download means faster page-load times.
This will likely be the single biggest benefit of variable fonts on the web, at least initially.
Let’s say you’re visiting a web page that uses six font styles, but requires just two variable font files. Those two font files are smaller in total size than the six you would have had to load otherwise, so that’s fewer server requests and less data to download for that page to display properly.
Thus, your web pages load faster. And faster-loading pages make for better user experiences than slower-loading pages.
Fewer compromises for designers
Another consequence of having overall smaller font file sizes: designers who are file-size conscious—or who are reined in by managers and technical leads who are—do not need to make as many compromises to their design.
The more that variable fonts proliferate, the fewer conversations you’ll need to have that begin: “Do we really need the Light Italic version of this font? It costs us an additional 100kb.”
Finer tuning
Variable fonts allow users of the font to adjust its supported parameters in relatively small increments, allowing for fine-tuning where desired.
Take the common example of font weight. With traditional fonts, font weight values range from 100 to 900, but are limited to nearest-hundred (and that’s presuming that each hundred is available as a separate font file).
Variable fonts, however can allow the font weight to be meaningfully adjusted to any number in the supported range. Want to split the difference between Semi-Bold (traditionally 600) and Bold (700)? Set the font-weight to 650, and that’s what you’ll get. Without a variable font, you’d be forced to choose between one or the other.
Far more options for font designers and font users
Axes of variation
Variable fonts let typeface designers design fonts that users can modify in a variety of ways. Each kind of style variation that a font supports is an referred to as an axis. Font weight is one example of an axis of variation in a typical variable font.
For each axis of variation, the font user can modify the style value within a predefined range. For example, one font might allow users to set the font weight to any value between 300 and 800; another font might allow a range of 1–999.
Tons of style combinations
A single variable font can support a large number of axes (if the font designer so chooses), and a font user can adjust any or all of the supported axes’ values.
As a result, the number of possible style combinations can get enormous fast.
For example, if a variable font supports weight in the range of 200–900, and width in the range of 50% to 150%, that’s 70,000 style combinations right there (and that’s presuming whole-number values only). If it supports a third axis with a range of 500, you’re already at 35 million combinations!
Please don’t make me do any more math.
Creative variations
These axes of variation can allow UI designers to modify normal stuff, like a font’s weight or width or italics-ness. But a font designer can also create custom axes for more creative modifications.
This might be as dry as decreasing the size of capital letters, as specific as increasing the number of thorns on a rose-themed font, or as wacky as changing the size of the hat that appears on the head of each emoji in an emoji-icon font.
Practical axes
Benefits of custom axes of variation don’t just cover aesthetics, they can be practical as well.
For example, some variable fonts have a “grade” axis that allows you to change the weight of the text without affecting the width of the text. This would be useful in a UI design where, for example, text labels are bolded when the item is selected, but it’s important to your design that UI elements don’t change size.
Text animations and transitions
Because an axis values can be modified incrementally, variable fonts allow for smooth CSS transitions between text states.
This page contains some interactive examples of text transitions triggered on mouse hover (as well as some examples of creative axes of variation): https://pixelambacht.nl/2017/variable-hover-effects/
In addition, variable fonts will provide more opportunities for interesting text and icon animation effects, based on font designers’ creative axes of variation.
More-responsive responsive design
Variable fonts provide tools for enhancing responsive design.
Some of this ties the concept of fine-tuning with responsive techniques. An example of this would be setting the font weight of a headline to always be a function of the current screen size, to preserve balance in your visual design.
You can also take readability into account, based on the size of the screen and the size of the text. With decorative fonts, you may wish to tone down the decorative styling of a heading when the text gets too small for the flourishes to be effective. Along the same lines, if a variable font supports the optical size axis, then you can give your users the best experience by tuning the font for optimal legibility based on the current size range of the text.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Gradually Master Cross-Platform Mobile App Development: Learn Flutter and Dart as You Go
You’ve gotten started with Google’s Flutter SDK to build mobile apps on both iOS and Android, but what now? Here’s how to keep the momentum going and learn Flutter and Dart over time.
Keep going after “getting started”
This article is about how you might learn Flutter and Dart over time in a sustainable way, to grow your mastery of the technology so that you’re ready to use it to enhance your career or your business.
Prerequisites
This article presumes that:
- You know what Flutter is, and
- You might have already gotten started using Flutter
The latter article is about how you can get started with Flutter. In particular, how to do so without quickly losing steam or immediately bouncing off.
Losing steam and dropping out are common when you’re just getting started with learning a new thing, but it continues being a risk afterward, too. Things can get dry, unrewarding, and frustrating if you’re not careful, and there are so many other shiny things to learn out there!
How do you avoid losing steam learning Flutter and Dart? Rack up small victories, bite off interesting pieces as you go, learn from others, and keep going.
Set achievable Flutter goals to learn as you go
Once you’ve done all of the hand-holding courses and tutorials that are available to you (or that you can stand), it’s time to give yourself some small, achievable mini-projects to drive your learning.
In his article for newcomers to Flutter, Nick Manning recommends setting “motivation milestones”, which can include both building and research milestone goals. Some of his examples:
- Milestone Three: Learn how to hook up a button, change some state and render it on the screen by using a StatefulWidget.
- Milestone Four: Take a few hours to read up on Dart.
- Milestone Five: Be able to fetch some data from a public API and render it on the screen. Understand how to work with JSON and deserializing it.
- Milestone Six: Release an actual iOS and/or Android build to a friend. This […] is really an amazing way to stay motivated and confident that you can crank out an app to the public one day.
Get input and ideas to learn Flutter as you go
Whether you’re giving yourself milestones or mini-projects to learn Flutter, it’s important to keep them relatively small and achievable.
You might want to assign yourself a project that is interesting to you and break it down into sub-goals. Or perhaps you want to be more reactive to outside forces, where the internet brings ideas to you.
Here are some places where you might be inspired to learn bits of Flutter as you go.
Flutter articles and media
A bunch of fine folks write informative articles about Flutter. This content might teach you something new, bring an aspect or capability of Flutter to your attention for you to pursue further, or simply allow other developers’ projects to inspire your own.
You might occasionally search the web landscape for such articles, train your phone to bring them to your attention, or follow authors who periodically publish content on the subject.
For example, on Medium, you might browse stories tagged “Flutter”, search through content on the official Flutter channel, or follow individual authors like Deven Joshi or Burhanuddin Rashid, who periodically write articles about Flutter.
Similarly (and yet differently), there is also The Boring Flutter Development Show, a video series on YouTube.
“Cookbook” and other Flutter.io documentation
Flutter.io has a bunch of great documentation to browse through, including a “Cookbook” of Flutter solutions to specific small goals (e.g. “Working with Tabs”, “Fade a Widget in and out”, “Introduction to unit testing”).
Poking through these might help you assemble your own milestones list.
Pick a widget and try using it
See below!
About those Flutter widgets
Everything is widgets / widgets are everything
Flutter is all-in on an abstract concept of widgets. In a Flutter app, effectively everything is a widget: UI text is a widget, input fields are widgets, layout containers are widgets, gesture detection is a widget, the app itself is a widget… you get the idea.
Learn Flutter widgets as you go
You might be tempted to dive into the documentation and learn about each and every widget type that the Flutter framework provides.
That’s not what you should do when you’re getting started, and it’s probably not what you should do afterward, either. Instead, you might investigate only the widgets that fit the need for your current project. Or pick an interesting widget first, and build a mini-project or milestone around learning it.
For identifying interesting or useful widgets, you might:
- Browse the catalog of categorized widget types in the documentation
- Run the Flutter Gallery app (from the Google Play app store or build it from GitHub). You can visually browse and interact with some of the widget types and samples, and inspect the actual code.
Learning Dart to learn Flutter
Flutter uses Dart for its programming language. Dart is not a language that most developers have prior experience with, however. Fortunately, when you are starting out with Flutter you can do a bunch of tutorials without really having to think too much about Dart.
But even when you’re “on your own” and learning Flutter as you go, it’s best not to let learning Dart bog you down and sap all of your momentum.
Learning just enough Dart
Android developer Gurleen Sethi wrote a useful tutorial series called “Just enough Dart for Flutter”. The four tutorials provide a focused Dart education for the impatient Flutter learner. A lot of it serves to show you just how similar Dart is to Javascript and Java.
Google also provides resources for you to “Bootstrap into Dart”, including a relatively lengthy tour of the Dart language.
Dart as compared to X
Want to learn about Dart from the perspective of…
- …Java? Try this Google codelab: Intro to Dart for Java Developers.
- …JavaScript? Try this: “Introduction to Dart for Javascript Developers”
Full docs
And there’s always the full Dart documentation at https://www.dartlang.org/. It’s reference material. You don’t need to try to read it top-to-bottom.
Help, support, and learning from others’ questions
You don’t need to struggle through Flutter problems all on your own.
Get used to going to the Flutter Google Group if you can’t find an answer to a problem on Stack Overflow. I recommend the former over Stack Overflow when asking questions actually. You can read more advice here.
There’s also a friendly community-driven live-video help session, available all day every Wednesday.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 