Four Unconventional Ways of Improving Software Quality
It is an established fact that the task of ensuring software quality starts from the beginning of the software development and doesn’t rest entirely on the shoulders of only one role but on every team member. Also, the absence of bugs doesn’t necessarily translate to software quality.
Implementing quality practices and processes before, during and after development is the first step in the right direction. Listed below are some techniques that you should consider in ensuring the quality of your application:
Session-based Exploratory testing
Session-based exploratory testing (SBET) involves having time-boxed uninterrupted sessions where testers perform exploratory testing on an application focusing on a specific aspect, module or feature of the application. SBET creates a very flexible atmosphere for the tester to creatively explore the product and possibly exhaust all scenarios that the tester can invent rather than being restricted to previously formulated test cases. SBET is also highly recommended for products that are undergoing active development and changes; as it provides the team with the opportunity to take a breather to uncover scenarios that have not been covered in the automation suites, and also to catch user experience related issues.
To get the most of this technique, it is advisable to implement the following:
- Time boxed session with a duration of 45–90 minutes with short breaks,
- Availability of test charter before the session. Test charter is a document that specifies the scope, objectives/goals of the test session
- Get fresh eyes from testers who are new to the application to get new perspectives, insights and suggestions.
- Access to the product manager or a colleague from the business to answer questions
- Bugs, issues and suggestions encountered during the session should be noted and logged.
- Results and observations should be discussed and shared with other stakeholders.
Polish week
Polish week is an unpopular technique employed by some software teams whereby a week is dedicated to “polishing” software products, improving features, user experience and fixing bugs. All polishing efforts during this week are particularly focused on user-facing related tasks. This serves as a reminder and indicator that the team’s work is ultimately in the service of users. All teams including Dev, QA, DevOps, Designers etc, are focused on this polishing activity. Setting a week aside for these tasks gives the team time to work on features and bugs that normally wouldn’t get addressed due to other prioritized tasks.
To fully take advantage of the benefits of Polish week,
- Larger roadmap projects might have to be put on hold briefly for the week to help the teams focus on improvements to the product
- Improvement tasks/tickets should have been created and groomed beforehand and story points also allocated to the tasks to maximise the period to work on tasks
- Deployment of these improvements should be done and completed by the end of the week
- Polish week could be done every quarter or after a couple of months of software development
Get feedback about your application periodically
Obtaining feedback is another way of obtaining firsthand insight as to how users are using your app, if it helps them solve their problems and if they find it easy to use. Reviewing and analyzing this feedback can also throw some light on what aspects you need to direct more effort especially if there is a trend observed in the feedback reports received about the application. Some of the ways you can obtain meaningful and actionable feedback include;
- Reviewing the bugs or issues logged by customers or users over a period.
- Meeting with Customer Support teams to know the pain points of users/ customers
- User observation; ie closely watching and observing actual users interact with your app. This is usually a quick way to obtain an objective view of the app. To get objective results, try as much as possible to be unobtrusive as possible while taking notes. This can be achieved remotely using tools such as Hotjar, FullStory, Lookback.io etc
- User surveys: Providing forms to customers to seek their opinions as they voluntarily share their experience with the application and what they think needs to be improved.
Do note that getting feedback is just half of the job to be done. The goal is to improve the overall quality of your software and what you do with this feedback determines the result you get and how far you go with the goal you are trying to achieve
Automatic Static Code Analysis:
Static Code Analysis are tools that help to continuously inspect code quality by performing automatic code reviews to detect bugs, code smells, and in fact security vulnerabilities in some cases. Many of these static code analysis tools provide extensive code quality reports that cover the number of code bugs, coding standards, duplicated code and code coverage. They are usually very easy to set up and capable of integrating seamlessly with most CI/CD (Continuous Integration and Deployment) tools. Many of these tools offer both open-source and paid versions and are capable of supporting many programming languages. Examples of popular static code analysis tools include SonarQube, Embold, Veracode, Brakeman just to mention a few.
Static code analysis should not be seen as a replacement for code peer reviews. Employing both is highly recommended because it helps overall code quality as the code undergoes multiple checks and assessments. Applying static code analysis tools early in software development enforces development standards and good practices in the development team from the beginning, not when the codebase is very large and complex.
Doing the same thing over and over again while expecting the same result is insanity — Albert Einstein.
Why not try something different, something unconventional?
Happy Testing!
