5 Key Software Testing Steps Every Engineer Should Perform

In recent years, the term “left shift test” has entered the common parlance of software engineering. But what does that mean? Simply put, this means performing more software testing during the software development phase to reduce defects and save the business from costly bugs.

Left shift testing is often used to describe the increased involvement of quality assurance (QA) engineers during the development phase with the goal of detecting defects as early as possible, before software engineers hand over the issue. program to QA for further testing. Most of the time that means developing and running more automated UI and API tests.

However, there are some basic and essential software testing steps that every software developer should take before showing their work to someone else, whether for left testing, formal testing, ad testing. hoc, merging and integrating code, or just calling a colleague to take a quick look. The goal of this basic test is to find obvious bugs that arise immediately. Otherwise, you enter an expensive and unnecessary cycle of having to describe the problem to the developer, who must then reproduce, debug, and fix it, before trying again.

Here are the essential software testing steps that every software engineer should perform before showing their work to someone else.

1. Basic functionality test

Start by making sure every button on every screen works. You should also make sure that you can enter plain text in each field without crashing the software. You don’t have to try all the different click and character combinations, or edge conditions, because that’s what your testers do, and they’re really good at it. The goal here is: don’t let other people mess with your work if it will crash as soon as they enter their own name in the username field. If the feature is designed to be accessible through an API, you should run tests to make sure the core API functionality is working before you put it to more intensive testing. If your basic functionality test finds something that isn’t working, that’s okay. Just tell them that it doesn’t work, that you are aware of it, and that they shouldn’t bother trying it. You can fix it later, but don’t leave any surprises in it.

2. Code review

Another pair of eyes looking at the source code can uncover many issues. If your coding methodology requires peer review, complete this step before submitting the code for testing. Remember to do your basic functionality tests before reviewing the code, however.

3. Static code analysis

There are tools that can perform analysis on source code or bytecode without running it. These static code analysis tools can check for many weaknesses in the source code, such as security vulnerabilities and potential concurrency issues. Use static code analysis tools to enforce coding standards and configure these tools to run automatically as part of the build.

4. Unit tests

Developers will write unit tests to ensure that the unit (be it a method, class, or component) is working as expected and will test on a range of valid and invalid inputs. . In a continuous integration environment, unit tests should be run every time you commit a change to the source code repository, and you should run them on your development machine as well. Some teams have coverage goals for their unit tests and will fail a build if the unit tests are not extensive enough.

Developers also work with dummy objects and virtualized services to ensure that their units can be tested independently. If your unit tests fail, fix them before letting someone else use your code. If for some reason you can’t fix them now, let the other person know what went wrong, so it doesn’t come as a surprise when they encounter the problem.

5. Single-user performance tests

Some teams integrate load and performance testing into their continuous integration process and run load tests as soon as the code is checked in. This is especially true for back-end code. But developers also need to look at the performance of a single user on the front end and make sure the software is responsive when using the system only. If it takes more than a few seconds to display a webpage from a local or emulated (and therefore responsive) web server, find out what client-side code is slowing things down and fix it before letting someone else do it. see.

Finding the right balance

Take the time to run as many tests as possible before you pass your code on to someone else, because leaving obvious bugs in the code is a waste of your colleagues’ time and that of your colleagues. Of course, you’ll need to find the balance between writing code and testing that’s right for you. “Here’s the mix that worked for me,” said Igor Markov, LoadRunner R&D manager at HP Software. “40% of my time is spent designing and writing code; 5% code review and static code analysis; 25% to unit tests and integration tests; and 30% basic functionality testing and performance testing for a single user. “

Leaving obvious bugs in the code isn’t going to do your reputation any good, either. “A developer who doesn’t find the obvious flaws will never shine,” Markov continued. “Developers need to produce software that is functional and easy to use. Nobody wants developers who just do pure coding. What has helped me develop my career is the fact that I have always invested more time in designing, reviewing, and testing my code than in writing it. ”Producing software functional and easy to use requires exactly this kind of balance How do you balance your time between designing, reviewing and testing code?

Keep learning