My team has got a dedicated QA for 4 developers (I know there is no such role in a Scrum Team, but I am writing here to provide information).
Now, the problem is: we are heading to Sprint end and she is on sick leave.
There are a few user stories that need to be tested. Can the Business Analyst or other Team members test and close the user stories even though they don't have a testing background?
The user story is closed when the acceptance criteria is met. So if any team member can check if the story acceptance criteria passed or not, then yes they can close the tickets.
If any technical background/setup needed, like creating automated tests, test data..etc. then it's more dependent on the setup or the person who have it on their machine.
In this answer I'll start by explain what's the role of acceptance tests (AT) in the context of user stories give an example and finalise by answering your question.
To note this answer is adapted from the content provided by the Coursera course "Principles of Agile Software Development", from Instituto Tecnológico de Aeronáutica.
Acceptance tests
The acceptance tests are the result of the conversation between the Product Owner (PO) and the development team. In our case, they will look to see if the user story is satisfied (just looking at the result), not being interested how the product was coded (it is assumed / expected the code to have quality).
Another thing worth mentioning is that acceptance testing is implemented during Sprint. During Sprint, the development team has to develop the user story and make use of these ATs, so it's highly advised to have the acceptance tests before starting to code. Still, there may be some user stories that one can't set good acceptance tests at that time (for instances in Sprint zero). In certain situations, the development team may also suggest the PO new acceptance tests. If he/she accepts to be the owner of that test and say that it is valid, then it is valid, otherwise it is not.
Acceptance testing will help the PO and the development team know if what they developed for the user story is correct or not (that's what the acceptance test is for).
Generally speaking, the development team, in that sprint, already have the ATs and US they will implement. The first thing they do is implement the user story; then, they code the acceptance tests.
Example of AT
Imagine that you have a video streaming application to run on smartphone, tablet or computer. When you are watching a video streaming program and, for example, your mobile phone battery runs out, you would like to resume on a tablet, or another mobile phone, so without forcing you to enter the menu and go through many steps to get to the point you were.
We want to solve this problem, that is, when you switch from device to device when you are watching video streaming in this application that is going to be made, you start again from exactly the point you had stopped before, no matter why you had stopped before, you will start over from that point.
The user story can be as following
As a user of video streaming (role), I want to start watching program on my mobile device, then I want to be able to resume the same program on another mobile device at the point I stopped at the previous one (goal), so that I don't miss a second of the show I was watching (benefit).
I get off device, get on the other and already have access to the point where I had stopped, no matter why I stopped.
Some of the acceptance criteria to make sure that the US presented is working or not can be:
Scrum Team without testers?
In Scrum exists only three roles, Scrum Master, Product Owner and Development team. In your case, the person currently sick is part of the development team.
The development team is responsible to develop the user stories and implement the ATs (in certain cases also create ATs which then need to be approved by the PO).
So, anyone that's part of the development team can test if what was developed for the user story is correct. Once this point arrives, there's a ceremony called Sprint Review / Demo. In this ceremony, development team demonstrates to the PO and other interested parties what was implemented for the specific USs. The PO is the decision maker, and can then say "This US is done" or he/she is also free to change his/her mind and say "This US didn't go as i thought, the direction isn't the one i want and we need to do some changes" (considering not done).
When developing software in Scrum, QA is a skill, not a role. So, the answer to your question is: who has those skill in the team?
No SubTeams in Scrum
The Scrum Guide says that there are no subteams in Scrum. This means that for any skill, there may be an expert in the team that usually does the work, but the team shares the responsibility for ensuring it is done. For something as common as QA, I would definitely encourage any team to have a number of people with capability in that skill and if they don't have it currently, do some cross-training.
It's Still a Skill
Scrum says anyone on the team can do any task, but it does not guarantee that they'll be good at it. Testing is still a skill that people work many years at developing. I've seen teams take this too far and dismiss testing as something anyone can do and then they get rid of their QA expert and are left with a group of people with a very slow skill level in testing and as a result, their quality sucks.
Your current situation
Realistically, unless you have an extra person with some testing experience, you may be stuck - you may not have anyone else in your team with enough skill in testing to reach your desired level of quality. If this is the case, my best advice would be: don't sweat it. You will probably have a bunch of items that aren't done. It's a painful learning opportunity, but one you can address. The person will help with this items when they feel better and how to avoid the same thing happening again will make a great retro topic.
You're absolutely right that there is no such role as QA on a Scrum Team. Scrum does not recognize titles or sub-teams. However, Scrum does recognize that members of the Development Team may have specialized skills.
My first recommendation, for the immediate concern, is that the Development Team members take responsibilities for ensuring that the work is tested according to the team's Definition of Done. That is, the Product Owner or Scrum Master should not be performing the testing (unless this person is also a member of the Development Team). This should make the entire Development Team accountable for getting the selected work to Done.
My second recommendation, for the long term, is to improve the team's cross-functionality. In response to this particular instance, the dedicated QA specialist should be teaching the necessary QA and testing skills to the rest of the team. The others may not be experts in the subject matter, but they should be able to pitch in and help in cases where the workload to test is high or the QA specialist is unavailable.
The only other consideration is if you need to have independent testing. I'd point out that in most cases, except for the most critical software, independent testing is most likely not needed. However, if your organization practices this, it should be moved outside of the Scrum Team. That is, the Scrum Team should take responsibility for fully testing the work within the Sprint timebox and the independent testing should be a process checkmark and find only minimal issues with testing.
