jcarranza's solution will also work; my preference is still to create a role and use that role to assign permissions. What happens to that user/login when they quit and a replacement gets hired in? Or a second person needs their permissions so they can be a backup or secondary person to do that job?
Assigning roles is, in my opinion, a lot simpler. Especially when you have multiple tables to work with for the permissions.
For example, if your QA team needs access to tables A, B, C and D and your QA team is 1 person right now. Giving that person access to tables A, B, C, and D is easy. Then they get a second person on the team, not a big deal adding them again. Now 10 years later, the team has 50 people in it and they now need access to table E, F and G. That is now 50 users you need to add permissions for 3 tables. That will be a huge pain in the GUI, and a lot of scripting to do in TSQL.
Now, lets say you used a role called QA. That role has access to tables A, B, C and D and initially has 1 user in it. Jump forward 10 years and you have 50 people in that role and need to add tables E, F and G? That's easy - add those 3 tables to the role and the users will have access.
Now to make management of this even easier - Create a QA security group in AD and grant that access to the database as a login and user on the database and put it in the QA role. AD group gets the new users and no changes need to be done on the SQL side! Your source of truth for users is AD. User changes departments from QA to IT, they lose access to those tables as soon as the AD admin makes the change.
Also, future DBA's (and future you) will appreciate that you had the foresight to use roles rather than individual permissions. Imagine someone asks you to "replicate" permissions from user A to user B. That is trivial with role-based permissions, but a pain in the butt with object-based permissions.