If running a project using BDD with 100% coverage of user stories with automated acceptance tests, what would be the role of a tester / quality assurance person?
I guess I am imagining that developers would write the acceptance tests in conjunction with the product owner, let me know if that seems like a foolish assumption.
Maybe I'm too old-fashioned, but even the most modern development or proccess techniques cannot substitute another set of eyes, fresh eyes, before releasing a product to your client.
Even if your product is simply an API for another developer, you can use QA to think as the API user, providing test/use scenarios that you or your client did not think in advance.
If your product is heavilly based on user interface, definitely you want another person (that's not you or someone of your team) looking to the final result before sending it to the client.
Like any other buzzword in our industry, BDD - even with 100% coverage - is no silver bullet.
100% coverage is not the same as 100% tested.
I'd see a QA person in a ATDD project as someone that would help write the tests and perform the other types of testing that still exists. I.e. UI Testing, destruction testing and load/stress tests.
But I've never worked out an ATDD project.
QA's job is to break the application, the devs job is to not break it. Therefore they write their tests from a different perspective. For instance the devs write tests to see if the expected behavior happens, QA writes tests to see what happens when the users does something the developer would never consider the user would do. Further, developers often misinterpret the requirements and the QA tests will catch when their interpretation is different from what the developer thought it meant and then get together with the project stakeholders to determine which is the correct interpretation. Tests written by devs who wrote the code often have big blind spots because the dev had a big blind spot. For instance, it might test what happens 97% of the time but not the edge cases.
At a previous employer the role of QA was to not test the product but to guarantee the developers essentially did what they said they were going to do with regard to the previously defined acceptance tests which were defined by QA.
The product owner on the other hand had absolutely nothing to do with the testing. Dealing with testing at any level IMHO is not the role of the product owner.
At some point you have to have confidence in your employees; checks and balances are good but you should not have to force a solution within the development cycle which in reality is to only address a small subset of the employees work ethics.
In a perfect world I see the collaboration with dev and QA formalizing with the writing of the acceptance tests in a joint manner. QA should bring a different aspect to the table as should the development team. QA should have their hand in the pie at the infancy of the product and remain engaged through the entire cycle. The product owner on the other hand should then engage QA for an understanding on what the current state of the product is, risks, etc... and focus on the product in a holistic manner; not the specific nuances that make up the product.
From my experience: We were using Unit test to cover more than 90% of code. There were also integration tests and hourly builds. jBehave tests for BDD.
QA role: - adopting user stories for testing - writing code behind steps - exploration testing using RestClient plug-in for IDEA (thus we found some major bugs)
Part of BDD is applying the 3 Amigos approach where the stakeholders collaborate to produce the acceptance criteria. QA/Dev can write the step code to make scenarios execute as acceptance tests. Where is the value of QA to execute manually the same acceptance tests that a BDD tool will execute automatically? The value add of QA is to validate those acceptance tests and perform manual exploratory testing outside the scripted acceptance tests. Duplication will usually yield the same result.
Developers don't rewrite requirements and specs, QA don't rewrite app code...it is possible for QA to not have to perform the very same scripted tests that developers execute as acceptance tests. It is time for Devs to wear some of the QA hat!
