1. Do we have enough people for testing
1.1. YES: Great. Make sure they're available on schedule to write and execute tests
1.2. NO: Allocate people from other projects Hire new people Inform that QA activities will take more time according to the lack of capacity
2. Do you know all people from project team
2.1. YES: Great. Make sure you setup a connection between each other. Make sure you've chosen the best way of how to communicate
2.2. NO: Meet everyone who's in change of project activities
3. Does the process exist
3.1. YES: Great. Make sure you understand it
3.2. NO: At least make sure you know all the timings for QA activities: - When testing can be started - When testing needs to be finished
4. Have you agreed on priorities for issues
4.1. YES: Great. Make sure your work is always aligned to them
4.2. NO: Clarify what should be marked as Blocker/Critical/Major in your project
5. Do you know what kind of testing types you need to use
5.1. YES: Great. Make sure all test types are covered during test design
5.2. NO: Think about all possible types of testing
6. Have you agreed on bug template
6.1. YES: Great. Make sure everyone follows it
6.2. NO: Set up bug template to let everyone knows what and how needs to be specified in the bug
7. Consider the following heuristics: http://www.satisfice.com/tools/htsm.pdf http://www.satisfice.com/articles/hrbt.pdf
8. Does it worth to write automation
8.1. YES: Do we have skills for that
8.1.1. YES: Write coverage
8.1.2. NO: Training existing QA engineers or hire automation QA
8.2. NO: Forget about automation
9. Do requirements exist
9.1. YES: Test requirements. Check if they meet requirements for requirements. Check that that fulfil user expectation.
9.2. NO: Find test oracles of how software that you're gonna create should look and behave like
10. Do we have all required tools for testing
10.1. YES: Great
10.2. NO: Acquire tools
11. Do we have all required environments for testing
11.1. YES: Check if they're ready for testing
11.2. NO: Setup environments. Make sure they're ready for testing
12. PROJECT FEATURE TESTING
12.1. Is the feature dependent on other features
12.2. Is feature backward compatible
12.3. Design Test-Cases for feature
12.3.1. Choose regression set of test cases
12.3.2. Choose smoke set of test cases
12.3.3. Execute test-cases
12.3.3.1. Found a Bug for a functionality that you don't have test-case for - Add test case for it
12.3.3.2. Found a bug that prevent you from further testing - Open a Blocker bug and return feature for developers
12.3.3.3. Make sure each issue contains clear description including debug data
12.3.3.4. If developer can't recreate an issue - Come over and show him. Don't wait
12.3.3.5. Found a question that you didn't have before - Shoot it into the person who owns the requirements according to the communication style you have chosen before i.e. if you don't know if it's a feature or a bug
12.3.3.6. Report on testing activities
12.3.3.6.1. Make sure you add List off issues that was found in the report
12.3.3.6.2. If you haven't finished testing - Make sure you provide clear estimation of when testing is supposed to be finished
12.3.3.6.3. Make sure you described every blocking issue or problem you've met during testing
12.3.3.6.4. If any further action is required, make sure you specified which exactly
12.3.3.6.5. Test closure activities
12.3.4. Try to think about more cases using http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf
12.3.5. Prepare Test Data for test execution
12.3.6. Make sure you know who is the developer of the feature so you can assign all future bugs properly