What is the most difficult thing about QA, and how would you approach it?
The most difficult thing in QA is if the project requirements are constantly changing. I would make sure that I gather all the client communication and have in-depth knowledge about the domain and all the user actors and use cases so I can not only verify but also validate the functionality tested.
Which part of an application should be covered with automated tests, first.
Mostly stable parts of the applications need to be covered with automated testing. On the code side, unit tests should be developed as new development is done, so logical areas are covered and these tests are can then be handed over to QA to be used along with other automated testing solution.
Can whole application be covered with automated tests?
It can be but for an ever-evolving application, this soon becomes non-practical. Ideally, you would want a functionality to have gone through few manual test cycles and then as functionality is considered complete, then QA can increase test coverage in that area.
Our QA department has helped test and ship software for software shops with all kind of life cycles. We are currently helping a behavioral health client with ADHD patients to ship builds on a daily basis and we have worked with structured environments with quarterly releases and full regression etc are applied. We usually suggest a two-prong QA approach. We can assign one QA person to go with the flow and make sure as many as possible issues are caught in the build cycle, and a second person can identify stable areas of the application and start to develop a library of verification scripts. As these scripts start to accumulate, you will see that QA will start to be able to focus more on new development and old development issues are caught by these scripts.