What you have description is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example the y2k bug and I have been on such projects.

However most development today is done with a more modern, typically 'Agile' process.

I would suggest that you consider the following Agile process:

• devs and qa and product meet weekly to review new tickets, bugs and chores and score them for degree of difficulty
• devs and qa meet (before dev starts work) to consider tests, testing and a test plan if needed
• devs write the code and the unit tests that verify it. Tests are NOT optional
• devs and/or qa write integrated and UI tests. Tests are NOT optional or 'ideally done'
• qa perform extra testing manually on a representative variety of devices and applications.
• work is demo'd to product and when they are ready merged into master.

Also

• everyone can enter bugs and they are reviewed weekly
• qa acts more as a service to help than a gatekeeper to pass/fail.
• everyone gets training in Agile with a short/long term scrummaster on-site
• use a bug/feature/chore tracker as mentioned by Peter. Consider Trello, Pivotal Tracker and Jira
• all members sit together for 0 comminication lag
• use a good IM tool. The hot new standard is slack.

This is not a comprehensive list (see resources below) but the key idea here (and I've certainly experienced it over decades of development) is that once the feature is written, with accompanying tests, it's relatively unlikely for the developer to want to start tearing it apart and trying different things based on ideas from others whether they are good or bad. So the earlier the input that the QA team can give the cheaper it is to do it, i.e. the cost of changes rises over time.

Other resources:

• https://en.wikipedia.org/wiki/Agile_testing
• http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

What you have described is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example, the y2k bug and I have been on such projects.

However most development today is done with a more modern, typically 'Agile' process.

I would suggest that you consider the following Agile process:

• devs and QA and product meet weekly to review new tickets, bugs and chores and score them for the degree of difficulty
• devs and QA meet (before dev starts work) to consider tests, testing and a test plan if needed
• devs write the code and the unit tests that verify it. Tests are NOT optional
• devs and/or QA write integrated and UI tests. Tests are NOT optional or 'ideally done'
• QA perform extra testing manually on a representative variety of devices and applications.
• work is demoed to product and when they are ready merged into master.

Also

• everyone can enter bugs and they are reviewed weekly
• QA acts more as a service to help than a gatekeeper to pass/fail.
• everyone gets training in Agile with a short/long term ScrumMaster on-site
• use a bug/feature/chore tracker as mentioned by Peter. Consider Trello, Pivotal Tracker and Jira
• all members sit together for 0 communication lag
• use a good IM tool. The hot new standard is slack.

This is not a comprehensive list (see resources below) but the key idea here (and I've certainly experienced it over decades of development) is that once the feature is written, with accompanying tests, it's relatively unlikely for the developer to want to start tearing it apart and trying different things based on ideas from others whether they are good or bad. So the earlier the input that the QA team can give the cheaper it is to do it, i.e. the cost of changes rises over time.

Other resources:

• https://en.wikipedia.org/wiki/Agile_testing
• http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

What you have description is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example the y2k bug and I have been on such projects.

However most development today is done with a more modern, typically 'Agile' process.

I would suggest that you consider the following Agile process:

• devs and qa and product meet weekly to review new tickets, bugs and chores and score them for degree of difficulty
• devs and qa meet (before dev starts work) to consider tests, testing and a test plan if needed
• devs wrote the code and the unit tests that verify it.
• devs and/or qa write integrated and UI tests
• qa perform extra testing manually
• work is done.
• work is demod to product and when they are ready merged into master.

Also

• everyone can enter bugs and they are reviewed weekly
• qa acts more as a service to help than a gatekeeper to pass/fail.
• everyone gets training in Agile with a short/long term scrummaster on-site
• use a bug/feature/chore tracker as mentioned by Peter. Consider Trello, Pivotal Tracker and Jira
• all members sit together for 0 comminication lag
• use a good IM tool. The hot new standard is slack.

The key idea here (and I've certainly experienced it over decades of development) is that once the feature is written, with accompanying tests, it's relatively unlikely for the developer to want to start tearing it apart and trying different things based on ideas from others whether they are good or bad. So the earlier the input that the QA team can give the cheaper it is to do it, i.e. the cost of changes rises over time.

What you have description is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example the y2k bug and I have been on such projects.

However most development today is done with a more modern, typically 'Agile' process.

I would suggest that you consider the following Agile process:

• devs and qa and product meet weekly to review new tickets, bugs and chores and score them for degree of difficulty
• devs and qa meet (before dev starts work) to consider tests, testing and a test plan if needed
• devs write the code and the unit tests that verify it. Tests are NOT optional
• devs and/or qa write integrated and UI tests. Tests are NOT optional or 'ideally done'
• qa perform extra testing manually on a representative variety of devices and applications.
• work is demo'd to product and when they are ready merged into master.

Also

• everyone can enter bugs and they are reviewed weekly
• qa acts more as a service to help than a gatekeeper to pass/fail.
• everyone gets training in Agile with a short/long term scrummaster on-site
• use a bug/feature/chore tracker as mentioned by Peter. Consider Trello, Pivotal Tracker and Jira
• all members sit together for 0 comminication lag
• use a good IM tool. The hot new standard is slack.

This is not a comprehensive list (see resources below) but the key idea here (and I've certainly experienced it over decades of development) is that once the feature is written, with accompanying tests, it's relatively unlikely for the developer to want to start tearing it apart and trying different things based on ideas from others whether they are good or bad. So the earlier the input that the QA team can give the cheaper it is to do it, i.e. the cost of changes rises over time.

Other resources:

• https://en.wikipedia.org/wiki/Agile_testing
• http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468