Terminology
The target audience for Effective Software Engineering is mainly for people who have stumbled upon the practice of writing code but do not necessarily have formal software engineering training. Given that audience, there will undoubtedly be unfamiliar terminology that should be understood completely before continuing. This page is set up to enumerate as much terminology as possible that Effective Software Engineering will use. As Effective Software Engineering grows, this page will appear to be a living document as more terms get introduced periodically.
The terminology enumerated on this page contains both software engineering specific terms and terms used to describe common aspects/scenarios of software engineering practices.
Coding
| Term | Definition |
|---|---|
| Pseudo-code | Code that does not follow a specific language syntax, but does convey a specific sequence of events. |
Languages
The terms function, method, procedure, subroutine, and other synonyms, all generally mean the same thing. They are smaller encapsulated bits of logic that may (or may not) accept input variables, perform some computation, then may (or may not) return a value.
In all practicalities, the difference between these definitions are arguable at best. Many languages, particularly object-oriented languages, consider a method different in that it operates on a specific instance object. In Java this is the "this" reference, while in Python this is the "self" reference. Functional programming languages like to use the term "procedure" for indicating the function does not have any side effects. In general I will stick to a convention whereby a "method" implies some sort of object-oriented aspect and the other terms do not. Within the context of Effective Software Engineering, these terms are mostly interchangeable.
Roles
These roles are not mutually exclusive. For example, a developer could also be a sustainer, or a sustainer could also be a tester. These are intended to be more of a logical separation of duties rather than a physical separation of people.
| Term | Definition |
|---|---|
| Developer** | The person whose job is to write code. |
| Sustainer | The person whose job is to monitor or maintain operational instances of code. |
| Tester | The person whose job is to test code written by a developer. |
** For the purpose of Effective Software Engineering, the terms "developer", "coder", "programmer", "software developer", and "software engineer" are all synonymous with each other. It is arguable at best that each of these terms have separate definitions, so any references to any of those terms are intended to mean "developer."
Testing
| Name | Synonyms | Authors / Maintainers | Description |
|---|---|---|---|
| Unit Testing | White-box Testing | Software Engineers | Unit tests typically validate the implementation of objects or modules. A change to the implementation has a high chance that a unit test will fail afterwards. Additionally, unit tests should not depend on the whole-system functioning to run the test, they will use fixed values, known test data, and/or mock objects to exercise a specific object or module. |
| Integration Testing | Black-box Testing | Software Engineers | Integration tests exercise higher level functionality whereby groups of objects or modules are clumped together for testing. A lot of times integration tests are exercising functionality at the interface level. A change to an implementation should not usually break an integration test. |
| System Testing | Black-box Testing | Test Engineers | A level even more abstracted, than integration testing, from the specific implementation details. At this level system tests usually pool together multiple applications, databases, and other external entities for testing that comes close to if not exactly like production environments. |
In my experience, very large software projects will have a software development team that writes the code then performs both unit and integration level testing, and a dedicated Test Engineers perform the system testing. It is not unheard of for developers to perform system testing, nor for Test Engineers to dabble in lower level tests, but if a project grows to the point where dedicated Test Engineers are employed then they will more often than not stick with very high level system testing.