Waterfall is more suitable than Agile for testing ... in some teams (Satire)

This is a satire. I have been using Agile for more than 10 years and I believe Agile are generally good for the quality of whole team , products and businesses , provided we communicate clearly and take collective responsibility. Changing to waterfall or other methodology will not resolve the issue. Read it with a light heart , laugh , have a beer or cry - as some of these scenarios may have happen in your team.

Note : I do not recommend changing to waterfall as what is stated in the article.

?

I visited several teams (big and small companies) to understand their testing processes. I find several common challenges :

1. The products / services are about to be launched hence the team decided that a testing resource is needed, They start the hiring processes or transfer a QA member from another division.
2. There are very few unit tests (or none) and no automation (blackbox / api ).
3. There are several dependencies that cross interface with the internal services / products that have not be verified.
4. The team do ad hoc manual testings among themselves.
5. There are no documentations (no API docs especially).
6. They need someone to "certify" the products / services have "passed" before release which is coming soon .
7. Many of these are multiple teams working together (may be 20 person or more).

The tasks seem straightforward for the QA resource (usually it is one headcount - the very first)

• Complete all category of testings - manual testing (black box / api / functional / integration / component etc) , UI automation (web app / windows app) , api automation, performance test before the launch.
• Have tests plans / test cases other test docs completed.
• Work with multiple teams (may end up supporting more than 15 devs for one tester).
• Test "everything" and automate everything in parallels.

Taking note that there is no testing resource at all and the team is investing in it for the first time.

Looking at this , I usually probe on the process of development , the priorities, expectations (for different phases), technical challenges and current testing process. I find that it is almost impossible for tester to complete it within schedule - you can complete it but the testings quality are almost poor.

This problem is aggravated in Agile where each cycle is 2 weeks and the tester have began with a backlog of several sprints. Ideally , most developers and testers should work on the same features but these are not the case. Even so, realistically , the deliverables of features will be given to the testers late in the sprint, giving him/her little time to test and automate.

My recommendation - Go back to waterfall , let the tester have time to test. Or clone him / her so we can complete the sprint.

Cross functional teams are important to Agile development. One of the main advantages of having team members who are multi-skilled, rather than specialists, is that when stories are heavy in certain work that other team members can pick up this work from the “QA”. The testing is not done solely by the tester.

Quality needs to be owned by entire team. If the testing starts only with the tester , it is costly and too late. The teams need to change their mindset to do TDD. Otherwise , testing care rarely be satisfactory complete - Testing quality will be sub-par standards.

Or the team can go back to Waterfall. This is where the testing team can have more time to focus than the continuous disruptions in Agile. Agile is not suitable for many of these testing teams. For Agile to work, testing activities need to be scheduled and planned at every sprint for everyone (developers / product designers / testers).

Process needs to work for the organisation , not the other way round. Testing is only part of quality . Everyone is responsible for good quality - not in paper but in continuous regular action.

Let me know your thoughts.