5 exercises on the verb collocations developers use every day — run, ship, raise, merge, resolve. Choose the right verb for the right context.
Key verb patterns in developer English
run tests / builds / pipelines / scripts / migrations
ship / deploy / release features → different register/precision
raise / create / open a ticket → platform affects which verb
open → review → approve → merge a pull request
fix / resolve / squash a bug → register from informal to formal
0 / 5 completed
1 / 5
Which sentence uses the correct collocation for executing automated tests?
Run — the standard verb for executing tests and processes:
In software development, run is the dominant verb for executing tests, scripts, builds, pipelines, and processes.
Core collocations with "run":
run the tests / run a test suite
run the build / run a CI pipeline
run a script / run a deployment
run a migration / run a container
What the other verbs mean in testing:
write tests = create/author the test code ("Let's write unit tests for this function")
pass/fail a test = the outcome ("The test passed" / "3 tests failed")
fix a test = repair a broken test
skip a test = mark it as excluded from the current run
Technical commands match the vocabulary:npm test, pytest, go test ./..., ./gradlew test — all the commands include "run" semantics, and developers say "run npm test" or "run the test suite."
"Do the tests" and "make the tests" are incorrect collocations in this context. "Perform the tests" is technically grammatical but rare in spoken developer English — you'd see it in formal QA documentation.
2 / 5
A team celebrates delivering a new feature to production. Which phrase is most natural in developer conversation?
Ship — the developer culture word for delivering to production:
"Ship" has a rich history in software development — it means delivering software to users, making it available in production. It conveys the full lifecycle: built, tested, merged, deployed.
The development lifecycle vocabulary:
build / implement / develop → during development: "We're building the dark mode feature"
test / QA → verification phase: "The feature is in QA"
merge / land → code integration: "The PR was merged to main"
deploy / release / ship → when users get it: "We shipped it to production"
Ship vs. Deploy vs. Release:
ship = informal, developer culture — emphasises delivery, can mean the whole cycle
deploy = technical — the act of putting code on a server. "We deployed to staging."
release = making a version available — often has a version number. "We released v2.3.0."
Common expressions:
"Let's ship this." → informal push to deliver
"Ship it Friday." → often represents the urgency culture (and its dangers)
"We shipped 47 features this quarter." → used in retrospectives and OKR reviews
3 / 5
A developer notices a production bug. A colleague says: "Can you ___ a ticket for this so it doesn't get lost?" Which option sounds most natural in a professional IT context?
Raise a ticket — the professional British IT collocation:
"Raise a ticket" is the standard professional expression in IT, particularly in British English and in enterprise/ITSM (IT Service Management) contexts.
Ticket lifecycle collocations:
raise / create / open / log a ticket → create a new issue
assign a ticket → allocate to a person
accept / pick up a ticket → start working on it
update / comment on a ticket → add information
resolve / close a ticket → mark it done
escalate a ticket → move to higher priority/person
reopen a ticket → resurrect a closed issue
Platform-specific language:
GitHub/GitLab: "open an issue" (not "raise")
Jira/ServiceNow: "raise a ticket" or "create a ticket"
General IT support: "log a ticket" or "raise an incident"
"Make a ticket" is understood but sounds informal. "Do a ticket" is incorrect. "Build a ticket" does not collocate — you build software, not tickets.
4 / 5
Which set of verbs correctly describes what happens to a pull request from start to finish?
The complete pull request verb lifecycle:
Pull requests (PRs) have a well-established vocabulary in developer culture:
Opening phase:
open / create / raise / submit a PR → create the PR for review
draft a PR → open as work in progress, not ready for review
Review phase:
review a PR → read the code, leave comments
request changes → ask the author to fix something
leave a comment / leave feedback → non-blocking note
Decision phase:
approve a PR → LGTM (looks good to me)
reject / decline a PR → decide not to merge
merge a PR → integrate changes into the target branch
close a PR → close without merging (abandoned or rejected)
revert a PR → undo a merged PR
Merge strategies:squash and merge, merge commit, rebase and merge — different ways to integrate the changes.
Common expressions: "LGTM", "ship it", "approved with comments", "waiting on review", "needs rebase", "conflicts to resolve."
5 / 5
After a debugging session, a developer tells the team: "I ___ that null pointer exception in the order service." Which version sounds most formal and appropriate in a written standup update?
Bug/Error vocabulary by register:
The register matters — the same action has different expressions for different contexts:
Informal / developer culture / Slack:
squash a bug → common developer slang ("squash bugs" is so common it's in GitHub's October activity)
kill / nuke / zap a bug → very informal, casual team conversation
hunt down a bug → emphasises effort ("I spent 3 hours hunting down this bug")
Standard / daily standup / team communication:
fix a bug → most universal, understood everywhere
fix the issue → neutral, works in most contexts
Formal / written reports / incident reviews:
resolve a defect → full and formal ("The null pointer exception was resolved")
address a bug → careful formal language ("This PR addresses the NPE in the order service")
remediate a vulnerability → specifically for security issues
Best practice: Use "fixed" or "resolved" in written standup updates, commit messages, and Jira tickets. Save "squash" and "kill" for team Slack channels and casual conversation.