We are behind sprint schedule right now, bugs from Sprint 1 have taken over some time in Sprint 2, and the tasks for Sprint 2, though possible to still finish, won't have time to be tested.
Now, we are looking for ways on how to handle this. We are inexperienced to Scrum, and we are thinking that to keep up, have a longer Sprint 3. I'm not sure if that is the correct course of action, if you guys have a better suggestion, please answer away.
Sprints need to have a constant length, so you can best measure your velocity.
It's not the correct course of action (in as much as "correct" exists) to change the length of sprints to fit in the amount of stuff you originally thought you were going to fit in them.
You need to
1) Determine, in a restrospective, how to improve on having less bugs
2) Determine, in your Sprint 2 retrospective, what your velocity actually was, given your current bug rate, and plan Sprint 3 to have only the amount of tasks you can get done at that actual velocity.
There is no reason to think that you will have less bugs to fix in Sprint 3, so Sprints 1 & 2 are the best indication you have of what your velocity will be.
Now that you are getting some indication of your team's actual velocity, you also might want to replan the sprints to the "end" - see how many you need to get everything done at your current velocity. That is the schedule that you have, whether you like it or not. The only way you will do better is by improving your velocity: either reducing bugs as you go, or by some other means that you find in your retrospective.
Increasing the length of Sprint 3 won't help you one bit.