Here is the checklist tailored for a Python developer operating without an
automated CI/CD testing pipeline:
Python Developer Checklist for Manual Regression Avoidance
Phase 1: Understand and Scope the Change (Using Python-
Specific Tools)
The goal of this phase is to precisely define the "blast radius" of the
intended change before coding begins.
Action Descriptio Python Tool/Method Verification
n Method
[ ] 1.1. Map Identify all Use pydeps Analyze the
Dependenci imports and <your_module_file.py> to generated
es dependenci visualize local code dependency graphs
es for the dependencies. and code import
module Run pipdeptree in your statements.
being virtual env to see
modified. external package trees.
[ ] 1.2. Document Markdown file or a A written, bulleted
Define the the primary simple manual_test_plan. list of user steps.
"Happy success md
Path" scenario for
the new
feature or
fix.
[ ] 1.3. List Peer discussion, review of Documented list of
Identify potential existing ticket details. negative scenarios
Edge Cases failure in manual_test_plan.
points md.
related to
the change.
[ ] 1.4. Document Screenshots, short screen Recorded baseline
Isolate current recordings, or notes on behavior for
Existing behavior current UI/API responses. comparison later.
Functionali that must
ty remain
stable.
Phase 2: Implementation and Local Verification (Unit Testing)
Ensure the new code works as intended and does not break the
immediate surrounding logic, even without an automated runner.
Action Description Python Tool/Method Verification
Method
[ ] 2.1. Create a script A A repeatable
Write to run your simple test_my_change.py fil script ready for
Local manual checks e containing direct calls to use.
Manual repeatedly. the functions you modified
Tests (acting like a manual test
runner).
[ ] 2.2. Ensure the Run Script runs
Verify the new feature your test_my_change.py scri successfully;
Change works exactly pt locally, or interact with intended
(Positive as intended the local web server/CLI. functionality
Testing) under ideal observed.
conditions.
[ ] 2.3. Ensure the Modify Code raises
Verify system your test_my_change.py scri appropriate
Edge handles errors pt to pass invalid inputs exceptions or
Cases gracefully. (e.g., None, empty strings, handles errors
(Negative wrong data types). gracefully (e.g.,
Testing) using try...except)
.
[ ] 2.4. Check that Use a local development Full application
Verify code relying server (e.g., flask run-through
Local on your run, python [Link] confirms no
Integrati change still runserver, or your primary immediate
on functions application entry point). breakages.
correctly
within your
local
development
environment.
Phase 3: Comprehensive Manual Regression Testing (The "Blast
Radius" Check)
The developer acts as the quality assurance engineer, systematically
verifying all potentially impacted areas without an automated test suite.
Action Description Python Tool/Method Verification
Method
[ ] 3.1. Rapid verification Manual interaction with the Core
Full of all major local application UI/CLI. functionality
System application entry confirmed
Smoke points. working.
Test
[ ] 3.2. Manually A detailed, time-consuming All steps in
Test the test all functionali manual test session following the manual
"Impact ty identified in the manual_test_plan.md cre plan pass
Zone" Phase 1 that ated earlier. without
(Scope) touches the regression.
modified code.
[ ] 3.3. Verify lockfiles Run pip freeze > Lockfiles are
Test and environment [Link] (or update up-to-date
Cross- consistency. your [Link] with poet and
Environme ry lock --check). consistent;
nt behavior is
Difference the same
s across
environment
s.
[ ] 3.4. Get a second A second developer pulls your Second
Peer developer to branch and executes developer
Review perform their own the manual_test_plan.md. provides
and manual written sign-
Manual verification. off in the Pull
Sign-off Request.
Phase 4: Deployment and Monitoring
Action Description Python Tool/Method Verification
Method
[ ] 4.1. Deploy the Standard deployment Code is live in
Deploy to changes to an script (e.g., Fabric script, staging
Staging/Pre environment that Ansible playbook, or environment.
-Prod mirrors manual server steps).
production
exactly.
[ ] 4.2. Immediately run Manual interaction with The developer
Staging the Smoke Test the staging URL/API and a peer
Smoke Test (Step 3.1) in the endpoints. confirm
staging functionality in
environment. staging.
[ ] 4.3. After deployment Check error aggregation No unexpected
Monitor in to production, tools (e.g., Sentry, error spikes or
Production actively monitor Rollbar) or direct server failures are
error logs. logs (tail -f observed post-
/var/log/[Link]). deployment.
Appendix
1. Static Analysis for Dependency Mapping:
Tools like deptry or pipdeptree:
These tools can help visualize your project's internal and external
dependencies. pipdeptree specifically shows the hierarchical structure of
your installed Python packages.
Code analysis tools (e.g., pylint, flake8 with extensions):
While primarily for code quality, some of these tools can help identify
unused imports or potential dependency issues.
Custom scripts:
For complex internal dependencies, you might need to write scripts to
parse your code, identify imports, and build a dependency graph.
2. Dynamic Analysis and Testing:
Unit Tests:
Ensure comprehensive unit tests cover individual functions and
classes. Changes should trigger failures in relevant unit tests if the impact
is not handled.
Integration Tests:
Test the interactions between different modules and components. This
helps reveal how changes in one module affect its integration points.
End-to-End Tests:
Simulate real-world usage scenarios to catch issues that might not be
apparent at lower testing levels.
Coverage Analysis:
Tools like [Link] can show which parts of your code are exercised by
your tests. Low coverage in areas affected by a change indicates a higher
potential for an unmanaged blast radius.
3. Version Control and Code Review:
Version Control Systems (e.g., Git):
Use features like git diff or git blame to understand the scope of changes
and who introduced them.
Code Reviews:
Involve other developers in reviewing changes. They can help identify
potential impacts and dependencies that might have been overlooked.
4. Dependency Management Tools:
pip-tools or Poetry:
These tools help manage your project's dependencies and ensure
consistent environments, reducing the risk of unexpected dependency
conflicts.
Dependency vulnerability scanners (e.g., Safety, Snyk):
Regularly scan your dependencies for known vulnerabilities, as these can
also represent a "blast radius" of security risks.
5. Architectural Considerations:
Modular Design:
Design your application with clear separation of concerns and loosely
coupled modules. This limits the blast radius of changes to individual
modules.
API Design:
Define clear and stable APIs between components. Changes to internal
implementation details should not break external consumers if the API
remains consistent.
By combining these approaches, you can gain a comprehensive
understanding of your Python project's dependencies and potential impact
areas, allowing you to manage the "blast radius" of changes more
effectively.