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?
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.
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 test cases 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 user stories with acceptance criteria for which test cases 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.
Write the test cases yourself, focus on bug regression and happy path. Use a BDD framework to write test cases. Get help from people who know the features and created the bugs.
See also: xunitpatterns article.
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. Main idea is that you start with strategy: what do you want to automate, what kind of information you want to collect, how will you know that you automated the right thing. If you automate without strategy, you are building technical debt. I hope it helps.
As detailed in
- Learn about the domain
- Capture the existing functionality using a tool such as Cucumber or RSpec to document it
- Make real tests described in English
- Create Smoke, Happy and Sad cases