...the two problems we encountered with scrum (stuff never gets tested, no metrics to show when project will be complete) seem to exist just as much with Kanban ...
This is fairly simple to address, as your true problem is not Scrum or Kanban, but rather the assumption that a Scrum or Kanban task board in Jira is enough to give you the insight (metrics) you need.
You also need (a) a high level product backlog/roadmap that can be used for estimating and reporting completion and (b) a reliable test process, within your control.
Use a product or epic roadmap to estimate and report when the project will be complete:
How close you are to completion can be monitored, estimated and reported in Jira by looking at the % of the user stories (or epics) completed in relation to the total number of user stories (or epics) in the original product requirements. Without a checklist of any kind there is no way you can estimate completion and/or total costs.
Tasks can’t be moved to “done” because things don’t get tested:
The definition of done has to be in your control. Either hire a test manager to make sure it gets done and is in with your control, or remove the “externally tested” step from your board. Board metrics are only useful if they measure your performance in a process you control, so that you can predict future performance for tasks in a process you control.
You sort of answered your own question when you said:
... we're not really doing scrum ...
An underlying assumption behind both the Scrum board and a Kanban board is that the tasks can and shall be completed by the team/resources using the board. A velocity is only a useful metric if can be used to estimate the future performance of those same team resources, against a known set of goals.
The Kanban board assumption is that the tasks are of a similar size, without much uncertainty, and helps you measure throughput. Again, knowing your throughput and using it to estimate completion is only useful if it reflects yourknowing your throughput per resource and can be used to estimate completion or cost for a set number of similar tasks, when “done” is within your control.only helpful in estimating completion if it gives you your team’s throughput per resource. An estimation of completion or cost for a set number of similar tasks must assume that “done” is within your control, and that throughput will be fairly consistent.