Are you writing a test specification?
There are various ways to write test specifications, such as making them as test specifications or as test code, depending on the company.
I think it is common for large, historical companies to create test specifications in Excel files.
When editing by multiple people, I think it is also common, at least in Japan, to use suffixes such as _latest, _latest_20230103, _latest_5 to manage versions.
I would like to know the best practices for handling Excel files, but I have no good idea at the moment, so I decided to use a program to make the differences visible in a Git repository and manage them.
However, if you put the Excel file directly into Git, the difference lines are not clearly displayed. TortoiseGit and other tools will also show you the difference, but can you make pull requests and comments there? You usually see the difference on the web page of the repository anyway. And CSV is also a bit unsatisfactory. There are tools that can edit CSV in table format like spreadsheet, but the diff display of the repository should be a simple character-delimited text, which is not easy to read. So, I thought about managing test cases in Markdown. If you can manage it in text, you can also use *nix commands. You can write test cases even if you don’t have Excel, and if you can convert it to Excel, no one will have any trouble. (The tool I used can also convert to CSV, TSV.)
Continue reading Managing test specifications with Git: Creating Excel from Markdown
