Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Quality Assurance Introduction to QA Engineering Why We Test The Basic QA Process: Tests and Bugs

Determining Expected Behavior

From experience working with developers and product teams, I've noticed that sometimes it can be difficult to determine what is the expected behavior of an existing or new feature. That is, should this issue be reported as a product enhancement request or as a bug?

Are there some simple things that company's can do to make determining expected behavior on all sides: customer support, product, and engineering with a special emphasis on customer support? For example, would making acceptance criteria and test cases available to customer support as well as both product and engineering be useful so they can make a better judgement call on these things?

2 Answers

Ryan Saul
STAFF
Ryan Saul
Treehouse Guest Teacher

I personally think that transparency is the best policy. Support should be able to see tests from QA and requirements from Product and Development. That might help smooth out misunderstandings and maybe even differences of opinion. Bugs and defects really should always be based on requirements and specifications. Feature requests should be used when its pretty clear that the request is outside of what the intent of the software is.

Communication should also be an answer here. If support is having a difficult time making that judgement call, it should be simple enough to ask someone who would know if its a bug or feature request why it might be one or the other. And having a culture where asking questions like that is encouraged would also go a long way!

That is, should this issue be reported as a product enhancement request or as a bug? A: It depends. I would say that anything that is not implemented as required should be reported as a defect or deviation containing the right explanation for it.

The expected behavior is making sure that the product performs as required. Quality is determining that the product works as previously defined. In my opinion, giving access to tests and acceptance criteria to the customer is irrelevant because both documents need to be approved before test execution anyway. In case of changes, the whole thing needs to follow a change control procedure to ensure that the implemented changes are also reviewed and approved before implemented.