Development Team Workflow

John Vandivier

This article is a basic overview of the workflow of a professional application development team.

  1. Receive requirement
    1. This would classically come in the form of written Acceptance Criteria and/or test cases
  2. Understand requirement
    1. EOE, delivery schedule, and other planning is involved here
    2. Research may be involved if the feature involves a new or unknown implementation pattern.
    3. This phase is not done until the intended implementation pattern is known and planned.
  3. Develop solution to that understanding
    1. Development workflow may include separate environments such as local, development, testing, and production environments.
    2. A network-oriented or web-based solution is not developed or tested until after is has been verified in a server-deployed environment. A local machine doesn't count.
    3. Integration with other developers is key: Use version control and test before pushing to other developers or the server.
      1. Git is a great tool for this for many reasons, but two key reasons are the ability to do a local backup without broadcasting the change, and easy branching and merging.
  4. Peer review
    1. After completing a solution, or even simultaneously (peer coding ftw), it is a good practice to do a peer review.
    2. Peer review catches bugs, allows for optimization, and allows knowledge sharing with others about the new codebase.
    3. A proper peer review is not only a code review but also a functional review or demonstration. Developers should be familiar with the technical flow and use flow or scenario.
  5. Test the solution
    1. This includes all kinds of testing: Regression, unit, functional, automated, integration, etc.
      1. Regression testing: Make sure nothing that was previously functional stopped working.
      2. Unit testing: A small, automated test. Usually it is run as part of a build process. Usually a function or module tests itself to ensure internal validity.
      3. Functional testing: A person tries using the product and compares observations to expectations to ensure the desired user experience.
      4. Automated testing: A good automated testing solution can mock functional testing with a testing algorithm that simulates clicks around the operating system. So it's like a functional test, except no human is involved. TestComplete is an example if an automated testing solution.
      5. Integration testing: When you take code built in one environment and test it in another environment. This is key for web and network solutions, where code is usually built on a single machine but it must be tested on a server or in a network-accessed environment.
  6. Send for Acceptance Testing
    1. This is sort of part of #4 as it is testing, but it is the last stage of testing: All other tests should be verified before this one.
  7. Iteratively improve until the feature is complete and stable.
    1. Yes, iteratively indicates the use of Scrum and Agile. Agile is preferred practice for most IT development teams.