2015 Jul 03

Early in my career a lot of my testing was done at the end of a project without any planning; a typical waterfall approach. Testing without planning is what I like to call the “testing around” method. Sometimes it works out, sometimes you miss bugs.

Don’t get me wrong, any testing is better than no testing, but when projects reach a certain scale and complexity, it can be dangerous.

Effective and efficient testing requires just as much planning as all other stages of a project. Would you tell a developer to “dev around?” Or a designer to “design around?” Of course not! Specifications and requirements are required so we know what the outcome should be. Same goes for testing.

In an agile approach to projects features are planned, designed, and developed individually which allows testing to be more focused. When specifications are written for the feature, test cases can also be developed. Here at Industrial we start with written test cases (managed in a SaaS online tool called TestRail). Each test case includes the following information:

  • Preconditions (What do I require to be in place, or available, before I can execute this test case? This can be test data, credentials, specific tech like a device or software, etc.)
  • Steps (A detailed list of steps that must be followed exactly to test the feature or functionality.)
  • Expected Result (After following the steps above, what should happen? What does the spec call for? For example, if it’s a login form, what should happen when a user enters the incorrect password?)

An example test case in TestRail

While writing detailed test cases can seem like a lot of work at the beginning of the project, it always pays off later in the process where it becomes more costly to fix an issue. Test cases can also identify any “I didn’t think of that” or “we didn’t plan for that” holes in the spec. Test cases are then provided to the entire team as a reference.

Developers can use these written test cases to develop their own unit tests. These are tests baked right into the code of the project and are executed continuously. Unit tests are a huge asset to project quality, especially when new features are added or updates are pushed. Unit tests can identify bugs in the code that may have been caused by a new piece of code being added, or existing code updated.

Project quality is everyone’s responsibility. If you take the time to plan your testing, it makes it easier for the entire team to build quality right into their work.