How do you track your online database development progress?

On point Paul. Quite a good number of programmers and testers do not take time on the EP (Equivalence partitioning) and BVA (Boundary value analysis).

It has been my experience that any development project, whether front-end, middle-tier or back-end, either application coding or database architecture, is predominantly planning. Whether its Agile/Scrum or traditional Waterfall, I would say that at least 60% of any (well run) project is planning, stakeholder and user involvement and gap analysis well before a first line of code is written. During the course of the analysis stage, timeframes and milestones can be developed, discussed and agreed upon. Agreement on scope (as well as what is not in scope) needs to be stablished. Make the planning and design process flexible enough to accommodate some changes and (more likely) a certain amount of scope crepe.

Maintaining version is critical as requirements change all the time and to keep a track using any version control tool would help in reviewing or rollbacks. This would also helps in retrospective meetings in Agile as if the Sprint fails to address the requirements properly then there is a backup always available. We all have been there and seen how version control have helped us??

Consider testability already during the design phase. Small, well defined and functionally pure units (without side-effects such as file- or database system access) are easily testable. Thus, move all logic into such units and create respective unit tests. Impure parts of the code (e.g. DB access, logging setup etc.) are easiest to place in wrapper classes / functions that are calling the well tested functional business core. Designed well, these parts can still be integration tested, e.g. by letting them connect against a temporary database instance with automatic rollback mechanisms.

Insist on documentation, and make sure documentation is part of the project plan. You can write the most beautiful code, and know exactly how it works. But it is vital, from both an operational perspective as well as extensibility, the the data sourcing (ETL) and code process flow, as well as the details of the code, are cleanly documented, both in code comments as well as external documents. Code comments are usually concise (sometimes too much so) while external documents can capture both textual and graphic representation of the code and process flows as well as external data extraction and data manipulation. Insist from both yourself and members of the time to take the time to document the code, the ETL and testing results.

I am a big proponent of formal code reviews. No matter how good the developer, no matter how skilled they are, no matter how many times the developer has tested (both Unit and Integration testing) it ALWAYS helps to have another set of eyes checking the code and the test results. There are usually QA teams that will take the code and perform both installation and functional testing. The QA testers should not only be able to duplicate your original testing, but look at how your code handles extremes. This is especially true with interactive (GUI) applications: how are missing or out-of-range data handled? In smaller groups, code review sessions among team members would contribute to fewer problems being passed into production.

Code review helps share knowledge amongst the team, and it reduces individual's stress and responsibility. Showing other team members your code, or sending it for code review, ensures that others have seen the new functions you created, and can utilize them. This reduces code duplication, especially on new projects. Reducing stress and individual responsibility is also important. If a developer makes changes, and pushes them straight to Production - any issues are all on that developer. That's a lot of stress, and the reward is no more than if it was reviewed and tested properly. If one developer wrote it, one reviewed, a QA tested it, and smoke tests cleared - the responsibility is shared amongst all involved. That's a lot less stress!

Reviewing your code helps you learn from your mistakes, improve your skills, and receive feedback from others. There are different methods to review your code, such as self-review, peer review, or code review tools. You can use platforms, such as CodeClimate, Codacy, or SonarQube, to analyze your code quality and performance.

You are on point Paul. Quite a good number of developers do not take time on BVA (Boundary value analysis), EP (Equivalence partitioning). A 2nd, 3rd and 4th eye over the code/test is crucial.