What are the cases for a test suite that verifies an app compiled to run on Mac/Unix/Windows10 does the job of copying files (not folders) from one place to another (not necessarily over a network). Not over WEB/FTP.

Note1: Copy between machines that are different O/S are not catered for, mainly interested in "local" type copy test cases.

Note2: The app is a GUI app, so has no command line, we are not testing the GUI, and not testing the API, but are testing the functionality and interaction.

Here is what I have so far:

  1. zero length file
  2. destination file has/must archive bit cleared after the copy (Windows)
  3. destination file is read-write
  4. source file has write locks open should prevent the copy process starting.
  5. program shall lock the file against writes
  6. destination file would exceed storage quota checks regularly
  7. destination file disappears while saving to it?
  8. source file contains file-streams (Windows Alternate Data Streams)
  9. source file is an executable (OS dependant outcomes??)
  10. source filename is case sensitive/filesystem case sensitive
  11. source file gets a (1) suffix if destination exists
  12. source filename with a “(1)” suffix gets renamed to “(1)(1)” if destination with (1) exists etc…
  13. destination file would exceed path length check
  14. source filename with no “filetype” (OS dependant treatment)
  15. source filename with multiple filetype “extensions” or suffixes handled
  16. source file contains virus signature (that may trigger a personal filesystem firewall??)
  17. source file conflicts when a destination folder of same name exists must append a (1) suffix. (OS dependant??)
  18. UTF8 (no BOM mark) and Unicode text files
  19. simultaneously transfer multiple files using the GUI
  20. cancel an individual file transfer
  21. stop all file transfers
  22. resume unsupported : Resuming a transfer is out of scope here, but any ideas are welcome.

I'm quite sure I have missed a good few interesting or valuable ones mainly because I am more familiar with Windows than the 'Unix' filesystems. Comments or answers are both equally welcome.

3 Answers 3

  1. Destination is a device (e.g. in Windows copy file.txt con) would print file to a console since con is console device
  2. Copy from one file system to another (for example copy from your local Fat32 to mounted flash drive formatted as NTFS)
  3. Copy to a folder by symlink name (Linux and probably other OSs)
  4. Preserve file attributes (depending on requirements)
  5. Transfer several files when some files would fail copying and some others would not.
  6. Transfer several files to source with the same name (if app allows to set individual names when you do bulk copy)
  • Damn, the internet is hot today. I googled for hours to get any kind of near decent list, and here you go. A whole bunch of them I would never have thought of. I'm sure more will crop up, but this is good enough to build a good testing strategy on, thanks.
    – Conrad B
    Commented Feb 18, 2021 at 20:08

For Windows / MacOS you should also take into consideration reserved filenames


The Windows operating system can use two different file systems, Protected-Mode File Allocation Table (FAT) file system and the New Technology File System (NTFS). The two systems have much in common, but the characters permitted in a file or folder name may differ. In the conventions listed below, it is true for both systems unless otherwise specified. Specifically there are cases where NTFS does not have the limitations (see note below).

The following characters are invalid as file or folder names on Windows using NTFS: / ? < > \ : * | " and any character you can type with the Ctrl key

In addition to the above illegal characters the caret ^ is also not permitted under Windows Operating Systems using the FAT file system.

Under Windows using the FAT file system file and folder names may be up to 255 characters long

Under Windows using the NTFS file system file and folder names may be up to 256 characters long

Under Window the length of a full path under both systems is 260 characters

In addition to these characters, the following conventions are also illegal: Placing a space at the end of the name Placing a period at the end of the name

The following file names are also reserved under Windows: com1, com2, com3, com4, com5, com6, com7, com8, com9, lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, lpt9, con, nul, and prn

Mac OS

Since Mac OS X is build on top of UNIX there are a few inherent conventions that OS 9 users may not expect. Because of this, migrating certain files and folders from OS 9 to OS X may cause unexpected behavior.

The only illegal character for file and folder names in Mac OS X is the colon ":"

File and folder names are not permitted to begin with a dot "."

File and folder names may be up to 255 characters in length

Source: https://kb.acronis.com/node/39790


This seems to be an engaging area of validation with lots of possible use-cases. Being a part of a software testing service, sharing additional below scenarios that can be included in the QA testing:

  • Individual Bulk file transfer for each file formats (Let say, If images/documents/videos are supported, then test bulk transfers for each format like bulk .png files, bulk .doc files as an individual transfer operation)
  • Bulk transfer consisting of mixed file formats
  • Large file sizes
  • Validate the transfer operation when invalid/non-supported file formats present (zip files if they are not-supported)
  • Validate the handling of transfer operation if the connection breaks in-between when the transfer process is going on
  • Transfer of system files which are auto-created in the system drive during the installation of software (Like automation setups, project files)
  • Validation when destinations system runs out of storage during the bulk transfer operation
  • Canceling a transfer operation followed with restarting the whole process and checking how duplicate files are handled
  • Deletion of few transferred files from the destination and re-transferring them
  • Presence of corrupted files in the batch
  • Transfer of password-protected files
  • Also very valid inputs, I shall at some point update the question to include and group these better without renumbering, since duplicates are starting to appear. I did ask this in another forum and received a few other answers that deserve adding. So just dropping his note here to remind me to do a tidy up.
    – Conrad B
    Commented Feb 26, 2021 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.