Test, debug and user support for software

For our Thunderbird add-ons Owl and ExQuilla, I need a tester and end user support. I'd like to have the same person for QA, debugging and user support, because I need somebody who can work with the customer to find and fix problems. You will need to verify the bugs that are reported, find the exact circumstances under which the bugs appear, and validate our bug fixes that they fix the bug and do not break anything else. Additionally, you need to handle end user support, answer people's questions, and help them when they have problems, and report a summary back to me, so that we can fix the problems that the people have. 1. Bugs reported by end users: An end user reports a bug, on any channel - support email, website form, rating. You need to find out what the exact problem was that the user had. Most of the time, users just say "this and that didn't work", but give no specifics. You need to find out what exactly happened. Ask them: • What exactly happened: What what the exact error message? Which reaction of the application was wrong? We need an exact description. • What exactly they did, each step of the process, in which order. • The Error Console output in Thunderbird often contains the underlying error and helps us to pinpoint the problem. You will need patience for this, because most users are simply unable to be precise. Work kindly with them. 2. Find a reliable reproduction Whenever the user gives you information, try whether you can reproduce the bug on your computer. Try various ways. The standard situation will normally work, so there's often a specific situation at play that causes the bug. Your job is to find that specific situation. Try to think about what factors might influence the situation. Then, test various variations of these factors. If you find nothing, think of other factors. Once you have found a reproduction, you have found the most important clue, but the job is not yet finished. Try to find in which exact situations the bug appears, and when it doesn't and the software works. Sometimes, a bug can be caused by several different factors. Once you have found once factor, it is usually easier to find the other factors as well. 3. Verify a bug fix Obviously, test the original reproduction of the bug, and ensure that the bug is fixed. But we also need to test other, related situations, and see whether the same bug might appear there. Before we declare a bug as really fixed, we need to make sure it does not exist in other situations or variants. That is part of the job of QA. Lastly, we need to ensure that we didn't break anything that worked before the fix. 4. User support Most of user support are people saying that it does not work. These fall into 4 classes: 4.1. User error The user says it doesn't work, but he did something wrong. We need to help him get it right. However, we have the attitude that all user errors are also our mistakes. (Most of them, anyway.) We tried to make the UI so that it is easy to use by everybody, without any knowledge of computers. If several users have a problem at the same point, that's an indication that we need to improve the software. 4.2. Software limitations For example, several users report that after login, they see the OWA webmail page. We found that that happens for old versions of Exchange, where we don't recognize the login. We cannot support these old Exchange versions yet. Instead of just saying that on our website, we should catch this error in the software, recognize the situation, and show a clear message to the user, instead of just failing. 4.3. Bugs Work with users to find out what happened, how to reproduce it, and help us to fix it. Attitude: Our users are "king" (German proverb). We want them to feel helped, and we are at their side to help them. Language: Fluent English writing Time: At the moment, this is just a 2-4 hours per day. We will start with 1-2 weeks. Whether you stay depends on your performance.