Learn More About the Code without Looking at Code, Part 2

In my previous post, I covered things you can learn from the database that can tell you more than the unfamiliar code and help prevent creating bugs when maintaining unfamiliar code. But, if you don’t have access to the data directly, there are other options. As a bonus, these options help you understand more about the software and how users actually use the software to accomplish something. This can help you present your feature consistently with the rest of the software. Below are a few ways to glean information.

Bug Repository

Review existing bugs submitted for the area you are working on (new work) or areas like your feature. Screenshots, videos, and explicit text strings show where users are adding data in the system, onscreen user tips for requirements, and validation information (required fields, validation messages).

For example, if you are changing the password requirements, you might know about setting the password on account creation and password reset. Reviewing some existing bugs, you see a screenshot of a password reset after the password expires. That way, you learn the password can be null if your account was created before passwords were required. You also learn that you must update the validation text to include the change.

Create a Trial Account

In addition to giving you a bird’s eye view of the application, you can add data that you know the state of. And, you can learn about ways the data is limited, cleansed, or validated that may apply to your code.

  • Like reviewing bugs, creating an account will show you field labels, and more.
  • How are dates formatted for the user and numbers (like phone numbers) displayed?
  • How are lists sorted? Is there pagination? (See Alphabetical? Chronological? Best Ways to List Data in Your App by
  • Does any information persist as you navigate around?
  • Does the app truncate text fields after some number of characters?
  • Are there any special calculations, such as taxes?
  • Are there any due dates? If so, is there a grace period behavior?

Training Videos/User Documentation

Look at training videos and user documentation for the existing software. You’ll see how the application is intended to be used and may find regression test cases to cover. While reviewing these materials, look for any cyclical events (calendar/fiscal year, payroll, tax cycles) that occur. Teams often forget about these until the software changes are almost done, and then the missing requirement(s) rear their ugly heads.

YouTube/Customer Reviews

Users may have posted videos or reviews on how to do something in the app more easily or shared any hacks they’re using. This will give more insight into what to keep and things you may want to change or avoid in your updates.

Other Internal Support Teams

Ask for contacts to other teams supporting ancillary parts of the app. Ask Customer Support if they know of bugs in the area of the app you are working on. Then ask Operations about any cron jobs (batch jobs like emails, data purges after a specific number of days, clearing connections on regular intervals, required password resets every 30/60/90 day, etc.) that are run to support the app. Then consider if that has any impact on your work. Do they use a different Content Delivery Network (CDN) for different regions? Also ask them if there are any other systems integrated with the app to consider, such as push notifications.

Sometimes you are tasked with making changes in unfamiliar code and it can be difficult to understand where your code might break other code. I hope these suggestions help you learn more about the software to help reduce introducing regression issues.

Conversation

Join the conversation

Your email address will not be published. Required fields are marked *