I was asked these questions during a job interview question. I totally stumbled on # 1 and for # 2 even though I answered but not a very convincing way. I would appreciate a concise and well phrased answers:
During SDLC, when would you be asked to take it "offline"
Throughout SDLC process, where would you implement test automation and why?
I would have responded with a clarification of exactly what "offline" means. I can think of three possible definitions.
Offline means disconnected from a network. If it is part of the requirements that your application be available without a network connection, then I would begin testing the offline capabilities as soon as those features are ready, as per the development plan. The sooner you find any bugs, the more cost effective they are to fix.
Offline means outside the scope of current discussion. Often in a meeting, people start getting into an unnecessary level of detail than is warranted by that meeting. A good meeting manager will rein them in by asking them to "take it offline". I could see a translation of this concept relating to the SDLC in terms of eliminating scope creep. That is to say that in the current iteration of the life cycle that creeping features be "taken offline", or further refined and prepared for the next iteration. I would consider this to be an esoteric use of the term, but we're talking about an interview here so who knows.
The most likely use of the term is the end of life of an application. To take an application offline would mean to discontinue support for the application and if applicable to shut down any servers or other resources necessary for its operation. For desktop applications, users might continue to use it but they do so at their own risk. This would occur at the end of the SDLC.
For your second question, to quote Alan Page, "We should automate 100% of the things that we should automate." We want to implement test automation any time we can define the inputs and programatically define the expected outputs, can set up a harness for performing those operations, and can run and analyse a test in a more cost effective manner than we could running that test manually.
We can't automate every test, and even of the ones that we can we shouldn't automate them all because either they're too hard to define, too hard to harness, too hard to analyze, or simple too expensive to automate. But when there is a cost savings (which comes in many forms, whether it's direct labor, faster notification of bugs, or higher coverage than manual testing) we should automate as soon as is reasonable.
