What to do when QA team has no test case documentation?
I just started working as a QA Automation Engineer to a certain company which provides ERP and CRM services. However, I recently discovered that they have no test case documentation for the testing they do, and just report bugs. I am now having a hard time to automate their tests because I have no reference, what do you think I should do?
automated-testing test-automation-framework qa-role qa-process
New contributor
add a comment |
I just started working as a QA Automation Engineer to a certain company which provides ERP and CRM services. However, I recently discovered that they have no test case documentation for the testing they do, and just report bugs. I am now having a hard time to automate their tests because I have no reference, what do you think I should do?
automated-testing test-automation-framework qa-role qa-process
New contributor
add a comment |
I just started working as a QA Automation Engineer to a certain company which provides ERP and CRM services. However, I recently discovered that they have no test case documentation for the testing they do, and just report bugs. I am now having a hard time to automate their tests because I have no reference, what do you think I should do?
automated-testing test-automation-framework qa-role qa-process
New contributor
I just started working as a QA Automation Engineer to a certain company which provides ERP and CRM services. However, I recently discovered that they have no test case documentation for the testing they do, and just report bugs. I am now having a hard time to automate their tests because I have no reference, what do you think I should do?
automated-testing test-automation-framework qa-role qa-process
automated-testing test-automation-framework qa-role qa-process
New contributor
New contributor
edited 3 hours ago
Niels van Reijmersdal
22k23176
22k23176
New contributor
asked 5 hours ago
Kit SabadoKit Sabado
161
161
New contributor
New contributor
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately.
Or you could just write the testcases yourself based on the documents and SUT you have. Maybe there is a business capability map for which you can write happy path tests or maybe you have userstories with acceptance criteria for which testcases can be written. Or you go through the SUT and look what it should do.
I usually take the approach that the test code is the test case and with a BDD framework you can more easily create test cases that are pretty readable and can be understood by the developers and management.
In conclusion: write the test cases yourself, focus on bug regression and happy path. use a bdd framework to write testcases. get help from people who know the features and created the bugs.
see also http://xunitpatterns.com/TestAutomationRoadmap.html
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
add a comment |
Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports.
- Write automated happy-path tests for the highest risk features first.
- Create a test-automation debt backlog, prioritize with stakeholders
- In the meantime write automated tests for past critical defects as well.
- Train developers to write automated tests for new features to stop fill the gap of missing tests.
add a comment |
Test Automation is not about having or not having test cases, which you can automate. This is about you deciding on test automation strategy. I wrote a blog post, which has several links and ideas where to start. I hope it helps.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "244"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Kit Sabado is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38976%2fwhat-to-do-when-qa-team-has-no-test-case-documentation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately.
Or you could just write the testcases yourself based on the documents and SUT you have. Maybe there is a business capability map for which you can write happy path tests or maybe you have userstories with acceptance criteria for which testcases can be written. Or you go through the SUT and look what it should do.
I usually take the approach that the test code is the test case and with a BDD framework you can more easily create test cases that are pretty readable and can be understood by the developers and management.
In conclusion: write the test cases yourself, focus on bug regression and happy path. use a bdd framework to write testcases. get help from people who know the features and created the bugs.
see also http://xunitpatterns.com/TestAutomationRoadmap.html
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
add a comment |
You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately.
Or you could just write the testcases yourself based on the documents and SUT you have. Maybe there is a business capability map for which you can write happy path tests or maybe you have userstories with acceptance criteria for which testcases can be written. Or you go through the SUT and look what it should do.
I usually take the approach that the test code is the test case and with a BDD framework you can more easily create test cases that are pretty readable and can be understood by the developers and management.
In conclusion: write the test cases yourself, focus on bug regression and happy path. use a bdd framework to write testcases. get help from people who know the features and created the bugs.
see also http://xunitpatterns.com/TestAutomationRoadmap.html
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
add a comment |
You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately.
Or you could just write the testcases yourself based on the documents and SUT you have. Maybe there is a business capability map for which you can write happy path tests or maybe you have userstories with acceptance criteria for which testcases can be written. Or you go through the SUT and look what it should do.
I usually take the approach that the test code is the test case and with a BDD framework you can more easily create test cases that are pretty readable and can be understood by the developers and management.
In conclusion: write the test cases yourself, focus on bug regression and happy path. use a bdd framework to write testcases. get help from people who know the features and created the bugs.
see also http://xunitpatterns.com/TestAutomationRoadmap.html
You could tackle that from two directions. You could take the bugs and ask the people who opened the bugs how to reproduce them. There is your testcase. You can probably start automating regression tests for these bugs immediately.
Or you could just write the testcases yourself based on the documents and SUT you have. Maybe there is a business capability map for which you can write happy path tests or maybe you have userstories with acceptance criteria for which testcases can be written. Or you go through the SUT and look what it should do.
I usually take the approach that the test code is the test case and with a BDD framework you can more easily create test cases that are pretty readable and can be understood by the developers and management.
In conclusion: write the test cases yourself, focus on bug regression and happy path. use a bdd framework to write testcases. get help from people who know the features and created the bugs.
see also http://xunitpatterns.com/TestAutomationRoadmap.html
edited 4 hours ago
answered 4 hours ago
globalwormingglobalworming
1917
1917
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
add a comment |
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
+1 for the test code should become the test-cases, make sure they are readable.
– Niels van Reijmersdal
3 hours ago
add a comment |
Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports.
- Write automated happy-path tests for the highest risk features first.
- Create a test-automation debt backlog, prioritize with stakeholders
- In the meantime write automated tests for past critical defects as well.
- Train developers to write automated tests for new features to stop fill the gap of missing tests.
add a comment |
Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports.
- Write automated happy-path tests for the highest risk features first.
- Create a test-automation debt backlog, prioritize with stakeholders
- In the meantime write automated tests for past critical defects as well.
- Train developers to write automated tests for new features to stop fill the gap of missing tests.
add a comment |
Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports.
- Write automated happy-path tests for the highest risk features first.
- Create a test-automation debt backlog, prioritize with stakeholders
- In the meantime write automated tests for past critical defects as well.
- Train developers to write automated tests for new features to stop fill the gap of missing tests.
Mindmap all the high-level features of the application together with business owners. Go over the map with stakeholders (e.g users, developers, managers, and sponsors). Do a risk assessment with some key people, maybe also analyze brittle areas based on defect reports.
- Write automated happy-path tests for the highest risk features first.
- Create a test-automation debt backlog, prioritize with stakeholders
- In the meantime write automated tests for past critical defects as well.
- Train developers to write automated tests for new features to stop fill the gap of missing tests.
answered 3 hours ago
Niels van ReijmersdalNiels van Reijmersdal
22k23176
22k23176
add a comment |
add a comment |
Test Automation is not about having or not having test cases, which you can automate. This is about you deciding on test automation strategy. I wrote a blog post, which has several links and ideas where to start. I hope it helps.
add a comment |
Test Automation is not about having or not having test cases, which you can automate. This is about you deciding on test automation strategy. I wrote a blog post, which has several links and ideas where to start. I hope it helps.
add a comment |
Test Automation is not about having or not having test cases, which you can automate. This is about you deciding on test automation strategy. I wrote a blog post, which has several links and ideas where to start. I hope it helps.
Test Automation is not about having or not having test cases, which you can automate. This is about you deciding on test automation strategy. I wrote a blog post, which has several links and ideas where to start. I hope it helps.
answered 11 mins ago
kriscorbuskriscorbus
301111
301111
add a comment |
add a comment |
Kit Sabado is a new contributor. Be nice, and check out our Code of Conduct.
Kit Sabado is a new contributor. Be nice, and check out our Code of Conduct.
Kit Sabado is a new contributor. Be nice, and check out our Code of Conduct.
Kit Sabado is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Software Quality Assurance & Testing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38976%2fwhat-to-do-when-qa-team-has-no-test-case-documentation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown