QA flow

Idas and thoughts


Simeon Simeonov

Agenda


  • The problem with the current QA flow
    •
  • Alternatives
    •
  • Suggestions
    •
  • Q&A and discussion
    •

The problem with the current QA flow

“Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” - Wikipedia


“Accumulation of technical debt is not always a choice.” - Simeon Simeonov, 21st century developer

The problem with the current QA flow (2)


  • Based on pull-requests (tactical)
  • Poor or lack of technical (strategic) design
  • Lack of supervision

The problem with the current QA flow (3)


Typical challenges

  • What entities do we need and how will we name them? (module, package, a script...)
  • Where will the code reside?
  • What is the best way to interract? (Object-oriented design in the case of Python)
  • Is this the best way (even in pragmatic terms)?
  • Any known best practices?

Alternatives


What do others do?

Alternatives (2)


Google, Microsoft...

  • Detailed technical design is expensive and requires hierarchial structure
  • They do not exploit our logistical advantage of being in one place

Alternatives (3)


Linux...

  • Brutal and hierarchial structure with a lot of overhead
  • They do not exploit our logistical advantage of being in one place

Suggestions


  • Automate most of the current QA tasks through better test coverage, static checking and linting
  • Modify the QA flow
  • Consider a more detailed technical specification(s)

Automation


  • better test coverage - as much as possible, something is better than nothing
  • own flake / pylint modules, as well as disabling the annoying ones as part of CI

New QA flow


  1. Decide whether the task is "strategical" during planning and mark it accordingly in Jira
  2. Assign supervising developer once the task is picked
  3. Commence the design phase(*)
  4. Approval by the supervising developer should be required

New QA flow (2)


Design phase

  1. Identify all entities, entry points and parameters (in case of CLI)
  2. Decide on names, naming conventions and where different enteties will reside
  3. Decide on code entities and define the public interface (OO design)

A more detailed technical specification?


May be feasible when developing new systems and micro-services

Q&A