After a few years of being a software developer, I want to make a list of some tips and examples that you can include in the definition of done.
I will keep an eye on the comments to add new items if necessary.
Keep in mind that the best DoD is that one that has been agreed upon across the team.
The order is meant to be logical from a dev perspective, and some of them are front end specific:
It could seem obvious but is not. Read the user story after you think everything is done, in case you have forgotten something.
It would be also well-formatted, complying with the style guide used by the team.
Try not to break other functionalities while developing new features. If the changes affect other parts, validate all of them.
It is common to have different roles (administrators, consumers, publishers, etc). Test the functionality against all of them.
Sometimes everything seems to be ok, but there are still some errors in the console. If you are working in the frontend, maybe you
Be sure to check that all translations are ok and every i18n file contains the right language.
If the feature requires some new markup, it has to be responsive. Check also that there is no horizontal overflow.
I wrote an article just about this.
Always keep in mind that what you do should be accessible and meet the WCAG standard.
Validate the HTML and CSS rules. You can use the W3C Markup Validation Service.
Test always at least two browsers. Knowing the most used browsers for your app/website should help to run specific tests in that ones.
Sometimes we need to measure how much value is being delivered to the user.
Try to break the new feature. Test for basic and non-basic functionality issues. What if you fill forms with empty inputs, incorrect types, or too long texts?
Also, if I'm developing a new endpoint and, I don't receive all the data? (try to use schema validations).
Try to cover at least 85% of the lines, and the majority of the branches. Expects have to make sense, and tests descriptions as well.
In our team we use Cypress, and sometimes it is required to make a new e2e test for some parts.
Very important if we don't want to break the application as a whole.
Very few projects that I've worked on had performance tests. But they are important and this could apply in some cases.
Artillery saved my life in the past.
Ohhh this is hard but always having in mind security could save yours. We use SonarQube and Kiuwan.
Maybe this user story requires doing something after everything is deployed. Or maybe there is a model change that has to be notified to other
teams that depend on us. We use RFCs, but the user story should reflect those situations.
It depends on the side you are working on, but documentation is your ally. Also meet the backend and frontend standards like Swagger, Storybook,
or a basic Readme file.
At the end of every sprint, you should be doing a demo to show and review new functionalities. Once you have everything ready, just make a screenshot
before continuing with another user story.
So you came through all of that, well done. Now leave other team members, ideally, more than two, review your work.
Three persons think more and better than just one.
If you can have a QA team in charge of that part, perfect. They should give you the ok.
I've been in some teams in which ones the PO had to give his approval to continue.
And if everything seems ready, just be sure the pipeline is passing and there is no problem with the build process as well.
So these are some ideas that maybe can fit in your definition of done. What do you think? What is yours? Tell me in the comments if you want.
I hope you’ve learned something new, and thanks for reading! If you've liked it, please share it!
More here! ismaelramos.dev