1. Software Developer Roles
1.1. Stakeholders
1.1.1. Group members: - customers - users - UX researchers
1.1.2. Primary functions: - provide requirements
1.1.3. send requirements to leadership
1.2. Leadership
1.2.1. PROJECT MANAGEMENT
1.2.2. Group members: - project managers - product managers - software engineering mgmt
1.2.3. Primary function: - gather requirements - provide requirements to software engineers
1.2.4. Organizational functions: I. planning/project management A. division of labor for SE's i. module segmentation B. scheduling deadlines
1.2.5. divides labor between software engineers; holds standup meetings with software engineers
1.3. Software Engineers
1.3.1. Group Members: - Sr. Developer - Jr. Developer - Front/Back End Developer - Domain Experts
1.3.2. Primary Functions: - coding
1.3.2.1. codes may pass or fail
1.3.3. Organizational Functions: - Status Meetings (Scrum, Standup) - Communication with leaders/stakeholders - Escalation of issues
1.4. QA Testers
1.4.1. Group members: - User Acceptance Testers
1.4.2. Primary Functions: - Testing software in whole or in part
1.4.3. Organizational Functions: - Communicating results - Reporting issues - Recommending changes
2. 6. Test Closure or Test Cycle Closure
2.1. calling testing team meeting and evaluating cycle completion based on test coverage quality, cost, time, critical business objectives, and software
2.1.1. entry criteria
2.1.1.1. Phase 5 deliverables
2.1.2. activities
2.1.2.1. stages of test closure
2.1.2.1.1. 1. check planned deliverables
2.1.2.1.2. 2. close incident reports
2.1.2.1.3. 3. handover to maintenance
2.1.2.1.4. 4. finalize and archive environment
2.1.2.1.5. 5. document system acceptance
2.1.2.1.6. 6. analysis best practices
2.1.3. deliverables
2.1.3.1. test lead publishes test closure report after completing exit criteria and testing phase
2.1.3.1.1. Test closure report and test metrics report
2.1.3.1.2. TEST SUMMARY REPORT - doc
3. 5. Test Execution
3.1. Test team executes test cases based on planned test cases
3.1.1. entry criteria
3.1.1.1. Phase 4 deliverables
3.1.1.2. test plan or test strategy document
3.1.1.3. test cases
3.1.1.4. test data
3.1.2. activities
3.1.2.1. execute test cases
3.1.2.1.1. testing team executes test cases based on prepared test planning & prepared test cases in prior step
3.1.2.1.2. ensure entry criterion is met
3.1.2.1.3. types
3.1.2.2. if any cases are blocked due to defect, then test cases are marked as Blocked
3.1.2.3. executing the code and comparing the expected and actual results
3.1.2.3.1. mark status of test cases
3.1.2.4. if test case fails, then corresponding defect is reported to dev via bug tracking system
3.1.2.4.1. fill traceability metrics to track progress
3.1.2.5. assign bug ID for all failed and blocked test cases
3.1.2.6. do retesting
3.1.2.7. track the defects to closure
3.1.2.8. final execution
3.1.2.8.1. log defects in case or discrepancies
3.1.3. deliverables
3.1.3.1. TEST CASE EXECUTION REPORT- doc showing ratio of passed executions to all executions (code coverage)
3.1.3.2. DEFECT REPORT- document from manager giving feedback on defect status
3.1.3.3. RTM
4. 4. Design Phase (Test Environment Setup or Design Phase)
4.1. Test environment is set up based on hardware and software environment list; developers or customers provide the environment - "HOW" to test
4.1.1. entry criteria
4.1.1.1. Phase 3 Deliverables
4.1.1.2. Can be started during 3. Test Design
4.1.1.3. test plan
4.1.1.4. application architectural
4.1.1.5. smoke test cases become available
4.1.2. activities
4.1.2.1. analyze the requirements and prepare the list of software & hardware required to set up test environment
4.1.2.2. setup the test environment
4.1.2.2.1. execute smoke test cases to test readiness of test environment
4.1.2.3. setting up distinct areas
4.1.2.3.1. test PC setup- different browsers for different testers
4.1.2.3.2. creating test data for test environment
4.1.2.3.3. setup test server- supports applications
4.1.2.3.4. network
4.1.2.3.5. bug reporting
4.1.3. deliverables
4.1.3.1. test environment ready with test data
4.1.3.2. result of test smoke cases
5. 2. Planning Phase or Test Planning
5.1. First step of the testing process; test manager or lead will determine estimated cost and effort for the project; prepare test plan based on requirements; it is decided which test engineers are going to work on what test, how long will it take, and which bug tracking tools they use, and which automation tools they will use for this release; - considered the most important part of the STLC
5.1.1. entry criteria
5.1.1.1. Phase 1 Deliverables
5.1.1.2. this phase is influenced by: requirements, organizational test strategy, risk analysis/risk management
5.1.1.2.1. Risk analysis/assessment (- gives us the optimal amount of information to test (we cannot test everything)
5.1.2. types of tests
5.1.2.1. 1. unit tests
5.1.2.1.1. smallest unit of measurement tests
5.1.2.2. 2. API testing
5.1.2.2.1. tests APIs created for application
5.1.2.3. 3. Integration testing
5.1.2.3.1. individual software modules are combined and tested as a group
5.1.2.4. 4. system test
5.1.2.4.1. conducted on a complete integrated system to evaluate systems compliance with its specified requirements
5.1.2.5. 5. Install/Uninstall testing
5.1.2.5.1. focuses on what customers will need to do to install or uninstall or set up or remove new software successfully
5.1.2.6. 6. Agile Testing
5.1.2.6.1. testing system using agile methodology
5.1.3. activities (in steps)
5.1.3.1. 1. analyze the product
5.1.3.1.1. must learn the product thoroughly before testing it
5.1.3.2. 2. develop test strategy
5.1.3.2.1. test strategy document is a high level document usually developed by a test manager
5.1.3.2.2. defines project's testing objectives and the means to achieve them
5.1.3.2.3. determines testing effort and costs
5.1.3.3. 3. define the test objective
5.1.3.3.1. test objective- overall goal and achievement of test execution; which is to find as many software defects as possible/ensure software being tested is bug free before its released
5.1.3.4. 4. define test criteria
5.1.3.4.1. rule whereupon test procedure or test judgment can be based; two types
5.1.3.5. 5. resource planning
5.1.3.5.1. identify the activities and resources needed to help meet objectives and write a detailed summary of all types of resources required to complete project tasks
5.1.3.6. 6. plan test environment
5.1.3.6.1. test environment- set up of hardware and software on which the testing team will execute test cases
5.1.3.7. 7. schedule and estimation
5.1.3.7.1. include earlier estimation and schedule to test planning
5.1.3.8. 8. determine test deliverables
5.1.3.8.1. list of all documents and tools that have to be developed and maintained in support of testing effort
5.1.3.8.2. test manager determines the effort and cost estimates needed to validate the application and for the entire project
5.1.4. deliverables
5.1.4.1. TEST PLAN + EFFORT ESTIMATION- docs that covers all future testing activity
5.1.4.1.1. test plan guides thinking
5.1.4.1.2. test plan is based on requirements analysis
6. 1. Requirements Phase or Requirements Analysis
6.1. General Info Tester needs: What areas of the product need to be tested? What functionalities should we focus on? What bug types does the customer want fixed? What features are off-limits to testers? Everything within scope should be tested.
6.2. Test Team studies + analyzes requirements from a testing perspective to understand the scope of this particular test
6.2.1. entry criteria
6.2.1.1. REQUIREMENT SPECIFICATION- doc that describes what software will do and how it will perform
6.2.1.2. application architecture- map of how software is assembled
6.2.2. activities
6.2.2.1. prepare list of questions + queries
6.2.2.1.1. Quality Assurance Team HAS to understand the requirements, they study the requirements from a testing POV, interact with various stakeholders
6.2.2.2. determine types of tests to be performed
6.2.2.2.1. depends on how many test cases they need to run
6.2.2.2.2. pair-wise testing/all pairs testing
6.2.2.2.3. orthogonal array testing
6.2.2.2.4. etc.
6.2.2.3. define testing focus/understanding the scope of the test
6.2.2.3.1. Test Team determines whether requirements are testable; collabs with stakeholders to plan mitigation strategy for any features that are not testable
6.2.2.4. list test environment details
6.2.2.5. Checkout automation feasibility
6.2.3. Requirements - documented need that product has to satisfy; both functional and nonfunctional
6.2.3.1. requirements are either functional or nonfunctional
6.2.3.1.1. functional- specifies what the system should do and when (i.e., send email when a new customer signs up)
6.2.3.1.2. nonfunctional- specifies criteria that can be used to judge how a system operates (i.e., Each page must load within 2 seconds)
6.2.3.2. Types of requirements
6.2.3.2.1. Business requirements
6.2.3.2.2. architectural and design requirements
6.2.3.2.3. system and integration requirements
6.2.3.3. create design based on requirements
6.2.3.4. information requirements sources
6.2.3.4.1. knowledge transfer from employees already working on project
6.2.3.4.2. knowledge transfer from PM, business analyst, project lead, and developers
6.2.4. deliverables
6.2.4.1. list of questions with answers
6.2.4.2. automation feasibility report
7. 3. Test Design or Analysis Phase or Test Case Development
7.1. testing team notes detailed test cases and prepares test data for testing, once test cases are ready, they're reviewed by peers or QA lead "WHAT" is to be tested?
7.1.1. entry criteria
7.1.1.1. Phase 2 Deliverables
7.1.1.1.1. identify testing conditions based on planning phase
7.1.1.2. factors that influence this phase
7.1.1.2.1. product complexity
7.1.1.2.2. levels and depth of testing
7.1.1.2.3. project and product risks
7.1.1.2.4. involved software development lifecycle
7.1.1.2.5. test management
7.1.1.2.6. skills and team knowledge
7.1.1.2.7. stakeholders availability
7.1.2. activities
7.1.2.1. develop a good test case: a good test case is effective in finding defects and covers most scenarios in the system under the test
7.1.2.1.1. 1. test cases need to be simple and detailed
7.1.2.1.2. 2. create tests case with end user in mind
7.1.2.1.3. 3. avoid test case repetition
7.1.2.1.4. 4. do not assume anything about the functionality and features of software application while prepping test case; stick to spec documents
7.1.2.1.5. 5. ensure 100% coverage
7.1.2.1.6. 6. test cases must be identifiable
7.1.2.1.7. 7. implement testing techniques
7.1.2.1.8. 8. self cleaning
7.1.2.1.9. 9. repeatable and self standing
7.1.2.1.10. 10. peer reviewed
7.1.2.2. ID which test case will become part of regression suite
7.1.2.3. take the sign of test cases before execution starts
7.1.2.4. Test team prepares REQUIREMENT TRACEABILITY MATRIX - doc that verifies whether test cases fulfill requirements
7.1.3. deliverables
7.1.3.1. test cases
7.1.3.2. test scripts (for auto testing)
7.1.3.3. test data
7.1.3.4. RTM