♻️ SDLC

👥 SDLC & QA

QA could be performed throughout the software development lifecycle, however this is not always possible nor efficient in practice for several reasons:

  • Every situation is contextual, meaning there will be some situations where QA will want to be involved throughout the process and others where the input is only required at the Quality Assurance stage.
  • The teams involved have more experience - they have learned in the past what to look for and test for in their own scope along the SDLC.
  • The teams are dealing with an urgent hotfix - the solution and implementation should be released quickly.
  • The QA team is too occupied with other higher-priority concerns.

🪲 Bug Report

  • Bugs can be reported by anyone with visibility
    • The client
    • The client's customer
    • The internal team (Project Manager, Designer, Developer, etc)
    • The QA Analyst
  • However, only the QA Analyst would most likely report the bug in context and with the proper level of detail necessary to avoid the need for excess replication and clarification. Further, the QA Analyst can determine if the "bug" is in fact a "bug" and not a user error often attributed to:
    • Environment (wrong branch, wrong version, wrong test server, caching errors, outdated browser, browser extensions, crashing operating system, etc..)
    • User Error (not fulfilling all requirements, not logged in as the appropriate user regarding permissions)
    • A misunderstanding of the requirements (feature does what it is supposed to do but user assumes otherwise)
  • Bug Reports should be monitored and assessed by the QA Analyst for validity or else the report may get ignored until it is too late.
  • Bug Reports can then move to:
    • Planning - if a new concern or stakeholder interest is exposed
    • Refinement - if it is necessary to choreograph the solution
    • Development - if the bug is clear and necessary to fix as soon as possible

📝 Planning

  • Stakeholders in this stage will decide how they want the application to function and perform.
    • The QA Analyst will draw from prior experience to determine if the plans are
      • Possible (with regard to the framework/technology in use)
        • If unsure the QA Analyst can ask the Development team.
      • Thorough and specific in scope
        • Are there any conflicting concerns elsewhere in the application?
        • Would the proposed feature increase opportunites for error?
      • Opportunities for efficient development by combining with other features/plans/updates.
        • Can the proposed feature become included with other proposed features that concern similar parts/aspects of the application with the goal of efficiency?
  • The planned feature can then move to Refinement.

📋 Refinement

  • Stakeholders, Project Managers, Designers, QA and Developers can meet to discuss how a planned feature should be implemented, list requirements and assign sorted tasks.
    • Does the feature require design?
    • What is the priority?
    • How long would this feature take to implement?
    • How much necessary QA is expected?
    • If Design is required, should we add a Design QA stage?

🧑‍🎨 Design

  • The design team reviews the previously-planned and/or refined specsifications and requirements of the feature and draws an appropriate design.
    • From here the designers may discover aspects of the feature that may need to go back to refinement if stakeholder input is necessary
      • Otherwise they can refer to QA or Developers for answers regarding context or missing requirements
    • The design team can add requirements to the acceptance criteria of the task to cover anything they discover and get more granular with the descriptions of the functionality.
    • Design will be kept in sync with prior design themes, branding, and patterns.
  • When design is complete the task can be moved to Development
    • However if there were some incomplete ideas or questions in refinement dependent on how the feature would be designed the task can also be moved back to Refinement, where the task can later go back to design or skip design and go to Development.

🧑‍💻️ Development

  • Developers will implement the feature, trying to match the design and requirements as acurrately as possible
    • If any unforeseen concerns arise they can move the task back to refinement or meet with the Design or QA team for answers
  • The developed feature can then move to Quality Assurance

🧑‍🔬️ Quality Assurance

  • The QA Analyst will thoroughly test each requirement and go further attempting to discover any unforeseen ways to break the feature.
    • Any bugs found in scope will fail the task and it will be sent back to Development
    • Any bugs found out of scope will be noted and referred to the Developer to determine if they can fix it quickly or if the bug needs to be "punted" to a new task.
      • A task in this punted situation can start the SDLC path at Planning, Refinement, Development or Design depending on the context.
  • If the task Passes, the task is moved to "Ready for Release"
  • If the task Passes QA and Design QA is required, the task is moved to Design QA

🧑‍🎨️ Design QA

  • A Designer will compare the implementation on a testing server to the designs created at the beginning before Development.

🏁 Release

  • Prior to release the Developer may combine various branches into a release branch for QA to do Release Testing
    • In this case the process starts at the Quality Assurance stage of the SDLC
      • If the release passes QA, the development team can then deploy the release to production.
      • If more Design QA is desirable and the release passes QA, the release will be moved to Design QA
      • If the release fails QA, the release will be moved back to Development to address any failures
Table of Contents