IBM s Point of View QA 2016/17. June 23, 2015

Transcription

1 BM s Point of View QA 2016/17 June 23, 2015

2 Hallway Conversations Myths or Reality? All Testers Will Be Dev/Testers Shift Left is Over Test/QA will be repurposed back into Development Agile = Dev/Ops What Does Testing Look Like in an Dev/Ops World (2016/17)? Automate Everything RBT on All Projects 2

3 Emerging Known BM Point of View Quality Assurance and Testing in 2016/17 QA/Test Today /T Transformations QA & Test in 2016/17 TCoE Automation Team Test Skills Technical + Domain Externally Provisioned Environments Runaway Test Case Suites E2E Tests the exception Discrete Test Phases 6 8 Week Test Cycles Detection Based (Resource Centric) Production / Progression Driven TDM Distributed Test Workforce Dev/Ops Agile Adoption Acquisition of Cloud Based Applications Mobile/Web (Everything is a Sev 1) Security / Privacy AP Economy Big Data Cognitive Computing nternet of things (ot) QCoE Everyone Automates QA Skills Domain + SDLC Self Provisioned Test Suite Optimization E2E Test the Norm Unified Test Phases (ST / UAT / DT) Continuous Test Cycles Prevention Based (Automation Centric) Market Based nstant Quality Feedback Explosion of Devices Fabrication Driven TDM Distributed QA Workforce 3

4 BM Point of View From TCoE to QCoE in 2016/17 QCOE will be the key organizational construct Why? What could go wrong? Need to complete TCoE Journey - Economics/skills Complete Centralization of Resources Negotiated Volume Labor Costs Common Test Process Across All LoBs Standardized Test Tool Set Organizational Changes QA Key, testing is part of it Development measured on quality and continues to be distributed TCoE is in self serve mode on environments Someone Needs to Own Quality Brand Risk Demand for domain experts increases - (e.g. UAT first/always) Architecture Directions E2E is the key QA validation model Component Base Architectures More SaaS Based Applications Big Data driving applications Dev/Ops is not pervasive Distributed Agile model does not work/is not implemented Development teams repatriate testing Measuring QA does not get deployed 4

5 BM Point of View From Automation Team to Everyone Automates in 2016/17 Everyone Automates Why? What could go wrong? Automation has become key to achieving /T objectives - Quality/Cycle Times A small team cannot keep up with demand Progression/First Pass automation compromised by handoffs Programmers do not want to code test automation Different types of automation (U vs. Non-U) need to be equally responsive Build in a progressive style/disposable Technology Evolution Limited training/ Technical Skills Required Scriptless Self Healing Process centric Unattended Execution Virtual nterfaces enable early automation 5 Tools continue to require deep technical skill Maintenance effort inhibits progress Availability of test data limits automation effectiveness

6 BM Point of View From Test Skills to QA Skills in 2016/17 QA Skills = Domain + SDLC + Technical Why? What could go wrong? The majority of QA staff will have a skill base in the domain with additional training in the SDLC pattern + technology - Defect Prevention/Requirements Extraction Non-functional testers will continue to have deep technical skills Functional validation will drive technical validations User stories with business models will drive test case design Developer will detect and correct the majority of simple code defects E2E flows will be more fundamental given the smaller incremental component strategies Cloud delivered applications will start with UAT Code continues to be of poor quality Transition from brute force testing stalls QA positions are not attractive to candidates QA = Testing Recruiting Strategies Domain Based Skills Business degrees Data modelling/nformation Analyst Business Analysts 6

7 Learn more at ibm.com/gbs