Software testing 10 best practices

Not only will you get to check for responsiveness and get a complete look and feel of how the app should appear and function on the mobile device, but you also get to see errors and bugs that the simulator might miss. Ensure that you are testing on all devices with platforms that you are developing the app for. Target Device Selection — Create an optimal mix of simulator testing and physical device testing on different models to maximize test coverage.

When you follow an Agile approach to your mobile development process, you will already have been practicing an iterative process to both your development and testing activities. The advantage of going Agile is that, in each cycle, you are identifying bugs that you can fix immediately, as opposed to waiting till the whole app is done, where it becomes hard to not just locate the bug, but also to remove it.

It is vital to test for both code and functionality, as you move through various sprints of development. The people using your mobile app are very much human. While automating mobile testing can be applied to certain components of the app to save time in identifying bugs, critical manual testing is still not to be ignored.

It gives you a very reliable idea of the user experience your future user will have from it and you get to look at the app from a different angle which allows you a whole new perception. This will further help you in refining and improving the final product. The goal should be to combine an effective testing strategy, traditional best practices and an effective automated testing tool, in order to minimize costs associated with regression testing. Battery consumption is a vital component of user experience.

Given the extensive usage of smartphones, people are quick to delete apps that drain too much of the battery — so make sure that you are making your app as battery friendly as possible. Organize the process to be as convenient for them as possible. The simpler the testing requirements you create for them the better. Any type of software developed has its User Documentation UD.

UD is a guide or a manual on how to use an application or a service. So, make sure you test your user documentation as well. Manuals for your software can also be tested by a team of end-user testers.

It is also a good practice to include user onboarding in your app. User onboarding consists of a set of methods to help users adapt to the interface, navigation, and guide through the app in general. For example, check Canva — a designer tool for non-designers. If you really want to improve the quality of your software, then automated testing or using automation tools to run the tests is definitely worth taking into consideration.

According to the World Quality Report by Capgemini, Sogeti, and Micro Focus, two of three key trends are increasing test automation and widespread adoption of the Agile methodologies.

Test automation saves time, reduces human errors, improves test coverage and test capabilities, does batch testing and parallel execution. Here are main cases when applying automated testing enhances the process:. To reach a perfect mix in testing, read out material on how to strike a balance between manual and automated testing.

There is a wide variety of automation testing tools. They can be both open-source and commercial. To choose from the variety of software, read our comparison of the biggest test automation tools or the full Selenium review. While automated testing can be employed within traditional Agile workflows , it is also a part of DevOps methodology and continuous integration practice. Continuous integration CI is a development practice that requires engineers to integrate the changes into a product several times a day.

A good practice is to combine the CI with the automated testing to make your code dependable. Bamboo, Hudson, and Cruise Control are open source tools that allow for introduction of continuous integration in your environment. Continuous delivery CD is considered an evolutionary development of the Agile principles. This method means that you can release changes to your customers quickly in a sustainable way. CD allows the commitment of new pieces of code when they are ready without short release iterations.

Generally, you automatically deploy every change that passes the tests. This is achieved by a high level of testing and deployment automation. CI and CD practices require continuous testing which brings test automation to the next level.

Read our article about continuous delivery and continuous integration to learn more. With all the obvious benefits of testing automation, it still has certain limits.

The main idea of exploratory and ad hoc testing is human creativity. Both of them require little to no documentation, limited or no planning, and both are somewhat random, discovering unusual defects or defects that are not covered in the scope of other, structured, tests. So, exploratory testing is a process of investigating a product with no predetermined test cases to examine how this product actually works.

To uncover bugs, it demands experience, intuition, and imagination from testers. Exploratory testing is conducted on the fly, with a test being designed and executed immediately. Then the results are observed and used to fix possible bugs and design the next tests. Using this technique, the system can be assessed quickly, getting immediate feedback and discovering areas for further testing. The ad hoc testing is the most spontaneous and least formal method of testing based on error-guessing technique.

Such chaotic checking can help detect defects that are hard to find with formal tests and are hard to reproduce. However, results of ad hoc testing are unpredictable and, well, random. These two above methods have a lot in common and are often confused.

However, there are some differences. The best strategy would be complementing automated testing with exploratory and ad hoc testing. This way you can increase testing coverage, improve user experience, and come up with additional testing ideas.

If you still wonder how to improve software testing, make sure your quality objectives are measurable, documented, reviewed, and tracked. The best advice is to choose metrics which are simple and effective for your workflow.

The CISQ Software Quality Model defines four important aspects of software quality: reliability, performance efficiency, security, maintainability, and rate of delivery. Additionally, the model can be expanded to include the assessment of testability and product usability. This indicator defines how long the system can run without failure.

The purpose of checking reliability is to reduce application downtime. You can measure reliability by counting the number of bugs found in production , or by reliability testing, specifically, load testing , that checks how the software functions under high loads.

It could also be regression testing which verifies the number of new defects when software undergoes changes. Performance efficiency means the responsiveness of a system to execute any action within a given time interval. Performance efficiency can be measured using the following metrics:. Security is the capability of a system to protect information against the risk of software breaches and to prevent the loss of information. You can count the number of vulnerabilities by scanning the software application.

The number of found vulnerabilities is a positive or negative measure of security. Maintainability is the ability of the system to modify software, adapt it for other purposes, transfer it from one development team to another, or meet new business requirements with a degree of ease.

A very simple metric of code maintainability is to check the number of lines of code in a feature or even the entire application. Software with more lines of code is harder to maintain. You can also use the software complexity metrics such as cyclomatic complexity to measure how complex software is. More complex code is less maintainable. The rate of delivery.

The number of software releases is the main metric of how frequently new software is delivered to users. Consider reading our piece on main Agile development metrics to broaden your view on this topic. A good bug report will help make software testing more efficient by clearly identifying the problem and in this manner navigating engineers towards solving it.

It must be a cornerstone and an efficient form of communication between a QA specialist and developer. A badly written report can lead to serious misunderstanding. Here are the guidelines for an effective bug report:. Provide solutions if possible. The document must include not only the bugs scenarios but also provide solutions for them, i. Reproduce a bug before reporting it.

When reporting a bug, you want to make sure it is reproducible. Include a clear step by step instruction of how to reproduce a bug. Make sure you specify the context and avoid any information that can be interpreted differently. In case a bug is reproduced periodically, it is still worth reporting.

A bug report must be clear enough to help developers understand the failure, including information about what QAs see, and a statement of what they expect to see.

It should detail what went wrong. Clarity also entails addressing only one problem per task. Include a screenshot of the examples of a failure highlighting a defect. This simplifies the work of an engineer who fixes the issue. Consider adding a bug summary.

A precise bug summary helps determine the nature of the bug much quicker, reducing fixing time. Source: discuss-gurock. The latest automated testing tools have built-in integration with bug-tracking systems.

They can automatically report the bugs and track their status. Test management tools, or systems, are software products that help QA teams structure and manage the testing process. They can:. Typically, open source tools are a good option for smaller companies. Here is a brief overview of a few popular platforms with good functionality. Whatever tool you choose, using test management systems can increase productivity by organizing the process, supporting communication, and visualizing progress.

If you want your company to be competitive and achieve a winning position in the IT industry market, you must produce very high-quality products. Improving the quality of software products will have the biggest overall impact on your business and its financial performance.

Consequently, your quality strategy should cover all key aspects: effective planning, a test-oriented quality management approach, and a dedicated QA team.

Yes, I understand and agree to the Privacy Policy. You have given a nice idea and suggestion in this post. In the end we all need to satisfy our clients through our work. So thank you for the post and keep sharing.

This is an excellent topic and perspective to consider. Global businesses are increasingly becoming digital and so are their various consumer-facing offerings and applications. Hence, the software development process has to evolve and get much more inclusive and agile rather than just working with a definite flow.

You might like to check out this post on … Read more ». I enjoyed this topic. This is great in-depth content with lots of information added to it. I am sure this article about software testing would be helpful for many. As a software testing professional for nearly 5 years, I know the exact value of this article. Hope to get this type of content many more.

Great post. Usually the bottleneck is not quite where you thought it was. With the usual note that adding timing code always changes the performance characteristics of the code, making performance work one of the more frustrating tasks. Smaller, more tightly scoped unit tests give more valuable information when they fail—they tell you specifically what is wrong. A test that stands up half the system to test behavior takes more investigation to determine what is wrong.

Generally a test that takes more than 0. With tightly scoped unit tests testing behavior, your tests act as a de facto specification for your code. Ideally if someone wants to understand your code, they should be able to turn to the test suite as "documentation" for the behavior. On the other hand, code is the enemy, and owning more code than necessary is bad.

Consider the trade-off when introducing a new dependency. Shared code ownership is the goal; siloed knowledge is bad. At a minimum, this means discussing or documenting design decisions and important implementation decisions. Code review is the worst time to start discussing design decisions as the inertia to make sweeping changes after code has been written is hard to overcome. Generators rock! Programming is a balancing act, however. Over-engineering onion architecture is as painful to work with as under-designed code.

Design Patterns is a classic programming book that every engineer should read. Fixing or deleting intermittently failing tests is painful, but worth the effort. Generally, particularly in tests, wait for a specific change rather than sleeping for an arbitrary amount of time. Voodoo sleeps are hard to understand and slow down your test suite. Always see your test fail at least once. Put a deliberate bug in and make sure it fails, or run the test before the behavior under test is complete.

And finally, a point for management: Constant feature grind is a terrible way to develop software. Not addressing technical debt slows down development and results in a worse, more buggy product. Thanks to the Ansible team, and especially to Wayne Witzel , for comments and suggestions for improving the principles suggested in this list. Want to break free from the IT processes and complexities holding you back from peak performance?

Download this free eBook: Teaching an elephant to dance. The idea of comments degenerating over time into "lies" is one that I agree with. At one former job, working alongside the esteemed Mr Foord the article author , we were all in the habit of simply referring to all comments as "lies", without forethought or malice.

As in "The module has some lies at the top explaining that behaviour. This is like saying that new tires end up being worn out, so drive only on smooth roads and only downhill, so you don't have to use tires.

Lazy developers find excuses for not writing comments. The fact is that there is no such thing as perfectly readable code. What's readable to one person is a complete ball of mud to others. To force someone to read code just as a form of documentation is an irresponsible idea that is inefficient and assumes that only developers of a certain level should be looking at your code.

I don't understand what you are saying in point number 2 - the first sentence, "tests don't need testing" seems to stand in contradiction to point A map without a legend and labels is "readable and self-documenting" but unnecessary torture. Comment the start and end of logic blocks and loops. Comment "returns" with values. If you don't like comments, a good editor will strip the lies from your eyes.

Every software developer should read this article. It can really help them improve their coding habit. These software engineering rules and testing best practices might help save you time and headaches. Image by :.

Get the highlights in your inbox every week. Programming and development. Topics Programming. About the author. Michael Foord - Michael Foord has been a Python developer since , spending several years working with C and Go along the way.