From 0665c646705f29fb4a5274e4a1a0bfb3cc713366 Mon Sep 17 00:00:00 2001 From: Simeon Simeonov Date: Mon, 30 Nov 2020 09:53:51 +0100 Subject: Add flow.html and demo.html as a reference --- reveal.js/flow.html | 194 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100755 reveal.js/flow.html (limited to 'reveal.js/flow.html') diff --git a/reveal.js/flow.html b/reveal.js/flow.html new file mode 100755 index 0000000..c5b2ef3 --- /dev/null +++ b/reveal.js/flow.html @@ -0,0 +1,194 @@ + + + + + QA flow + + + + + + + + + + + + + + +
+ + +
+
+

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. +
  2. Assign supervising developer once the task is picked
    3. +
  3. Commence the design phase(*)
    4. +
  4. Approval by the supervising developer should be required
    5. +
+
+ +
+

New QA flow (2)

+
+

Design phase

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

A more detailed technical specification?

+
+

May be feasible when developing new systems and micro-services

+
+ +
+ + +
+

Q&A

+
+ + +
+
+ + + + + + + + + + + -- cgit v1.3