1. QA/Test Engineering Perspectives
Roopesh Kohad
Email: roopesh.kohad@synerzip.com
LinkedIn: http://in.linkedin.com/in/roopeshkohad
Presented by

2. Agenda
 QA inTraditional Software Development
 Modern Software Development
 Test Engineering perspective
◦ Roles & Responsibility

3. QA in Traditional Software Development
 QA only at the end of long development cycle
 No effort to educate QA on product & quality
criterion
 Scripted tests, test design different than test
execution
 Mostly black-box testing or UI automation
 Dogmatic, process-heavy, labor-intensive, and
time-consuming
 Pressure to meet deadline even after
Development spill over

4. QA in Traditional Software Development
 Not considered an engineering discipline
 Not considered a stakeholder in the
product
 Seen more as cost/liability than an asset

5. Modern Software Development
 Software development has become agile
(“literally”)
 Rapid development & deployment thanks to
software moving to “Cloud”
 Complex design/architecture(as against
features)
 Increased competition & Reduced Time to
Market
 Constantly changing scope (feedback loop)
 Little or no documentation

6. Challenge for QA/Testing
 How to keep up with overall software
development and provide value?

7. Paradigm Shift
 Quality is collective responsibility
 Testing != Quality
 Everyone has to test not just QA
 Testing isn’t a separate practice, it is part of
the development
 Testing should be an act of prevention than
detection

8. Test Engineering
 Testing is an engineering discipline focused
on enhancing productivity of engineers

9. Engineering Roles
 Development
◦ Developer
 Testing
◦ SET (Software Engineer in Test)
◦ TE (Test Engineer)

10. Why – Developer Productivity?
 Quality would come through better code
 Better code through emphasis on code
quality
 Better code through optimum utilization of
time
 Less time to test, integrate & less rework

11. How - Developer Productivity?
 Test Frameworks for every type of tests
 Easy to author & run tests
 Quick results, better CI turnaround
 Encourages developers to write better tests
for their code

12. Why - Test Engineer Productivity
 Free him to do Exploratory testing instead
of running regression
 Focus on risk & other quality criterion
 Should not be caught with regression testing

13. How – Test Engineer Productivity
 Functional / End-to-End test automation to
take care of regressions
 Quick deployment or environment setup
 Tools to aid Exploratory tests & Analysis

14. Team Productivity
 Collaboration tools & processes
 Tools to provide consistent view of state of
the product across team
 Documentation

15. SET - Profile
 Enabler of good testing for other engineers
– Developers and Test Engineers
 Understands technical debt of the product
 Creative & strive for continuous
improvement
 Jack of all trades /Wears multiple hats / all
rounder

16. SET - Responsibility
 Anything to enhance developer/tester/team
productivity
 Review design and look closely at code quality
and risk
 Review test cases authored by other engineers
 Refactor code to increase code quality and
testability
 Write unit/integration/functional testing
frameworks
 Increase test coverage by looking code
coverage

17. SET - Responsibility
 Responsible for Developer/Tester tool chain
◦ BuildTools
◦ Continuous Integration/Testing/Deployment
◦ Test Frameworks
◦ LOBTools
◦ Custom tools

18. SET - Skills
 Same as developer with someone who is
passionate to test
 Well-versed with diverse technologies and
make them work together

19. Test Engineer - Profile
 Use the product on behalf of the end
customers
 Be a product experts and understand the
value proposition of the product
 Understand the customer and be a
customer advocate
 Focus is on user impact and risk to the
overall mission of the software product
 Creative & power user of product

20. TE - Skills
 Savvy with product domain
 Imagination & Creativity
 Communication

21. Exploratory Testing
 Unscripted but not aimless, more like mind
mapping
 Next test to execute is not obvious and
depends on the current state
 Useful in complex situations when little is
known about the product

22. Crowd Sourcing
 Can’t depend on TE(s) to find every issue
 Why is it important?
◦ Heterogeneity
◦ Good sample of external world
 Bug Bash
 Tools to make crowdsourcing simple
◦ Surveys
◦ IM
◦ Forums

23. Summary
 Quality of the product is collective responsibility
 Developers need to test
 Test Engineers own quality from customer
standpoint
 Test Engineering enhance developer & test
engineer productivity
 Stakeholders need to be onboard with Test
Engineering
 The thought-process is inline with Agile spirit

24. ThankYou!
 Further Reading – How GoogleTests
software
 Feedback
◦ Roopesh.kohad@synerzip.com
◦ Roopesh.kohad (skype)