Advice on how to understand a project with long hi

I have finnaly start my job as a SDET. Now it's my ramp-up period and I need to understand a project in 1 week (the quicker the better).

The project has quite a history and there're plenty of docs I need to read. PM docs, Dev docs and Test docs. My current aims are as below:

1- get a general idea of the project

2- understand the relations between different project modules

3- understand the interaction between the for-ground UI and the background components.

Currently, I think I am familiar with the workflow of our application as a customer of our project. Next is to understand the underhood of the project as a SDET.

The docs are too many and the time is too little. Could anyone give me some adivces on how to ramp-up quickly? Any tips on getting a quick understanding of a new project will be deeply appreciated!

Thanks and it's urgent...

回答1:

I am not editing the wiki, as I would take a longer time getting to know the product before worrying about the tests. I've had to do this a couple of times, and this is the approach that I've found works well for me.

First 1 to 1.5 days: Read the introductions, conclusions, section titles, and anything that catches your eye from the PM docs first, then the dev docs (so mostly just skim). Focus on the most recent documents, and on high-level diagrams. You may want to print some of the diagrams, especially ones showing how the systems fit together, so you can refer to them as you read on (this is the main reason you start w/ PM docs). Just skim previous feature lists to get an idea of what work is covered in those documents, and generally what those features are. The goals are (a) to get a high level understanding of the product (inputs / outputs, which systems make up the whole, etc.), (b) to know where you can look to get additional information on various features - but NOT to thoroughly understand them at this time, and (c) to pick up acronyms and jargon, so you have some vague idea what people mean when they say the PPS system is slow.

Days 2 to 4: read the test documents for the things you expect to be working on in the next month or so, very thoroughly (if there is none, read the dev. documentation thoroughly instead and start sketching out a test plan). Refer back to the PM and dev documents as needed and read needed information and related information thoroughly now. If there is no test information available, use the related dev documents and take notes that will help you when you do start testing. If there is no documentation at all (yes, I've been there), take up residence in the office of the mostly knowledgeable person(s), ask them to relay the information, take notes, and post them somewhere when you are done so that some non-verbal documentation exists.

First half of day 5: Take a look at the bugs that have already been filed, focusing on the things you will be testing. Get a feel for what sorts of problems exist, how people write bug reports there, how things are prioritized at this company, and which bugs get fixed. Look for documentation on how to do your job at this company (test plans, process, best practices, etc.). If you have remaining time, do a little networking and start warming up relationships with coworkers.

Second half of day 5: Get yourself ready to jump in on Monday / the next day. Make some sort of resource list for yourself, with links, DB names, etc. for everything you are likely to need once you get going. Take a look at HR stuff too, and get paperwork squared away so it's not stressing you out later and you can focus on your work. Get your organization / todo list system in place, and write down a couple of todo's for the next workday while the work needed is still fresh in your mind.

Don't follow the days religiously; these are just rough guidelines that I find approximate where I spend my time when ramping up as an SDET most effectively.

Every day: As you read all these documents, write down every question that crosses your mind, and remove old questions only when you have answers (if you have partial answers, restate the question so it reflects your current understanding). Try to organize these questions in some way. I would recommend different documents for each person who is helping you ramp up (manager, developer, PM, etc.), then organize by features or categories. That way you can just read through a single document when you go to talk with someone. If you want to save your answers, move answered questions to a new page or section. A wiki might work very well for this Q&A process - just have seperate sections for 'open' and 'closed' questions.

Once or twice a day, take your list of questions and make the rounds of everyone who is giving you information. Don't be shy - ask away. You aren't wasting their time, but getting yourself to a point where you can help them as quickly as possible. Work through the list, figuring out what the information is or where you can find it. In addition to getting you the information you need quickly, this will help you identify where you should be spending more time reading in depth (as people mention documents that have those answers), and will also help you figure out what is missing entirely from the documentation. You will also get a feeling for people's communications styles and learn more quickly where you can go for help once you start writing code or tests.

Throughout all of this, prioritize setup over learning. This is because setup is often dependent on other people doing things, and you want to reduce your dependencies on other people doing stuff as fast as possible. Get your machines running with a dev environment you can use, get any needed software installed, get email working if it isn't, and make sure you have access to resources that you will need as soon as you know they exist (DBs, bug databases, document repositories, etc.). If your start is poorly organized, you could easily lose a day or even an entire week just on this kind of overhead - or it might jut take an hour, and you'll wonder why I even bothered to mention this :)

回答2:

Do you mean SDET=Software Design Engineer in Test?

I would continue like this:

If I already know the workflow as a customer i try to find the actors of use-cases