Shift-left approach definition Integrating the quality assurance practices and testing with entire software development life cycle: - from the very beginning e.g. requirements testing, prototype testing etc. - into every role e.g. developer, product owner, tester
Other shift-left approach factors ● test the requirements, both technical and business ● work closely with stakeholders, validate ideas ● research often (A/B testing, users insights, tracked data) ● no sanctuary code, refactor on daily basis ● consider test automation as business value ● automate monitoring and alerting to keep focus into goal
Anti-pattern: never ending business request - one feature developed by 3 teams - requirements verification in the very end of development - unwanted feature from developer invention due to lack of business communication - 2 days of delay for 7 days marketing campaign Lesson learned: communicate with business teams before coding, create common calendar, update each other, squash branches NOT OK: shift left next time!
Success story: migrating to cloud case 4 countries, 2 months, 5 DevOps, server > cloud - after 1st failure: recovery plan, checklists, backup scenario - management supporting the migration team - active email, chat and oral communication - pair-programming to teach the new technology stack Good practice: requirements testing, learn by experience, create basic checklists, communicate with business stakeholders not only tech team OK: attention to quality shifted left on time
“Cognitive” means ... ● respecting human mind and brain capabilities & limitations ● respecting sensual processes like seeing, hearing, touching ● respecting various interfaces (haptic/tactile, visual, brain) ● dependent to perception
Cognitive testing approach manifesto ● Developers, testers, QAs, business stakeholders, end-users are humans. ● Humans have some perceptual limitations we should mind when developing software for humans. ● There are cultural differences between human using software.
Cognitive + shift left = future quality manifesto ● we are humans, we need to communicate ● we craft the software, you contribute to the quality, no matter what role you have ● we want other humans to use our software ● quality is a continuous thing ● the earlier you shift attention to the quality, the better for you
Inspirations ● cognitive science, cognitive psychology ● clinical psychology research (EEG, fMRI, ERP, experiments) ● user experience research ● information architecture ● anthropology ● personal experiences of mates in software development :-)
aleksandrakornecka
sakiengineer
miyayou
kadogen_0527
hato3isfriend
globis_gdp
skrb
kojira
oracle4engineer
trycycle
microcms
miyake
line_developers
gr2m
panda_program
jrom
rocio
trallard
tmm1
jasonvnalue
tanoku
stephaniewalter
mojombo
geoffreycrofte
sachag