QA is responsible for making sure an application does what the user expects and the product owner intends. The skills for such responsibilities are mostly nontechnical in terms of what it takes to make software work.
Can we agree on that much? Actually, nevermind agreement. This is a fact. No consensus is required. Making sure that I can login to a website requires none of the skills that are required for implementing login functionality. I don't need to know where any information is stored, how the system compares the credentials and decides to permit or reject a login attempt. I just don't as a QA person.
But if I'm going to automate a test, I need to manage the state of the data. I need to know the state of the data at all times because if I don't know the state of the data, I can't have any reasonable expectations about an automated test will do. In test automation, there are a few strategies regarding data. On is to completely refresh the database with a known set of data each time a test is run. The amount of time involved in this strategy might be fine for small applications with limited amounts of data, but what is more likely is that there is a big steaming pile of data because we're automating tests. No one who wants, and can afford, automated tests is building a teeny tiny application that does almost nothing. There's a good chance you need someone who can write code to insert and remove data from the data store for each test that runs.
When it comes to managing this big steaming pile of data, do you want QA Joe to know all about databases and how to control them on the minute level of inserting and cleaning up data? Not if you want QA Joe to do QA Automation. If QA Joe knows how to control data that well, chances are he'll be DBA Joe really soon. Likewise when it comes to standing up a QA Environment with reusuable test code that isn't incredibly brittle. That QA Joe will become Architect Joe before long. Why? Because those jobs pay pretty well, and they have the honor of being understood as distinct responsibilities.
QA Automation must rely on the the experts of the system to assist in creating the environment and managing its data. Manual QA doesn't require this because manual QA is not done by simple robots. Manual QA can assess the state of data in the system and usually perform a test that does not falsely identify bugs because of bad data.
If QA is going to automate tests, QA can not be boxed in and only given other QA people to coordinate with. There is a distinction.
Can we agree on that much? Actually, nevermind agreement. This is a fact. No consensus is required. Making sure that I can login to a website requires none of the skills that are required for implementing login functionality. I don't need to know where any information is stored, how the system compares the credentials and decides to permit or reject a login attempt. I just don't as a QA person.
But if I'm going to automate a test, I need to manage the state of the data. I need to know the state of the data at all times because if I don't know the state of the data, I can't have any reasonable expectations about an automated test will do. In test automation, there are a few strategies regarding data. On is to completely refresh the database with a known set of data each time a test is run. The amount of time involved in this strategy might be fine for small applications with limited amounts of data, but what is more likely is that there is a big steaming pile of data because we're automating tests. No one who wants, and can afford, automated tests is building a teeny tiny application that does almost nothing. There's a good chance you need someone who can write code to insert and remove data from the data store for each test that runs.
When it comes to managing this big steaming pile of data, do you want QA Joe to know all about databases and how to control them on the minute level of inserting and cleaning up data? Not if you want QA Joe to do QA Automation. If QA Joe knows how to control data that well, chances are he'll be DBA Joe really soon. Likewise when it comes to standing up a QA Environment with reusuable test code that isn't incredibly brittle. That QA Joe will become Architect Joe before long. Why? Because those jobs pay pretty well, and they have the honor of being understood as distinct responsibilities.
QA Automation must rely on the the experts of the system to assist in creating the environment and managing its data. Manual QA doesn't require this because manual QA is not done by simple robots. Manual QA can assess the state of data in the system and usually perform a test that does not falsely identify bugs because of bad data.
If QA is going to automate tests, QA can not be boxed in and only given other QA people to coordinate with. There is a distinction.
