7 Steps to properly test your website or software

Having a website for your business has sort of become the norm. Whether you have an online or offline product or service, you want potential customers to be able to find you quickly and easily. And when they do find you, you want them to have a great experience. Depending on your sales and marketing funnel, your website or app may be critical to your business or nice to have. Either way, if you've decided to develop a website or application, it becomes the window to your business. Statistically 21% of users browse online before buying in-store. And only 8% of users never research online before purchasing offline. So making sure your site or app are functioning properly is key. Once you've decided to start development it becomes a run against the clock to get things live as soon as possible. Cutting corners is never recommended, but many companies think that they can shorten the process by shortening the amount of time spent on testing and quality assurance (QA). In 2019 companies spent 23% of their IT budget on testing, as opposed to 35% in 2015. But cutting on QA may mean that your users will see buggy software, or worse yet, that there may be security issues in your software that you're unaware of. Here are a few steps you can take to ensure your software is presenting you in the best way possible: 1. Use a testing environment 2. Use separate development branches for your release 3. Use testing documentation 4. Have as many testers as possible 5. Use development software 6. Test components as well as integrations 7. Fix & retest Use a testing environment Testing your software should be done in an environment as close to your live product as possible. This means it should be a clean server, different from the one where on which you develop. Having a clean environment means the bugs you find are in the actual product and not due to someone uploading code or running development tools exactly the second you were performing the testing. Mimicking your live environment also means there is less of a chance things will start to fail when you go live. Use separate development branches for your release If you're using a code repository like GitHub or Bitbucket, have a branch for your release and test that branch on your QA environment. In general, working with branches is recommended. A branch is actually a pointer to a snapshot of your software. Adding new features on a separate branch means you can implement and test the feature before you integrate it into your software. Using a separate branch for testing means that when you finally approve your version and push it live, it will be the version you tested, and not a version with features developed or fixed after testing. Another advantage of using branches, is that if something does go wrong on the live site, you can always rollback to a previous version on the branch. Use testing documentation Testing documentation is essentially a document that lists every test you want performed for every feature and integration. Working with testing documentation means your testers are testing exactly what you want tested. They are testing both the feature and the integration of the feature within the site or app. There are two types of testing documents: 1. Feature testing document 2. User-case testing document Feature testing document For every feature on your site or app, a testing document should include: » The action the user does? » The expected result? » What is considered passed/failed for the issue? User-case testing User-case testing lists a flow you expect the user to go through and what is expected at every point. Having a user-case testing document will help you test the expected flow your users will go through on your software. This test the integration of the various features. You should come up with as many user-case flows as you can to ensure testing multiple options. The third type of testing, and often the most performed type of testing is exploratory testing. This type of testing doesn't require any documentation (except for documenting bugs). It basically enables your testers to browse your software freely, clicking and viewing anything they chose in any order they want. Have as many testers as possible The more testers you have, the more likely you'll find really good and valuable bugs. Each tester has a different method and eye, so each one sees different bugs. In addition, it is recommended to test on as many platforms as possible. Desktop and mobile (phones and tablets). Desktop users account for 45% of users, while mobile users account for almost 52%. And while tablets are in use by only about 3% of users, you still want them to have a good experience.

Source: GlobalStats statcounter In addition, test different operating systems, browsers and different versions of each.

Source: GlobalStats statcounter If you can afford external testing, I highly recommend Applause. They are expensive, but well worth their weight in gold. If you can't afford external testing, have a team of friends and family click every button. You'd be surprised what they find and how it varies. The larger the team, the more coverage you'll get for operation systems, browser, and overall environment. Use development software Any bugs you find need to be recorded. This is important for numerous reasons. First of all, it enables proper tracking. This will ensure every bug found is taken care of at some point. It will also enable prioritization of your work. Having proper bug tracking also means that when a tester finds a bug, they fill in all required fields and you and your developers have all the necessary information to recreate and fix the bug as quickly as possible. It will later ensure that the re-test of the bug is identical to the original test, thus ensuring the bug was properly fixed. Finally, having a bug tracking system will help you create sprints and manage your workflow and workload of your development and testing teams. Development software is great for managing your workflow. You can build user stories, prioritize your tasks, create sprints to manage workflow and create reports to manage your workload and timelines. Development software is also great for tracking bugs. There are quite a few development software tools out there. Personally, I recommend working with Atlassian's Jira. It costs $10 a month for up to 10 users, which is great for low budget projects. It's really worth it. And will grow with you. Atlassian has more tools for project management that integrate seamlessly with your development software (such as Bitbucket code repository). Test components as well as integrations Whether you have testing documents or not, it is imperative to test each component separately and then test the integration of all components. Component testing means you're checking each element in your software, or on your site, to ensure it is functioning as expected. Integration testing means you're checking that when you added components, you didn't break anything else. You're also checking that the integration works as expected. For example, let's say you have an onsite chat that enables your users to chat with each other on a specific page. The chat may be an off the shelf component that works great, but when you embedded it on your site, you need to ensure it behaves as defined and that it didn't break other things on the page. If you don't have the budget, team or time for both component and integration testing, forgo the component testing and focus on the integration testing. The integration testing will usually cover the most expected functions of the components. Fix & retest Don't forget to retest. You've taken the time to test your site or app. You've gotten feedback and know where the pitfalls are (at least some of them). Ideally, you've set some time aside to fix the bugs and even to retest, But what if your deadline to go live is tomorrow (or yesterday). Now what? Consider what bugs were found. Prioritize the critical bugs from the nice to have issues. If you've used a bug tracking system, you can mark priorities and add time estimates for each bug. This way you'll have an estimate as to how long you need to fix all the bugs, or the critical ones. Don't be afraid to push the deadline if your products isn't up-to-snuff. Retest the bug itself. But don't forget to retest the interaction of the element fixed with the rest of the site/app. One fix can break something else. Remember, ensuring your users have a great experience when they visit your site, or use your software means you're raising the chance of turning them into loyal clients. For more from Irit Levi visit her website day-by-day.biz