1. No solid requirements
2. Misinterpretation of the requirements
   
3. Miscommunication or lack of communication among the team members
4. Sudden change of requirements
5. Change of requirements often.
6. Inadequate knowledge in programming or in testing
7. Unrealistic schedule
8. Unrealistic goal to reach or no goal to reach
9. Improper planning of the project.
10. Team member playing more than one role or not playing their role.

Which of the testing is better White box or Black Box and similarly the same question with Manual Testing with Automation testing?

To me, everything is important. In a normal process, we have black box testers and we don’t have separate white box testers. The developers of the project behave or has to behave as a white box testers. they have to do their unit testing, optimize their own coding. The black box tester would test the functionality of the project. Thus for a project there is a role of the White Box as well as Black Box Testers.

Coming to the Manual Tester Vs Automation Tester, the person in charge for the testing should analyze whether they should go for automation tools or for the manual testing. There are various criteria on which this decision is taken

1. Size of the project
2. Number of Resources
3. Complexity of the project
4. Schedule of the project
5. Type of application e.g. Web Based / Windows Based

Mainly, we go for the tools when we need to check the performance, stress, load etc which consumes more resources or time.

Even in automation testing, tool needs a manual input for writing the scripts there automation testing thus reduces the work rather than human resource.

No Not only the network based application, the desktop application would laso take a beat.

Why…..
What is it?
*
*
Starting at GMT 03:14:07, Tuesday, January 19, 2038, It is expected to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions, banking errors, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year In the first month of the year 2038 C.E. many computers will
encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and wildly inaccurate dates being reported by the operating systemand/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting “skip” in reported time anywhere from 1901 to a “broken record” repeat of the reported time at the second the bug occurs. Also, may make some small adjustment to the actual time the bug expresses itself. This bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will “run out of time”.

What causes it?

Time_t is a data type used by C and C++ programs to represent dates and times internally. (Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.)
time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM Greenwich Mean Time. A time_t value of 0 would be 12:00:00 AM (exactly midnight) 1-Jan-1970, a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc.. some
example times and their exact time_t representations:
Date & time time_t representation
1-Jan-1970, 12:00:00 AM GMT 0
1-Jan-1970, 12:01:00 AM GMT 60
1-Jan-1970, 01:00:00 AM GMT 3 600
2-Jan-1970, 12:00:00 AM GMT 86 400
1-Jan-1971, 12:00:00 AM GMT 31 536 000
1-Jan-1972, 12:00:00 AM GMT 63 072 000
1-Jan-2038, 12:00:00 AM GMT 2 145 916 800
19-Jan-2038, 03:14:07 AM GMT 2 147 483 647

By the year 2038, the time_t representation for the current time will be over 2 140 000 000. And that’s the problem. A modern 32-bit computer stores a “signed integer” data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself.
The highest number these 31 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program
will reach its upper limit.
One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes. When a signed integer reaches its maximum value and then gets incremented, it wraps around to its lowest possible negative value.
This means a 32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647 and then incremented by 1, will become -2 147 483 648.
Note that “-” sign at the beginning of this large number. A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT.

So, if all goes normally, 19-January-2038 will suddenly become 13-December-1901 in every time_t across the globe, and every date calculation based on this figure will go haywire. And it gets worse.

Most of the support functions that use the time_t data type cannot handle negative time_t values at all. They simply fail and return an error code.