Notes Flashcards
SDLC
Software Developmental Life Cycle - The process take to build / develop software from its initial conception to its release
QA - Quality Assurance
to assure the quality of an application or software system by testing through the development life cycle, and delivery of a bug/defect free product, making sure the software is built as expected
Business Owner
director of overall product
Product Owner
manager of a specific product
Stake Holder
anyone who has an interest in the product, someone with influence. the people involved in or affected by a project’s activities.
stakeholders can include: project sponsor, project team, customers, project manager, support staff, suppliers, opponents to the project.
Subject Matter Expert
Someone who specializes in the subject at hand, someone to consult with
Developers
develop the code
Business Analyst
gives the requirements along with the Product Owner, tells you exactly what you need to do
Architect
designs what the website/product should look like from looks to backend connections
Scrum Master / Project Manager
makes sure everyone is able to do their part successfully
Why are there bugs?
- inaccurate understanding of end user (customer) needs
- inability to deal with changing reqs
as dev team is building a lot of changes for requirements can be made and this leads to inconsistencies - software that is hard to maintain
- software and hardware can be incompatible
all software needs to be compatible to all hardware/platforms put out - late discovery of serious flaws
- lack of focus on quality
Requirements
What you want or desire from a system
what is wanted is specified
Functional Requirements
what you want the system to do
Non-functional requirements
are restrictions on the types of solutions that will meet the functional requirements
- usability, reliability, performance, supportability, compatibility, security
Use Case
a set of scenarios that describes an interaction between user and a system
User Stories
a very high level definition of a requirement, containing just enough information so that the devs can produce a reasonable estimate of the effort to implement it
- As a (role) I want to (something) so that (benefit)
ex: As a student I want to purchase a parking pass so that I can drive to school.
Test Cases
a specific interaction (design steps) that a tester will have in order to test a single behavior of the software
(manually going through the features and testing each use case or user story to check if all acceptance criteria are working)
Test Script
program/script written in a scripting/programming language to record/script specific interactions (design steps) that a tester will have, in order to test a single behavior of the software
When you use an automated language or tool to help you confirm if requirements are working.
Test Suite
(a folder) a collection of Test Cases / Test Scripts that are intented to be used to test a software
RTM
Requirements Traceability Matrix
a cross-reference between a test case document and the functional / design specification document
mapping between test cases and requirements
SMART: Requirements Guideline
Specific
Measurable
Attainable
Realistic
Time-bound
Test Case Components (TUPSIDOP)
Test Case Name
Unique Identifier
Pre-Condition
Step No.
Input
Design Steps
Output
Post-Condition
Test Artifacts
things we care about as a QA, the deliverables (test cases, test scripts, etc)
Unit Testing
testing each smallest individual module or unit of the application, normally performed by software test engineers
Integration Testing
Individual software modules are combined and tested as a group, taking two units that have been tested and testing the interface between them
Smoke Testing (Build Acceptance Testing, Build Verification Testing, Ad-Hoc Testing)
Making sure the build is ready to be tested further by testing the most important functionalities for each module
System Testing (End to End testing, System Integration Testing)
testing the system as a whole system, making sure the system meets all the functional and quality requirements
Functional Testing
Testing more detailed/functional behavior of the Application Under Test (AUT)
Positive Testing (Under Functional Testing)
Making sure the system does what its supposed to do
Negative Testing (Under Functional Testing)
Making sure the system does not do what its not supposed to do
User Acceptance Testing (UAT)
a user version of system testing, the customers and end users run the software in a “production-like” environment
Black Box Testing
testing everything you can see in a program / software (can be done at all testing levels)
White Box Testing
(Unit Testing) testing the code and behind framework, done by devs
Fundamental Testing Process
- Review Requirements
- Test Plan / Test Strategy
- Test Execution
- Report Results
- Perform Regression Testing
- Provide Sign Off
SDLC Phases
Initial
Analysis
Design
Coding
Testing
Delivery & Maintenance
Initial Phase
the project planning stage where you are gathering business requirements from your client or stakeholders. This phase is when you evaluate the feasibility of creating the product, revenue potential, the cost of production, the needs of the end-users, etc.
Analysis Phase
formally defines the detailed functional user requirements using high-level requirements identified in the Initiation and Feasibility Phases. The requirements are defined in this phase to a level of detail sufficient for systems design to proceed.
Design Phase
a stage where software developers define the technical details of the product. Depending on the project, these details can include screen designs, databases, sketches, system interfaces, and prototypes. Clients use these details to make final product design choices.
Coding Phase
includes system design in an integrated development environment. It also includes static code analysis and code review for multiple types of devices.
Testing Phase
In this phase, the developed software is tested thoroughly and any defects found are assigned to developers to get them fixed.
Retesting, regression testing is done until the point at which the software is as per the customer’s expectation. Testers refer SRS document to make sure that the software is as per the customer’s standard.
Delivery & Maintenance Phase
The maintenance phase of the software development life cycle is where the software is monitored to ensure it continues to function as it was designed to, and repairs or upgrades are performed as needed.
Software Development Methodologies
approach and strategy of developing a software application
Two Main Methodologies: Waterfall & Agile
Waterfall Method
top-down approach to building an application from ground up. Complete all the steps of the SDLC in order.
Waterfall Method Cons
Lack of flexibility, difficulty in predicting actual needs for the software, the loss of intangible knowledge between phases, discouragement of team cohesion, and the tendency to not discover design flaws until the testing phase.
Agile Method
Iterative, starts with initial planning and ends with development with the cyclic iterations in between to develop a software system incrementally.
Agile Manifesto
values of this method over waterfall
- individuals and interactions over process and tools
- working product over comprehensive documents
- customer collaboration over contract negotiation
- responding to change over following a plan
Agile Method Pros
- deployment team receives feedback at early stages in the overall development process
- rapid feedback from actual user
- flexibility to address evolving requirements
- design flaws discovered quickly
- easy to roll out new functionality in stages
- higher motivation and great productivity
Scrum
An agile methodology that uses ‘sprints’ defined in weeks (1-4) works on requirements for set sprint, works on them and delivers them. then moves onto the next continuous cycle.
Product Backlog
a living document updated and prioritized by the product owner that contains a list of features to be implemented, containing user stories, use cases, defects, and SRCs.
Sprint Backlog
features selected from the Product Backlog that are to be implemented by sprint and updated on a daily basis
Burn Down Chart
graph representation of work done and left to be done in sprint, and updated everyday
Product Owner (Scrum Team)
A representative from the business/client who creates and prioritizes product backing, manages releases, and describes features to a team.
Scrum Master
responsible for the team to follow scrum/agile values, runs sprint planning and daily scrum meetings, assures teams productivity and efficient communication, guards the scrum team and removes impediments
Scrum Team
estimate and implement features, sprint backlog to shippable product, track work progress every day, communicate with product owner, scrum master, and alert when there are projects.
Sprint Planning Meeting
selection, discussion and estimation of features from Product Backlog for current sprint
Backlog Grooming Session
- user stories are well-documented
- making sure requirements are clear
- making sure every one is well aware of whats coming, or what’s on the queue
- making sure everyone is updated with previous progress or any issues or problems left
Daily Scrum Meeting
status of work progress meeting - same time, same place, everyday for 10-15 mins, stand up, no problem solving
each team answers three questions:
- what have i done?
- what am i going to do?
- what problems do i have?
Sprint Review Meeting
Demonstration of implemented features/defects fixes to stakeholders/business
Sprint Retrospective Meeting
discussion of goods and bads of the sprint
🌟 Role of QA in Agile Environment 🌟
- Continuously study and review all project documentations
- attend various project/scrum meetings & keep QA team informed
- capture complex and negative behaviors in AUT, think beyond the “happy path”
- write Test Case, create Test Script, clarify questions/concerns with PO/PM/BA/DEV/SME
- pair up with developer for reproducing defects, writing unit test cases and for QA test scenarios
- perform & automate Regression Testing & Suites
- perform negative, Boundary & Smoke/Ad-Hoc testing formally/informally
- be amicable and flexible in providing immediate support to devs in retesting defect fixes and run Regression Test
- cases/scripts/suites
- stay focused and informed of new user stories, defect status, test deliverables
- maintain criteria for DoD (Definition of Done) and improve quality of AUT
- maintain all test artifacts - Test Strategy, Test Plan, RTM, TC, Minutes, etc.
What is a Bug?
A software bug is the common term to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result or causes it to behave in unintended ways.
How do you know if its a bug?
- software doesn’t do and specs/recs says it should do
- software does and specs/recs says it should not do
- software does but specs/recs doesn’t mention
- software doesn’t and specs/recs doesn’t mention but should
- software is difficult to understand, hard to use, in the software testers eyes will be viewed by the end user as just plain not right
Bug Life Cycle
from the start or discovery of a bug to the resolution or closure state of a bug as it goes through different stages
Severity
how bad/dangerous/severe the bug is and the degree of impact when the user encounters the bug
Priority
how soon/urgency of fixing the bug, how much emphasis should be placed on fixing the bug and the urgency of making the fix
Best Practices of reporting Bugs
- reproduce the bugs two times before writing bug report and then ask a peer (peer reviews catch 80% of the defects)
- test the same bug occurrence on other similar modules/systems / data/environments
- report bug immediately
- write a good bug summary
- use diplomatic language
- properly define severity & priority
Writing an effective bug report
- WHAT happened, WHEN, WHERE
- IMPACT on user/customer
- Clear, Concise, Correct
