Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
What does the QA support need to do during the production push or release?
Is that just monitor the pushing progress and run smoke test after that?
What if something went wrong? Are the developers going to fix it? Or roll back to older version?
Any answer will be appreciate!
If you happened to have any experience working in production as QA or developer please share some knowledge you have.
I worked for four years on a small team that didn't have a specific team structure. Generally, we would push production releases for an enterprise Java application on a 3 - 6 month cycle. The team consisted of about 4 developers with me as the only tester.
My primary job was to bring the team in for a soft landing. That required a lot of planning and preparation on my part, including thorough testing of the overall application before entering the "release week", making sure any test automation was up to date and operational, and negotiating bug and issue fixes during weekly team meetings. As fixes were implemented and builds were produced, I would install the builds on various VM servers to test new installs, migration installs from older versions, secure server installations, network component interactions (such as user management systems), and on performance servers containing large data populations to test whether reporting capabilities were impacted.
The last day or two would always get intense where I would sometimes get builds every few hours to test. Working with the developers to verify the potential impact of fixes on the last few days was always an important job.
Hope that helps!
I read somewhere that "A" in QA stands for "Assistance" not "Assurance". Role of QA is to communicate with all interested parties and provide information to managers to decide if build is OK to deploy or roll back.
Business managers make decisions, QA assist by providing info and follows whatever process (or lack of thereof) is in place.
I worked as both QA and Release (it was sort of nice to own both sides of the gate) and in some ways that made it easier; in some ways hard. I had a sort of unique situation, though I am sure it exists elsewhere, but I have not encountered many who were doing both sides of the gate like I was. What it will come down it, is the expectation of the QA Role during a release.
Are you there to run the UAT? Because we had the experience, of testing the changes through the QA environment, we knew what to do and what to look for. So the UAT was quick. It also required us less documentation to pass off to the Release Team so they would know what to test, on the odd occasions where a deployment was done by someone else on the team we did have a UAT to run and we also ran other tests knowing that certain parts of a release might touch other systems that we would want to be aware of.
Are you there to assure roll-back? If there is a problem we would have a roll-back plan in place, or in cases when there would be absolutely no way to roll back (those were few and far between) we had to have someone from Dev on hand to help out in case we needed to make changes. Those couple of releases were frightening, such as the 8 hour running cursor with no logging. Considering you mention that your Devs are doing the deploys I suspect you are in a small dev shop and everyone wears many hats, they are familiar with the code and environment so you should have few issues there - one would hope.
Overall you may have an opportunity to define your position here. The fact you are asking may mean they have given you no direction other than you are involved, so determine what your comfort level is and what you will have available to test for updates in production. If you want to test, and be sure, then you need access to Production servers to check logs, events, and other Production level debugging in case there are problems. It can be a good thing overall, QA/RE mixes are rare and if you can do both you bring some very good experience to the table. I've enjoyed it, and I have been comfortable debugging in Production, since I have done it a lot, but also knowing what is needed for hand-off to a RE team is also valuable, since it's different than just putting a package over the wall for someone else.
I'll start with my favorite answer to this kind of question: it depends.
Now some detail for you - there is a big difference in the tasks a test team will do for the release of a desktop application compared to what will happen for a casual web application, and what happens for business-critical web applications with the expectation of 24/7 availability is different again, as is what happens with consumer web applications.
When I was working with business-to-business desktop applications, the test team would ensure that all items targeted for that release were complete and that automated regression had run cleanly against that release. This often meant a frantic scramble in the last few days as there were inevitably last-minute problems (particularly since it wasn't uncommon for project development to continue until minutes before the release went out).
Where I am now, working as the only tester for a team of 10, mostly involving a web application that's expected to be available at all times, release testing is largely integration testing first to ensure that the migration of code from the test server to the staging server has moved everything that needs to move and hasn't migrated anything that shouldn't be deployed yet. That's usually around a day, sometimes more, sometimes less. Once the staging items migrate to the production environment, I do a light-weight sanity test on each item and a small (about an hour) regression test against the production environment to check that nothing critical has been broken. That process usually takes about half a day.
I've known cases where releases to production happen more or less continuously and the test role was simply regular sanity checks. That happens with some of the less crucial applications where I work, and with some of the modules in the main application.
It really all depends on context.
From my personal experience
