Igor Vayner's Presentation at QA workshop (StarEast QA Conference 2014). Covers the eternal holy war between Test-Driven Development teams and old-world QA. Who wins?
2. Instruments
vs. Process
”Test" is the location of this uncertainty.
Drawing the line betweenTDD and QA is crucial: they are not
synonymous.TDD is NOT about checking the actual result to suit
the expected result, it is about a better understanding of the nature
of the function you need to incorporate.
Furthermore, whether you have testers on your board or not,
someone is still checking your software and monitoring the quality
process, which means that the task of QA still exists in a formal or
ad hoc manner.
Here we come to the real question with common language set: who
should do the testing?
3. Budget
Compare the developer's and QA engineer's pay, willing to do the
same job of testing. Often you will see the gap in favor of a
developer is 2, 3 etc. times. It turns out that for testing skills, you
pay the price for developing skills. Remember the 80 percent price
paradox that gives just 20 percent of the outcome?
4. Too many
ways to test
Integration of APIs, localization, performance, reliability, field use,
standard enforcement–all these areas can contain showstoppers for
your product.The amount of details you need to take into account is
enormous, and through this process, the tester's specific experience
is a great help. Professional testing is about approaching the quality
of the product to the system.
5. Speed vs skill
Average frontend developer will need a good amount of time to
understand things in order to dive into the quality testing aspect
s.There's often no room for this in your venture.
6. X-Ray
Senior-level experience testers are very FAST to catch lots of logic
and UI bugs between various screen sizes, platforms, and devices.
Problems identified early in the game are cheaper and quicker to fix
as each iteration tends to complicate the code.
7. Same old
story
Automation often has negative ROI when you have rare launches. It
means that a lot of items should be manually tested. Represent the
most common variations of OS versions, models / manufacturers of
devices (phones / tablets), browsers. And this is the time not
accustomed to these operations by your developers.
8. False positives
Unless you interpret the specifications in the wrong way, the tests
won't catch any inconsistencies between brand vision and
execution. Often it's easier to have team member of the opposite
position testing your function.
9. White stains
TDD is still more effective than standard UnitTesting because a
programmer eventually thinks about solving a problem before
writing any code, but acceptance testing should always be
performed separately.A programmer may be more interested in
writing a program that passes tests than in testing various test
scenarios.
10. Specifics
If having a QA engineer / team is a must, there are certain types of
projects, e.g.: the configuration is non-trivial, correlated with
complex integrations, calculations / heavy loads / security, and
requires a different tool set to check whether the actual system
behavior matches the anticipated one.
11. Mindset
Developers are living in "construction space," they are great at the
level of abstraction and their task is to solve problems.Testers live in
"destruction space" and their role is to understand the reverse side
question – and to know how to break the code before it's written.
12. What is
optimal?
Most projects do not need a QA group or separate test engineers
due to our empirical experience, because the cross-functional team
is able to meet the needs of a project–MVP stages. If fixing bugs
identified by your users is cheap for you, you probably don't have to
worry a lot.
But if this is not so, a combination of developers and QA on your
project will optimize your sets of skills and productivity.The secret is
the QA's accurate implementation. Devs and testers should share
each other's expertise and cross-train. Earlier a tester who knows
the code base can find loose ends–and effectively break the system.
A developer who knows how better tests can be produced would
introduce better functionality and product.
You easily discover the issues.This keeps members of the team
focused on their desired job. And most importantly, the budget is
saved.
