Sign up for free

This page is intended for users in Japan(English). Go to the page for users in United States.

One of the most precious resource in an IT project is your mindfulness for truly valuable code

About This Memo

This is just a hypotheticalcase of concepts and approaches for building development platform centering on test automation.

Motto

One of the most precious resource in an IT project is your mindfulness for truly valuable code

Some phychologist says,our brain can process only 126 bits/sec, approximately 500,000 bits/hour.
(*as a "consciously resourse". Our unconscious can handle much more apparently)

I beleive that productivity of an IT project ultimately rely on how we can allocate these precious restricted resource for "valuable works" as much as possible.

In other words,
it matters that "How we can deepen the engineer's focus on truly valuable code and protect it from any mental distractions, like anxiety or fears, shallow tiny invaluable/indirect works, and so forth.",
when we think about productivity of software engineers.

Values for Engineers from Dev Platform

  1. Healthy Rhythm/Cycle
  2. Sense of "Safety"
  3. Quick and Micro Feed-Backs
  4. Stand on the Shoulders of Giants

Redefine Test as a Catalyst for Team Chemistry

Opposite Two Demensions of "Test"

  • "Assessment" VS "Judgement"
  • "Breakdown/Drilldown of Criteria TBD" VS "Selection"
  • "Broken Windows Theory" VS "Deterrent Effect of Audit"

Communication Hub

  • "Story as a Test"
  • "Test as a Spec"
  • "Spec as an Acceptance Criteria"
  • "Test as a Report Template": Automatic generation of bug report with visual screenshot slide.

Physical and Mental Safety-net

Monitoring Cockpit

Design Concepts

Solve Trade-off between Speed and Quality

  • A common platform that provides sense of "safety", make members free from "anxiety", and support them to focus on truly valuable works.
  • Automate inevitable painful burdens but critical for quality in a long-run; recursive test, lint check, continuous and regular refactoring, and so forth.
  • Especially, maintainable recursive tests will provide so many pros for software products.
    • Safety and harness that encourage engineers to change working code without compromise for legacy code.
    • Big refactoring in safety without additional tons of testing just for refactoring.
      (* In this context, change of deployment style is another big topic.)

Outside-In Approach by Story/Scenario Based Tests

Supports for Writing Story Based Test Case

Acceptance test scenarios can be also strict definition of specification and clear criteria for "acceptance".
But this requires some standards and test writing skills for scenario writers, but this gap can be solved with well designed platform;

  • Pragmatic layering standard and its criteria for test scenario code.
  • Common components in law layer that encapsulate tons of techy APIs to keep a scenario writer free from learning them.
  • Enough samples that shows layering tips and granurality of test scenarios.

Graceful Alerts

Tests can be a sefety-net and harness for daily coding, but it had better not be noise for an engineer. The notice of "you are going to fall" should be restricted in gracefull manners, like safety-net will block your fall and let you go back to "right path" like trampoline.

"Separate of Concerns" by Layering

"Metronome" for Development Cycle

Auto Execution

with minimum case for saved file in local, with full coverage for merge in server.

Cockpit for "Cruise"

Easy to GettingStarted

  • One-linear install
  • One-linear wrappers for frequently kicked command combination

Close for Element Technologies

Open for Improvement

Test in Clean Room

  • Auto clean-up and set-up for a test condition

Isolation of Each Dev ENVs

Hurdles to be Solved for Test Automation as a Team Practice

  • Encapsulated Interface for Engineers
  • Test Code Management Practice
  • Test Data Management Practice
  • Test Execution Performance Tuning

Specific Themes/Components to be Implemented as a Dev Platform Supporting Automated Test Practice

  • Enforce Micro Feedback on Daily Coding Experience
  • Regular Health-Check for Non-functional Specs
  • Improve GettingStarted Experience
  • Exemplary Samples and Guidelines for Test Code Writing Practices
  • Tools/APIs to Reinforce Test "Code" Management Productivity
  • Tools/APIs to Reinforce Test "Data" Management Productivity
  • Scalable Performance by Parallel Execution of Automated Tests
  • Build-pipeline on CI server
Anonymous
Anonymous

Page top icon