Hello guys, today I will post about some steps that you can follow to create the QA area from the scratch.
1 – Make questions like:
- Do you have any written scenarios ?
- Who is writing the scenarios and in what phase ?
- QA team will need create its own scenarios, what phase may the team do that ?
- Who will need to look the scenarios, just QA and dev area ?
- Who will run the tests DEV and QA only ?
- How the application is working ?
- What are the critical scenarios ? Like, what are the scenarios which will crash the functions/app/process ?
- What are the most used scenarios (Like create an account…) ?
- What are the scenarios which are more unstable, like if you change a simple thing you will need to test this scenario every time ?
- What are the most repetitive tests ?
- Do you need run the regression everyday ? before every release ? (regression tests, exploratory tests, monkey tests, stress tests, performance tests) every time after a push ? (smoke tests)
- Do you have a QA environment ?
- If you are in a mobile/web project, remember to make these questions:
- What are the most used devices/browsers/OS ?
- What are the most unstable devices/browsers/OS ?
- What are the most used versions on these browsers/OS ?
- What are the most unstable versions on these browsers/OS ?
- If you are in a mobile project:
- The app is hybrid, native or web app ?
- If you are in a web project:
- Is this site responsive ?
- Do you have a process of QA, like SCRUM, Kanban ?
- If you find a bug in a task, do you return the task or create the bug to be fix separately ?
2 – Understand what will be first priority and until where you will reach (Like performance tests, integration ui tests, etc…), so you can have a big picture of the project
3 – Remember that if you are using BDD, it is just 3 layers (Don’t expose your code)
4 – Decide what are the scenarios that must be in the regression (Priority). What are the most repetitive tests ?
5 – Use tags for all the type of scenarios, like smoke, regression, iOS, android, manual. Even manual tests should be in the features inside the automation project
6 – Don’t use too many complex steps in your scenarios
7 – Try to re-use steps so you don’t need waste time
8 – Use examples
9 – Regression tests – Automated tests
- Choose the tool, do a POC with different frameworks
- On this POC, choose the most simple and important scenario (E.g. Create an account)
- Considerate the language which the developers are using (You never know when you will need help)
- Distribute the right level of tests between unit (70%), integration (20%) and manual tests (10%) – new functions
- Include the Automation in your development
- Decide if you need to create the automation project in the same or separated project
- Use CI since the beginning
- Decide what must to have in the report
- Choose a good report from the beginning
- Structure of Scripts. Create or follow a Code Style Guideline
10 – Form a team of automation and equality the level of knowledge. Make some meetings to prepare people in your team to use the tool with wisdom.
I think it’s pretty much this. Sorry guys if I forgot something… If I remember anything else I will update here. Thank you ! Feel free for comments and your opinion always ! See you next week !
3 thoughts on “10 Steps to setting up the QA Area”
Could you help me to clarify why should we have the test level is 70% or Unit, 20% of integration and 10% of manual? And how can I measure these portions. I see that the ideal is mentioning to the Test Pyramid.
Yes, it’s a pyramid in the level of solid tests. Unit tests is on the bottom because you will certify that at least every single piece inside it’s your own is working properly. What means in the next level (integration) you don’t need to to test every single integration. Integration tests it’s a group of unit tests, which means you will have less tests, because you are grouping the integrations which contains many unit tests to test (I am not sure if I was clear here, I hope yes haha) and Manual tests it’s more focus in new or less important functionality. Like, you don’t have time enough to automate something that is new in the release, you do manual tests on this new function, or if this function is not important enough, or it is not something that will crash the application you do manual tests, because this test is not so valued to spend some time doing the automation.
Yes, I don’t know if you use BDD, but if you use you can count the number os the scenarios that you have for one specific function, integration and manual tests using the tags. You can use a report to do this graphics for you, so you will know how many tests of each type you have 🙂
I hope I’ve helped you !
It’s very helpful for me to have your answer. Yes I’m doing the BDD for our projects.
Thank you a lot.