Introducing "Testing on the Toilet"

We want you to write more tests. Yes, you. You've already been told that tests are the safety net that protects you when you need to refactor your code, or when another developer adds features. You even know that tests can help with the design of your code.

But, although you've read the books and heard the lectures, maybe you need a little more inspiration, tips, and prodding. And you need it to be in a place where when you see it, you can't ignore it.

That's where we can help. We're the "Google Testing Grouplet," a small band of volunteers who are passionate about software testing.

We're unveiling the public release of "Testing on the Toilet": one of Google's little secrets that has helped us to inspire our developers to write well-tested code. We write flyers about everything from dependency injection to code coverage, and then regularly plaster the bathrooms all over Google with each episode, almost 500 stalls worldwide. We've received a lot of feedback about it. Some favorable ("This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!") and some not ("I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?"). Even the Washington Post noticed.

We've decided to share this secret weapon with the rest of the world to help spread our passion for testing, and to provide a fun and easy way for you to educate yourself and the rest of your company about these important tricks and techniques.

We'll be putting episodes on this blog on a regular basis and providing PDFs so you can print them out and put them up in your own bathrooms, hallways, kitchens, moon bases, secret underground fortresses, billionaire founders' Priuses, wherever. Send your photos and stories to TotT@google.com and let us know how Testing on the Toilet is received at your company.

And meanwhile, keep writing those tests.

Permalink | Links to this post |
The comments you read here belong only to the person who posted them. We do, however, reserve the right to remove off-topic comments.

66 comments:

Maciej said...

Will you be posting the back catalog of past TotT installments?

Alberty Pascal said...

Great idea. Thanks guys !

Slyoldfox said...
This post has been removed by the author.
Doesn't Work At McDonalds said...

Uncle John's Bathroom Reader watch out! :-)

Pepijn said...

A similar thing was/is in use at a place I worked. People made an effort to stay in the toilet for a long time (doodling on their PDA) and later claimed they were reading the work notes... :)

Dom De Vitto said...

Some of my best agile development has been done whilst 'at the porcelain hot-desk', so this is a great idea.

I'm sure it will be highly absorbent.

Kyle said...

when i'm on the toilet, i really just want to do my business, not read about boring test advice. something more thought-provoking would be nice..

Jason R. said...

I've just installed a Wi-Fi printer in my bathroom. Can Google just print the publications directly?

Surfer51 said...

My new Dihydrogen monoxide powered mini laptop has helped me tremendously when harold calls...

Now I have TotT...whoa...life is good.

apersaud said...

Can you make it a podcast like feed so that I can download the pdfs whenever a new one is available on the iTunes store? That would be awesome!

Elo said...

Testing: "Bombs, away!"
*listen*
*plop!*
Success!

bucky said...

Sounds great to already have reading material available rather than having to print something out, get it from the printer, then carry it in

Jared said...

Google doing this...mmmmkay....

However, I shudder to think about the PHBs who will use this to other ends...

doubleA said...

Saves toilet paper too!

Joe #302 said...

Hm. I have to say, I think this is misguided.

I've worked for a long time in the testing/QA engineering field for software (seems like every company calls it something different, and there are different expectations of each, but that just leads to my point). My point is that QA needs to have a bright line between it and development. No doubt, developers need to be good at creating good unit testing. By the same token, good QA/Testers need to be good at development.

But the two should remain separate. Go to any mature industry's engineering department, and ask how much of the release testing is done or defined by the actual development engineers. The answer will be you'll be laughed out of the office. There's good reason for this.

This is a sign of the immaturity of the software development industry. We're getting there, though. I've worked for a couple of the truly big Seattle software interests, and they are slowly getting more mature in how they deal with QA. The key is, (for as good and happy as developers doing a good job developing unit testing for their own work): SDEs are not QAEs, and the distinction should not be blurred, if you want to maintain true quality.

robin said...

and providing PDFs
How about just a printer friendly version without comments?

Eric said...

When I go to the john, I create the Bush cabinet, I don't worry about anything more than watching Cheney and Rice being flushed to a place they belong.

Shona said...

I think you may be missing a certain level of irony in your "positive comments"...
You may also be missing a certain level of fibre from your diet if you are regularly on the loo long enough to read through so much...

Ortwin said...

A picture of those bathrooms would be very informative and entertaining. Please...

Alessio Pace said...

Simply great!! :-)

A related curiosity: a friend of mine had in his bathroom some maths formulas he wasn't able to remember easily :-)

netron said...

i guess this gives a whole new meaning to a "Googlebomb".

Joel Odom said...

These folks obviously need to eat more fiber.

amit said...

Holy shit !!!

Major Tom said...

To respond to Joe #302
You're wrong. I'm a developer in a fortune 500 company and I test everything I do. By the time it goes to Alpha test, only field anomalies break my code. So to say "SDEs are not QAEs, and the distinction should not be blurred, if you want to maintain true quality." you're, well, full of crap. Your statements should be flushed.
Not everyone has poor software developers working for them. A true programmer can take the project from cradle to grave, or more aptly from napkin scribblings to deployment and not have problems.
I have 3000 sites with my software for over three years and have had 2 bugs related to errors on my part. Proper Software Engineering includes heavy testing during development.
I also know of one company that spends Billions (Microsoft) on everything you stated, and well, let their end product speak for itself. It does not support your conclusion.
I rest my case.
-T-

Michael said...

One word: awesome. (okay, I lied) And, thanks.

strimpster said...

To respond to Joe #302
I think that you may want to rethink your position and help usher your company into quicker development. Everyone in your company should be involved in QA activities because it is everyone's job. If the developers learn from their own mistakes, then they should be constantly improving and not have to bother you with errors that could be fixed by them. The QAE should be worrying more about integration testing rather than unit testing, but the SDE should also ensure that their code is scalable and will not cause errors due to an inability to forsee problems.

Robert said...

ewwwwwww. possible marketing backfire? "google" & "crap"...

Michael said...

I have a simple question as a former-programmer, now business guy, between dev and QA.

Why not put pay performance targets on both sides as incentives per testing release?

In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).

Seems like an easy way to get people more motivated about the whole testing process.

stewart said...

To respond to Major Tom:
I commend you on having only 2 bugs in your portion of code with a 3000 site deployment. However, I'm wondering if you're an anomaly and am concerned that this methodology sets a dangerous precedent. Considering the approach of a development engineer should be, and in the best companies is, fundamentally different from that of a test engineer. The DE is solving a positive functional problem, while the TE is addressing the validation and exceptions associated with the DE's solution. When presented with requirements from (in most cases) Marketing PMs, the DE considers how to make the feature/product work, while the TE considers where and how the feature/product will be deployed (functionality and performance testing) and under what circumstances it might break (stress, robustness, and negative testing). As much as we try in our smaller organization to unite the DE and TE mindset to save headcount and to arguably improve unit testing prior to the hand-off to TEs, they will always remain firmly divided.

fool said...

Its a great idea ... Well as long as I am not asked to do 'pairing' inside the toilet.

Russell said...

I had very good success writing my own tests as I was writing libdomainkeys. As I wrote the code, I would create the test. Every branch was labelled with a comment naming the test which forced that branch to be executed. Too bad our text editors don't (usually) support hot-linking between source files.

leskippeur said...

Gives a new meaning to "toilet training" !

BPDecaf said...

Thank you for your sane and sensible comments Major Tom.

Jeff Fry said...

Michael said...

I have a simple question as a former-programmer, now business guy, between dev and QA.

Why not put pay performance targets on both sides as incentives per testing release?

In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).

Seems like an easy way to get people more motivated about the whole testing process.


This sounds like a well intentioned idea, but it leads inevitably toward disastrous consequences.

Ken Kuhlman said...

And here I've always thought of testing as a crappy, #2 priority. Thanks for throwing another log on the fire & helping me see the light!

-Ken

Jeffrey said...

Just reading material? You can do better.

(From eXtreme Feedback)

Phil said...

Re: SDE's are not QAE's.

I think a point to be made here is that engineers of any sort tend to get accustomed to an idea or algorithm or whatever they've been working on. They see it as working just fine. The QA people are there to ensure that your idea of fine agrees with everyone elses. Sure, maybe it doesn't have bugs, but maybe the interface isn't as intuitive as it might be, or whatever. The point is, the more people that look at it before production, the more likely it is to be useful and useable. If you want to streamline your development timeline, you include QA people in the development cycle, to add their input as the project progresses. That way problems can be identified and resolved before it becomes a major problem. But you already knew that - it's your basic concurrent engineering model you learned about in college. I hope.

Adamm said...

I actually googled for "Linux Nerd 2000" to see if I was missing out on some cool new magazine. Heh.

untactical000 said...

Before anyone of you reaches for the toilet roll,make certain that you've read the fine print first!

Pradeep Soundararajan said...

Michelle from Google suggested to share the following with you all:

Kudos to the effort of brainstorming the idea of testing bumper(Harry Robinson style) stickers and tests in toilets.

Here are my 2 cents:

Toilet stickers:

1. The better you code, the lesser it stinks.
2. You expect the toilet to be clean, as we expect your code to be.
3. You mess, we spot, you clean.
4. You dropped the paper roll by mistake. Fix it !
5. Thanks for remembering that you need to go back and fix the bug I found.
6. for ($i=0,$i< ($i--1);++$i) - I am not reminding your coding error :)
7. 234/8 - No! It's a cricket match score and not 234 bugs per 8 KLOC.
8. I am your friend but unfortunately our customers aren't.
9. The more time you spend here, the less time you distract me and the more bugs I find.
10. Did you come here running to think about the explanation you want to offer on why you missed that bug?
11. Don't believe me when I say; your code is working fine so far. I just want to give you a bigger surprise.
12. I heard you say, "Please leave me alone" and that is why I am not reminding you of the bug that took the longest time for you to fix it.

Tests:

1. An end user thought of running our program with a platform we no longer support. Should he get an error message - "You are not supposed to that" ?
2. "Arggh! The page is corrupted." - Does this mean you were unable to handle an exception?
3. I am going on a 3 week vacation and while I come back, I will have a report that my script generated on the reliability test. Are you sure, I wont see anything in RED?
4. "Sorry, no donut for you" - Who got the donut then?
5. The voice kept breaking, when I was using a dial up connection. Did ._ _ _ know?
6. I hear too many click sounds when I login. Do I have an option to hear less clicks?
7. I refer to James Bach's 36 heuristics to test. Do you use them to code?
8. When firewall is ON, your code isn't.
9. Proxies do not by pass bugs.
10. I tried closing the window in between. It goes away smoothy without the error message you expected to see.
11. I am always amazed at your coding skills but not the way you build your code.
12. His code never merges with anyone. Beware if you are merging with him.
13. I found a bug with your unit test script and hence I know what to test.
14. Last time my developer forgot to enable the logger. He spent a week convincing me to reproduce the issue.
15. Psst! Don't tell this to anyone. I look at our competitor product known issues and test them on our product. This helped me catch bugs faster :)

abhi_3182 said...

aa guys nice idea, when is the release...

cameron said...

debugging code sucks; testing rocks; debugging test code really, really sucks

Ben said...

Michael said...

I have a simple question as a former-programmer, now business guy, between dev and QA.

Why not put pay performance targets on both sides as incentives per testing release?

In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).

Seems like an easy way to get people more motivated about the whole testing process.


This is a horrible idea.

I will not improve quality. It will not improve relations between business, developers, and testers. In fact, it will make relations worse within the company and can lead to real bug escapes that impact customers.

This will only lead to finger pointing and time wasted chasing unimportant and duplicate "bugs".

As a tester, I have often had to make the decision about reporting a bug as one or 100,000. I don't know if the 100,000 errors my automated test found are due to 100,000 different problems in the code or just one. I could report them separately, or I could report them in groups, or I could pick up the phone and talk to a developer than could help me determine how the bug should be reported.

And what if the bug exists because a QA person did a poor job of reviewing the requirements? I could easily provide input to requirements that I know will lead to bugs just to get a bonus.

Not all bugs are due to a developer making a mistake in their piece of code. Some are due to bad requirements given to the developer. Some are due to bugs someone else created. If one developer's code does not properly interact with another developer's code, who is to blame? If the issue to bad documentation and requirements, do we blame QA?

And then we could argue about what is and what is not a bug.

There was a Dilbert cartoon many years ago about the idea of rewards for fixing bugs: Now, I'm going to code me a new minivan.

ahoier said...

I like the idea...some of the best ideas come to me when I'm in the "john" ^^ lol

Seo Practices Guide said...

That is a great idea, I will talk my boss into it, a "SEO Testing Practices Program in the Toilet", amazing, thanks.

Woody said...

Great idea to share the testing experiences from Google with the whole world!

However you promised to post TotT's "on a regular basis". The last TotT episode was published over a month ago. So what's this regular basis?

Nate Murray said...

I also had a question about the regularity of this. I think its a great idea, but I've had a hard time finding the collection of these. Is there a place for people to submit these, because I could come up with a few episodes.

Komail Noori said...

I like the idea. I will definetely try it out.

Regards,
Komail Noori
Web Site Design - SEO Expert

M@rce said...

Excelente aporte a toda la comunidad de testers en todo el mundo; nos dá una visión más cercana del entorno laboral y relacional dentro de Google. Gracias y saludos!!

sm said...

網頁設計,情趣用品店,情趣用品專賣網

A片,色情A片,免費A片,成人影片,色情影片,a片免費看,情色貼圖,情色文學,情色小說,色情小說
AV,AV女優

辣妹視訊,美女視訊,視訊交友網,視訊聊天室,視訊交友,視訊美女,免費視訊,免費視訊聊天,視訊交友90739,免費視訊聊天室,成人聊天室,視訊聊天,視訊交友aooyy
哈啦聊天室,辣妺視訊,A片,色情A片,視訊,080視訊聊天室,視訊美女34c,視訊情人高雄網,視訊交友高雄網,0204貼圖區,sex520免費影片,情色貼圖,視訊ukiss

Jim said...

網頁設計,網站設計,搬家,除蟲,蟑螂,白蟻,眼科,橡膠,轉學考

cing said...

^^ nice blog!! ^@^

徵信, 徵信網, 徵信社, 徵信社, 感情挽回, 婚姻挽回, 挽回婚姻, 挽回感情, 徵信, 徵信社, 徵信, 徵信, 捉姦, 徵信公司, 通姦, 通姦罪, 抓姦, 抓猴, 捉猴, 捉姦, 監聽, 調查跟蹤, 反跟蹤, 外遇問題, 徵信, 捉姦, 女人徵信, 女子徵信, 外遇問題, 女子徵信, 外遇, 徵信公司, 徵信網, 外遇蒐證, 抓姦, 抓猴, 捉猴, 調查跟蹤, 反跟蹤, 感情挽回, 挽回感情, 婚姻挽回, 挽回婚姻, 外遇沖開, 抓姦, 女子徵信, 外遇蒐證, 外遇, 通姦, 通姦罪, 贍養費, 徵信, 徵信社, 抓姦, 徵信, 徵信公司, 徵信社, 徵信公司, 徵信社, 徵信公司, 女人徵信,

徵信, 徵信網, 徵信社, 徵信網, 外遇, 徵信, 徵信社, 抓姦, 徵信, 女人徵信, 徵信社, 女人徵信社, 外遇, 抓姦, 徵信公司, 徵信社, 徵信社, 徵信社, 徵信社, 徵信社, 女人徵信社, 徵信社, 徵信, 徵信社, 徵信, 女子徵信社, 女子徵信社, 女子徵信社, 女子徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社,

徵信, 徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 外遇, 抓姦, 離婚, 外遇,離婚,

徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信,徵信社, 徵信社, 徵信, 外遇, 抓姦, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社, 徵信社, 徵信社,徵信,徵信, 徵信, 外遇, 抓姦

eda said...

買煙火,製造浪漫煙火小舖,101煙火,煙火小舖,煙火,仙女棒,沖天炮,勝利之花,甩炮,升空煙火,情趣用品,情趣,衣蝶情趣精品百貨,情趣用品衣蝶
情趣,自慰套,飛機杯,充氣娃娃,AV女優,AV,電動按摩棒,按摩棒,G點,調情棒,後庭拉珠棒,跳蛋,變頻跳蛋,有線跳蛋,無線跳蛋,潤滑液,男女穿戴用品,穿戴用品,情趣內衣,性感內衣,情趣跳蛋,角色扮演,情趣角色扮演,丁字褲,情趣內褲,性感內褲,性感吊帶襪,網襪,性感網襪,T字褲,煙火批發,情趣禮品,情趣用品

★〃mina〃★ said...

花蓮旅遊,花蓮租車,花東旅遊,花蓮租車,花蓮租車,花蓮旅遊,租車公司,花蓮旅行社,花蓮旅遊景點,花蓮旅遊行程,花蓮旅遊地圖,花蓮一日遊,花蓮租車,花蓮租車旅遊網,花蓮租車,花蓮租車,花蓮租車,花東旅遊景點,租車,花蓮旅遊,花東旅遊行程,花東旅遊地圖,花蓮租車公司,花蓮租車,花蓮旅遊租車,花蓮租車,花蓮旅遊,花蓮賞鯨,花蓮旅遊,花蓮旅遊,租車,花蓮租車,花蓮租車 ,花蓮 租車,花蓮,花蓮旅遊網,花蓮租車網,花蓮,租車,花東 旅遊,花蓮 租車,花蓮,旅遊,租車公司,花蓮,花蓮旅遊,花東旅遊,花蓮地圖,包車,花蓮,旅遊租車,花蓮 租車,租車,花蓮租車資訊網,花蓮 旅遊,租車,花東,花東地圖,租車公司,租車網,花蓮租車旅遊,租車,花蓮,賞鯨,花蓮旅遊租車,花東旅遊,租車網,花蓮海洋公園,租車 ,花蓮 租車,花蓮,花蓮旅遊,花蓮租車公司,租車花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮旅行社,花東旅遊,花蓮包車,租車,花蓮旅遊,花蓮租車,花蓮一日遊,租車服務,花蓮租車公司,花蓮包車,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮租車,租車網,花蓮租車公司,花蓮旅遊,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮租車公司,花蓮一日遊,租車花蓮,租車服務,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮旅遊,花蓮賞鯨,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,租車花蓮,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,租車花蓮,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,租車公司,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮旅遊,花蓮旅遊租車,花蓮租車網,花蓮租車,花蓮一日遊,租車花蓮,花蓮租車,花蓮旅遊租車,花蓮租車,花蓮租車旅遊,花蓮租車,花蓮旅遊,花蓮旅遊,花蓮包車,花蓮溯溪,花蓮泛舟,花蓮溯溪旅遊網,花蓮旅遊,花蓮民宿,花蓮入口網,花蓮民宿黃頁,花蓮旅遊,花蓮租車,租車公司,花蓮旅遊租車,花蓮租車,租車,花蓮旅遊,花蓮租車,花東旅遊,花蓮賞鯨,花蓮旅遊,花蓮泛舟,花蓮賞鯨,花蓮溯溪,花蓮泛舟,花蓮泛舟,花蓮溯溪,花蓮旅遊,花蓮旅遊,花蓮租車,花東旅遊,花蓮,花東,花蓮旅遊,花東旅遊,花蓮租車,花蓮,花東,花蓮旅遊,花蓮租車,花東旅遊,花蓮旅遊,花蓮租車,租車,花蓮旅遊,花蓮租車,花蓮旅遊租車,花蓮旅遊,花蓮租車,花蓮,花東旅遊萬事通,花蓮旅遊,租車,花蓮旅遊,花蓮租車,花蓮,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車,花蓮包車,花蓮旅遊,花蓮租車,花蓮租車旅遊網,花蓮太魯閣,花蓮旅遊網,花蓮包車,花東旅遊,花蓮旅遊行程,花蓮旅遊,花蓮 租車,花蓮租車資訊網,花蓮租車旅遊,花蓮旅遊租車,租車,花蓮旅遊推薦,花蓮旅遊包車,花蓮租車,花蓮,花蓮租車,花蓮地圖,花蓮旅遊優惠,花蓮旅遊資訊網,花蓮旅遊景點,賞鯨,花蓮行程,花蓮旅遊,花蓮旅遊租車,花東旅遊景點,花東旅遊行程,花蓮旅遊blog

lee said...

徵信社的服務項目,如婚前徵信、商業徵信、財產徵信等等,另外徵信社還可以代為討債,當有以上各項徵信服務的需求時,只要找有登記合格的徵信公司,與徵信公司簽訂徵信合約,就能保障自己的權益,所以徵信社仍是您遇到難題時的最好選擇,合法的徵信社,除了能提供您法律的諮詢外,還能協助釐清問題,尤其是棘手的外遇徵信徵信社除了跟蹤外,還會協助您注意徵信過程的合法性。

lee said...

OA辦公家具, 室內裝潢, 室內設計, 室內設計作品, 搬家推薦, 精緻搬家, 搬家公司, 全省搬家, 回頭車, 搬家服務, 專業搬家, 搬家, 托福, 多益, 搬家, 台北搬家, 搬家公司, 搬家網, 精緻搬家, 宜蘭飯店, 宜蘭住宿,坐月子餐, 月子餐, 留學, 留學, 搬家公司, 搬家, 台北搬家, TOEIC, 多益, 台北搬家, 搬家公司, 搬家, 托福, toefl, 全民英檢, 英檢, 搬家公司, 搬家, 台北搬家, 花蓮民宿, 民宿, 台東民宿, 團體制服, 團體服, 制服, IELTS, 雅思, 留學, 美國留學, 遊學, 室內設計, 空間設計, 會計師事務所, 會計師, 信貸, 貸款, 三信商業銀行, 影印機, 印表機, 傳真機, 事務機, toeic, 多益, 搬家公司, 搬家, 台北搬家, 桃園搬家, 虛擬主機 , 電腦維修, 室內裝修, 馬賽克, 磁磚, 瓷磚, 拋光磚, 企業外派, 企業教育訓練, 徵信社, 徵信, 喜帖, 馬克杯, 室內設計, 室內裝潢, 多益, TOEIC, 三信銀行, 貸款, 信用貸款, 公教貸款, 搬家, 包裝材料, 搬家公司, 全民英檢, 英檢, 網頁設計, 網頁設計公司, 日文補習班, 日本留學, 禮品, 贈品, 托福, 英文, 精緻搬家, 搬家公司, 專業搬家, 台北搬家, 全省搬家, 回頭車, 搬家服務, 搬家, 室內設計, 室內設計作品,

lee said...

提供坐月子中心簡介、健康飲食、月子餐外送服務、養生藥膳等坐月子中心資訊。

lee said...

提供婚禮部落格社群討論、新娘秘書婚紗攝影及傳統結婚習俗等資訊。

lee said...

Tutors家教網提供台北家教資訊,讓有家教需求的家長可以在本家教中心找到合適的家教老師

lee said...

使命必達徵信社提供婚前徵信、外遇抓姦、工商徵信、錄影拍照、行為蒐證等徵信服務。

lee said...

築園成家為提供房屋仲介 ,也就是房屋仲介網,除了買屋賣屋等資訊外,還有影音看屋功能。

lee said...

普普風室內設計網站提供室內裝潢、家居佈置、空間設計規劃、景觀櫥窗展場等室內設計資訊服務。

lee said...

慾望城市徵信專為外遇、婚外情、劈腿、婚前徵信或離婚等問題題,提供最佳的徵信服務

ann said...

福~
「朵
語‧,最一件事,就。好,你西...............................................................................................................................-...相互
,以讓>它使...................

水玲珑 said...

謝順福blog蔣萬安 blog高以翔圖片男紀香blog守護甜心漫畫王祖賢mv迷你漢堡余筱萍的照片猴頭菇食譜東部巨型蜘蛛羅家英 only you楓之穀遊戲薛景求mv史蒂芬金黑塔郭翰陽mv無名挖挖挖王傑莫綺雯mtv大堡礁島主 clare范植偉的照片朱麗倩的近況Makiyo milkiway吴亭欣bt迷霧驚魂報稅軟體瘦大腿的方法狼愛豬影片 狼愛豬影片 山田優 real you 禹承妍照片吳淑敏寫真n95型口罩 藤原紀香尹雪姬販毒溫昇豪部落格 賈靜雯部落格禹承妍自殺電玩少女瑤瑤開球 吳威廷blog時尚服飾,服裝搭配 祕魯議員萊昂 最新發型 豬哥亮廣告哈拉论坛汽车租赁

peter said...

PU超柔玉米跳蛋超柔細觸感花蝶的愛戀時尚豹紋雙跳蛋葫蘆凸粒G點凹凸愛潮G點長跳蛋舒爽長短激情七段甜蜜花紛超微米透明跳蛋插線老二閃耀光采粉紅老二葫蘆短蛋