Functional testing best practices

[RST IT]

Hello,

That’s my first post in here, so it’s very nice to meet you all. I would like to start with a discussion – what are the best functional testing practices?
The article which inspired this discusssion – http://howwedostartups.com/articles/functional-testing-best-practices

[Loranne]

I believe one very important best practice for functional testing, is to have the requirements and/or design spec (preferably both) in hand prior to starting. It will save you a lot of time going back and forth with the customer or developer. Something that goes along with this is, if you can attend requirement or design meetings, you should do that as often as you can. This will help you understand it well before it’s ready for testing and possibly even start developing test cases.

[Lada]

I like the article, but in the context of functional testing I think it doesn’t emphasize testing preparation enough.
You should know the expected results of each test up front. In agile environment there might not be detailed specification of the system behavior. The analyst or product owner and end-users should provide the information then. It’s best that a tester gets involved in the project as soon as possible and attends requirements elicitation workshops and other meetings. .
Domain knowledge is very useful. If you don’t have personal experience as a user, ask questions to fully understand the business process, inputs, outputs, reasons why the system under test must work as it does. This should provide you with context of testing, place you in the users’ shoes, give you additional test ideas, enable better assessment of bug priority and risk etc.

[marzio]

Nice point. To me: best practice on Functional testing depends pretty much on methodology you’re using.

In an Agile environment there is not so much distance between Unit, Integration and Functional tests. They can be covered with TDD, doing pairing between a Dev and a Tester (if you’re enough lucky to have more than one tester in your team). Acceptance Criteria of User stories becomes your input of requirements, PO is your first stakeholder. Your Definition-of-Done could be met when your test-project is running green on your CI tool.
Every defect raised up in functional can be handled immediately, or postponed in a next sprint via a well reported issue (we use Jira), depends on its severity.

[RST IT]

Thank you all very much for the answers, they are very helpful. 🙂

[Author]

Posts