At Testomato, we eat our own dog food. Eating your own dog food means we use our own product. We try to be our own customers.We work hard to understand what we’re building from your perspective.
Since Testomato was originally built to fill a void in our own testing process at Wikidi, we regularly use our own product in our development process.
Over the last 3 years, we’ve picked up some tips about our product that we’d like to share with you. Hopefully, you’ll find something helpful from what we’ve learned as a development team along the way.
1) It’s all about the team.
One of the biggest lessons we’ve learned as a team that has members working remotely has been that communication is key. One of biggest goals is to try and stay connected constantly regardless of where we are working.
That means anything from brainstorming to commits and tests.
Testomato is a great tool for team collaboration on testing. When someone is not working in the office, it’s important for us to have a way to get our work done without negatively affecting our workflow.
Take advantage of the features that allow you to stay in touch with what’s going on with your projects. Add user roles to make sure other team members or clients have a way to access your tests results. In addition to system roles, which have set permissions, you can customize user permissions according to the individual and allow access to people on your own terms.
2) Build testing into your process.
We’ve integrated automated testing into our deployment process in order to keep our iterations as fast as possible and deliver frequent changes to our users.
Try to build testing directly into your process instead of the end to avoid ending up with expensive mistakes. Resolving issues with automated testing before a cycle is complete significantly cuts down on the risk of human error and makes it easier for you to act quickly to minimize any long-term consequences.
Here’s our basic set up:
- We continuously integrate changes to our staging environment.
- Automated testing is used to verify they function as expected.
- Manual release to production.
- Production undergoes automated testing for an hour.
- Regular automated testing is conducted on production and the results are displayed on 2 screens in our offices.
Using automated testing early on in development allows teams to identify and locate problems more easily. This will free up more time to spend on building new features instead of trying to track down where things went wrong.
Although Wikidi uses Selenium as well to test our staging and production servers, you can still use Testomato for the same process to catch issues before a release or find live issues quickly to avoid affecting visitors.
3) Maximize your tests.
Since we are responsible for building Testomato, we try to use it to its maximum potential. Take advantage of all the tests that are available to help increase your code coverage.
The more tests you have, the less likely it is for you to end up with a website that doesn’t work properly.
Here are 3 tests we think you should be using (if you aren’t already):
Password-protected areas: Test all areas of your website, including pages that are only accessible with a password.
String tests: Search for missing or expected strings to make sure the most important information on your page is present.
Form tests: Configure tests for important forms for sign up or sign in to ensure they work properly for users.
4) Take control your inbox.
Email notifications are a great option for many teams, but sometimes you don’t want or need to fill up your inbox with more messages.
Trust us, we understand.
Some of us get hundreds of emails a day and adding one more that isn’t necessary only clogs up our inbox and interferes with our ability to get things communicated efficiently.
There are 3 important features to help you avoid overloading your email:
- Add an alternate email address to your account. Receive all your notifications at an alternate email for an easy way to filter and organize your test results.
- Delay notifications for better alerts. Delay notifications for 5, 10, or 20 minutes to avoid receiving notifications about false or short errors.
- Set a severity level for your notifications. Avoid receiving emails for warnings such as time outs or authentication requests in protected areas.
5) Use reports to create benchmarks.
Develop performance measurements to predict future outcomes and measure productivity using our email reports, or view them directly from your account.
Creating benchmarks related to problems on your website can help you identify problems and find ways to improve your current processes. For example, you can track how often a problem occurs and how long it takes to resolve to find ways to improve support.
For example, we’ve added popular websites and projects to our dashboards to help us learn more about what kinds of problems they experience and how fast they get fixed.
If you like to track yourself against competitor benchmarks, you could also try setting up projects for their websites to find out how you compare to their performance.