December 25, 2021

How I use ManualTesting.dev and Vercel in my daily work as a software developer

We built the ManualTesting.dev to help people like us increase confidence in delivering better code. Being a software developer is not easy, but it can be fun. We are responsible for writing code, but there are many other activities we have to perform before we release the code to the world, e.g. review requirements, checklist, review bugs, test, test and test.

Let me introduce my way of developing apps with massive help from this tool.

Preparation work

Usually, I receive requirements or specs for the feature or new application. In most cases, it's a text document or spreadsheets describing desired functionality. I review the document with project owners, and when all is agreed and approved, I attach the files with accompanying designs to a suite.

Preparation work

Work with suites

I'm used to creating separate suites for each feature to test regression in the application in future releases. I move all requirements to the newly created suite with all notes, requirements, suggestions. It will help me to track the development and testing. Sometimes, original specs might change or are not sufficient, and then if we need to update requirements, we quickly update the suite to keep track of all changes in one place.

Work with suites

It's an excellent method to keep track of all test cases in one place. We might find some edge cases worth putting in the suite during the development process so testers can be aware of all of them.

We love emojis. That's why we use emojis often in our test cases, so we can easily emphasize which test cases are more critical.

Development

First thing before I start coding, I create a test instance and attach the newly created suite.

Development

Also, because it's an early stage of the development, I define the configuration for the test to: "Development". It will be helpful in the future testing phase, where all reported issues use test configuration to describe in which environment the problem happened.

set-fields.ts
const handleSetField = (field: string) => {
  const currentFields = new Set(fields);
  if (currentFields.has(field)) {
    currentFields.delete(field);
  } else {
    currentFields.add(field);
  }

  setFields(currentFields);
};

Having access to requirements and test cases is a great way to track the development progress. We can use the "In progress" status to inform other team members which part of the requirements I am currently working on.

Development

Bugs

After finishing the development, it's time to test the new feature. I'm creating a duplicate of the current test I used for development. When ready, I set up a new configuration for the new test and choose the environment to perform the test.

During the testing process, I can easily use the review status property to switch each test case from "In Progress", "Skip", "Pass", "Fail". When I see a bug, I change the review status to "Fail" and add details about the issue. The reported problem is automatically visible to all team members to be aware that there is already a reported bug.

Bugs

Fixing

After the first round of testing, we are ready to start fixing the reported issue. It's easy to open the problems screen and see all issues grouped by suites. When we finish fixing bugs, I can go back to the test and review test cases previously reported as failed.

Testing on Staging

When we finish all testing, we are ready with the release. The process differs from company to company. However, it's simple in our company: we merge the feature branch to develop branch. We use Pull Request wherein the description we attach the test results generated by ManualTesting.dev.

Testing on Staging

When all is in place, we are ready to merge it. Vercel automatically triggers the deployment process, and within a few minutes, the new instance is ready for another round of testing, but this time on the staging environment. Again to speed the process up, we duplicate the existing test but with a new configuration pointing to a staging environment.

Testing on Staging

We repeat the testing against the staging environment, and we repeat all steps to fix bugs and attach test results to a final PR to merge code to the production.

Deploying to Production

Before the final merge, we review the "Release Checklist", which describes essential steps before the release. It is crucial because we aim to forget about some action to perform in our daily routine. The checklist helps us not to skip them.

Deploying to Production

Reporting and sharing

We can review the report about the release, find work on testing, who reported bugs, and who fixed them. Also, we can see how much time the whole process took us.

I hope this gives you a better understanding of how you and your team can use ManualTesting.dev to improve the development process and code confidently.

no credit card required, cancel any time