There is no one way to specify a use case. UML doesn't describe how to do it. Therefore, many authors have different ideas on how to do it. So, your idea to use partitions (you called them swimlanes) to represent Actors is valid, as long as it helps you to communicate the use case to your stakeholders.
However, that doesn't help you, when your lecturer has a different opinion. He or she might have good reasons for this statement. Probably it worked well in the situations he or she experienced.
Some authors suggest to use interaction diagrams. Since a use case describes how actors use a system, in other words, how they interact with it, this could be a good choice. The problem here is, that most people only know sequence diagrams of interactions, and they are not well suited to describe all the different ways the use case goal can be reached.
Therefore, many people use activity diagrams, even though officially they can't describe the interaction between actors and the system. They are in fact meant to describe the inner workings of a system (that could of course also be a system of people). So, your activity diagram officially means, that the activity invokes behavior at the actors. I don't think that was what you had in mind.
Since many people nevertheless use activity diagrams for describing use cases, I think your interpretation of partitions is not so far off. I personally think, partitions make live of the modeler unnecessarily more difficult and would not use them.
If you choose to use activities to describe use cases, it should be one activity per use case.