Julius and Ethel Rosenberg Essay

The relationship between The United States and The Soviet Union after World War II was tense. This time was known as The Cold War. Although the two countries were allies during the war, they soon became enemies. Each country was trying to build up their nuclear arms and wanted to know what the other had in their arsenal. Although both countries had their share of spies, two very famous spies from the Soviet Union were Julius and Ethel Rosenberg. Julius Rosenberg was born on May 12, 1918 in New York City. After attending high school and the City College of New York, he graduated in 1939 with a degree in electrical engineering. Less than a year later, he married Ethel Greenglass and had two sons, Michael and Robert. Ethel was born on born September 28, 1915 in New York. The two met at the Young Communist League, which Julius was a leader in 1936 and later on they both joined the American Communist Party. Ethel worked as a secretary and Julius worked at a company until 1945 when Julius was fired from his job because he was suspected of being part of the American Communist Party, when in fact, he and Ethel dropped out of the party in 1943 so they could focus on Julius’s espionage doings. Julius Rosenberg was arrested on June 17th, 1950 for suspicion on espionage. His brother in law, David Greenglass gave his name when he confessed to espionage and was arrested. David also gave the name of his wife but not yet of Ethel. Ethel wasn’t arrested until August 11th. Although many people they were involved with gave names of other spies, the Rosenberg’s didn’t give any names. The FBI though Julius was â€Å"just the next in a row of falling dominoes, but unlike the dominoes in line before him, Julius did not tip over†(law2.umkc.edu).They were arrested for telling secrets to the soviet union. They were also involved with the Manhattan Project, the â€Å"top-secret effort of Allied scientists to develop an atomic bomb† ( law2.umkc.edu). When the Rosenberg’s wouldn’t give any Intel about the Manhattan project or anyone else in the spy ring, they were brought to trial. The Rosenberg’s were put on trial on March 6th, 1951. They were charged with conspiracy to commit espionage. â€Å"Treason could not be charged because the United States was not at war with the Soviet Union† (www.history.com). The Rosenberg’s attorneys were Emanuel and Alexander Bloch. â€Å"From the beginning, the trial attracted a high amount of media attention and generated a largely polarized response from observers† ( atomicarchive.com). Some people thought the Rosenberg’s were clearly guilty, others believed they were innocent. During the trial David Greenglass told the jury about the secrets Julius told to the Soviet Union. Bloch argued that â€Å"Greenglass was lying in order to gain revenge because he blamed Rosenberg for their failed business venture and to get a lighter sentence for himself† (sparticus.schoolnet.org). The trial ended on April 4th, it lasted almost a month. David Greenglass was sentenced to fifteen years in prison for his cooperation and admission of his guilt. Sobell was sentenced to 30 years in prison. Both Julius and Ethel Rosenberg were convicted and sentenced to death row on March 29th, 1951 under the espionage act. Although they had a way out of this by admitting to espionage and by giving names of other people in the spy ring, they refused. A lot of people were shocked and thought it was bad for the courts to orphan 2 young boys when there wasn’t even any evidence of the espionage, but they continued with it anyways. The Rosenberg’s continued to state their innocence until there execution. They were on death row for 26 months before they were executed by electric chair on their wedding anniversary, June 19th, 1953. Since the cold war ended, there has been confirmation that the Rosenberg’s were in fact spies and were guilty of espionage. This trial was so important to the cold war because it was the first time spies with little proof, were executed. The Rosenberg’s sons tried for many years to prove there parent’s innocence.

Frankenstein: The Meaning behind the Words Essay

Upon receiving all the books that we had to read during this course, Frankenstein was the one that I was looking most forward to reading. Most horror fiction novels have the same story line with no actual meaning behind the writing, but as I opened this novel and continued to read, I really became interested in the deeper meaning of Frankenstein and I just had to continue reading to find out more. Unlike most horror fiction novels, Frankenstein in my opinion has the ability to keep its readers interested instead of boring them. Mary Shelley used her writing ability to tell a great story that involved the relationship between man and mans creation. A major observation that I made while reading Frankenstein was of all the several themes made throughout the whole entire book. Some themes where obvious, others you really had to think about it. All though many people may think Shelley’s Frankenstein is just another normal horror fiction novel, I believe this novel provides several themes throughout the entire story line because it shows the themes of human injustice towards outsiders, ignorance is bliss, and society’s sexist viewpoints. The main theme that I noticed while reading Frankenstein, was the idea of human injustice towards outsides. All throughout the novel, the monster has to face man’s cruelty to those who are different. Frankenstein’s monster is indeed an outcast and he doesn’t belong in human society. The monster’s alienation from society, his struggle for revenge, and his unfulfilled desire for a companion, are all shared by his creator. I noticed while reading the novel how quickly Victor became similar his creation. Both Victor and his creation live in isolation from society, they both hate their miserable lives, and both Victor and his creation are suffering. Shelly did a very good job showing the relationship with man and his relationship with outsiders, and how cruel society can be when it comes to being different from everyone else. The monster states, â€Å"When I looked around I saw and heard of none like me. Was I, the, a monster, a blot upon the earth from which all men fled and whom all men disowned?† This quote explains itself. The monster was different, and therefore he was alone in the world. This was the easiest theme to recognize, in my opinion, because this theme plays a big role in society. Shelly’s writing shows exactly what people in society that are different go through, by showing it through Victor and his creation. A second theme that really stood out to me was the idea that ignorance is bliss. With the power of human reason, through science and technology, it challenged a lot of concepts about world and man’s relationship with his creator. This was the idea of Shelley’s time. Although this was a big concept, many questioned stressing the limits of human capacity. Shelley uses this theme in her book. She uses the idea in chapter four when Victor warns Walton to not follow in his footsteps stating, â€Å"Learn from me, if not by my precepts, at least by my example, how dangerous is the acquirement of knowledge and how much happier that man is who believes his native town to be the world, than he who aspires to become greater than his nature will allow† (38). During Shelley’s time, including many others, some aspects of nature should never be discovered by man. Shelly used both the new sciences of chemistry and electricity of life to conjure up the bodies of the dead. Victor is a man that clearly wanted to discover and did discover these aspects of nature and he stole the idea of creation from God and used it for his own ill-advised purposes. The third theme that I analyzed while reading Frankenstein, was the indicting towards society for its sexist viewpoints. Throughout Frankenstein, Victor sets the view for women as weak, suffering, non useful human beings who live to serve and depend on the men in their lives. Many people believe Shelly could have experienced these sexist points at one point in her own life, but she may or may not have agreed with it. In Frankenstein, Victor puts the name of a barbarian to the monster because the monster has a very good notion of the opposite sex. The monster, unlike Victor, believes that men and woman are equal and both should be treated equally. The monster, throughout the novel seeks companionship from a female, which does not convey a desire to rule a women or that a woman should have to depend on the men in her life. The monster states, â€Å"I am alone and miserable: man will not associate with me; but one as deformed and horrible as myself would not deny herself to me. My companion must be of the same species and have the same defects. This being you must create† (129). His desire for companionship just shows the monsters need for equal companionship with someone to share his sufferings. Frankenstein expressed several different themes all throughout the novel. The three themes discussed in this paper really stood out to me and I felt they played the biggest parts in the novel, but many of the other themes expressed in Frankenstein played a big role in making the novel what it is today. Shelly used these themes for her novel Frankenstein, to suggest the monster from the novel is some sort of metaphor of our own culture. Shelly’s way of using actual real world themes in her novel allowed her to show how these themes are actual portrayed in the world. Frankenstein is definitely one of the best horror fiction novels; not just because of the story, but because of the deeper meanings you can get from reading the novel. WORKS CITED Shelley, Mary. Frankenstein. New York: Dover, 1994.

Vancomycin-Resistant Enterococci and ambulation ( evidence based Dissertation

Vancomycin-Resistant Enterococci and ambulation ( evidence based practice ) - Dissertation Example In most instances, recognition of a practice problem prompts an evidence based practice (EPB). For instance, an EPB team with the goal of conducting an EPB project in a given duration would have to consider what outcomes by the patient need more improvement (Jones, 2004). Once a practice problem has been realized or determined, data both internal and external is collected. This data should be relevant to the practice problem to confirm that there is indeed the need for change and in the long run, improvement. It is crucial that the focus of evidence based practice is justified because it is resource intensive. A practice problem statement is also prepared so as to clarify what the evidence based practice is exactly (Fulton, 2010). The best evidence is also located using key actions. These are identifying the types and sources of evidence, making arrangements for the search for evidence, and conducting the search for best evidence. Types of evidence could include clinical practice gui delines, systematic reviews, expert reports, single studies as well as critical appraisal topics. The search of evidence is planned as a rigorous, systematic review, which would include formulating the research question to guide the search, selection of the research strategy, choosing the inclusion and exclusion criteria, and planning the synthesis (Kathleen, 2011). Clinical Question The nursing practice to be detailed is based on a hugely serious clinical question. The question seeks to establish whether patients acquired with Vancomycin-Resistant Enterococci (VRE) more likely to recondition due to physical therapy limitations. This is a clinical problem that requires research on how to handle it. The evidence also in his case is that patients with VRE are more likely to recondition due to physical therapy limitations. This is the main objective of evidence based research and what it entails (Parke, 2011). Literacy in significant information is required and access to adequate infor mation so that evidence based practice (EBP) can be researched. The patient is the main stakeholder, and their health is vital. Besides the fact that the infection brings various disadvantages to their movement, policies should be put in place that would encourage movement by them without increasing the risks of spreading the infections. Physical therapy has extremely strict rules in relation to ambulation, but still there exists other kinds of infections that are not warranted to this policy measure. Even though, lobby privileges are awarded to some patients, risks are still there related to spreading the infection because of the infectious risks the VRE has. The patient can still walk and not undergo confinement to bed. The only set back is that infection makes them confined in their rooms leading to physical inactivity. This has its health related hazards like muscle problems for instance muscle atrophy (Lawrenceville, 2006). Synthesis of Literature Literature reviews have been a ble to provide details of primary research in human health policy as well as their care. These are considered as the highest standards in evidence based health care. They help in the provision of evidence during the investigation of the responses to the interventions of prevention, rehabilitation as well as treatment. They also detail about how valuable and accurate a diagnostic test for a given

Government 2 Dissertation Example | Topics and Well Written Essays - 500 words - 3

Government 2 - Dissertation Example Either the Senate or the House of Representatives may introduce a bill; it must be approved by both parties. Though every bill must be signed by the President before it becomes a law, instances that the President does not sign, the House and the Senate will vote on it and should acquire a 2/3 majority for a bill to become a law. In instances that a certain law is said to be unjust or unfair, the courts can rule and decide if it remains a law or not. (Cook, p. 23) Democracy: Freedom of Expression Freedom of expression is the foundation of democracy. It is fundamental in all forms of freedoms. It is said to be the core freedom in which democracy will not be possible without it. This doesn’t entail freedom of speech alone but the right to write openly, speak freely and criticize injustices and incompetence. It gives the public the opportunity to voice out their opinions of any kind. Thus, without it, a country cannot be called democratic if voices of the public are limited or unh eard. Progressive Taxation The US currently has a progressive taxation system in which tax rates get much higher from the middle class to the upper class, making the lower class shoulder very minimal tax rates. (Surname) 2 In the 1980s, a revival against the current tax system was which had started in the early 20th century was seen.

Response Week 13 Essay Example | Topics and Well Written Essays - 250 words

Response Week 13 - Essay Example For example, she has mentioned the training employees on how to avoid and the effects of money laundering, implementation of money laundering laws and the need for Money Service Businesses (MSBs) to know how money laundering schemes work. In addition to what she has mentioned, I believe there are other techniques that organizations or the government can do to prevent these criminal activities. For example, more countries or organizations should meet to coordinate and share their models of legislation, trends and multilateral agreements. Currently only a few countries are active in these discussions. If all countries were to meet for such discussions, it would work because certain financial watchdogs such as the Financial Action Force (FATF) emerged from member countries having such international discussions. According to United Nations Office on Drugs and Crime (2003), the establishment of FAFT took place in year 1989 and it is an inter-governmental body. Its objective is to promote effective implementation of laws and measures that combat threats related to financial systems of member states (United Nations Office on Drugs and Crime, 2003). However, this is a preventive measure that would occur on a large-scale level. On a small-scale level, the due diligence for individuals matters. To remove ambiguity from a lower level, customers should prove their identity when carrying out financial transactions with valid personal identification documents, not only by using payment cards. When it comes to organizations, White (2013) asserts that businesses with legal documents of operations also engage in money laundering. Therefore, the best technique would be to have rules that require businesses to provide information about their intended transactions, nature of transactions and purpose of the business

Developing a Nursing Intervention to Encourage Healthy Eating Habits Research Proposal

Developing a Nursing Intervention to Encourage Healthy Eating Habits among Teenagers - Research Proposal Example This is a clear indication that consumption of an extensive variety of food especially during adolescence is more likely than not to set up preferences of food that will continue even in adulthood. Changes in food preferences during adulthood are quite difficult to change and therefore it would be much easier to cultivate healthy eating habits. Consumption of a healthy diet is the foundation of better growth and development for adolescents. Healthy eating allows adolescents to attain their educational potential following better brain development. Eating habits during childhood and adolescent often have an impact on the health of such an individual during adulthood. For example, adolescents who munch through outsized quantities of energy giving foods are more likely than not to become obese or even overweight. According to Booth et al. (2001), obese adolescents are more likely to obese even during their adulthood an as a result, they may suffer from illnesses related to obesity such a s heart disease as well as diabetes. Discussion Many healthy eating interventions have mainly focused on changes in nutrition intake. Nevertheless, a focused on food patterns, enjoyment of eating, food eating as well as the experience of food are according to Tapper, et al (2003) more likely to develop a positive nursing intervention to encourage healthy eating habits among teenagers that is long lasting. In their study on adolescent healthy eating Worsley and Skryzpiec (2004) make an attempt to define the term healthy eating to mean consumption of an extensive variety of vegetables, fresh fruit, dairy and animal products, wholegrain cereal foods, and also legumes. In an effort to develop a positive nursing intervention to encourage healthy eating habits among teenagers that is long lasting, the causes of concern about adolescent t eating must be identified. These causes of concern may vary from one adolescent to another, they include meal skipping, poor food preference and selectio n, excessive energy consumption, and fussy eating. The term food selection is used to connote the amount and type of food that individuals usually eat. The reliance on a limited variety of foods is therefore what is referred to as poor food selection. This usually involves selection of foods that contains huge amounts of sugar, salt, and fats. Other studies depict poor food selection as conception of foods which have low content of wholegrain foods, fruits, vegetables, and legumes. There have been concerns about meal skipping amongst adolescents. According to a study conducted by Pollitt and Mathews (1998), skipping meals such as breakfast or even lunch may result to cognitive as well as mood deficits. The tendency to prefer particular food over the other is also another big concern that results to poor eating habits in adolescents. Adolescents may learn to like new and healthy eating habits from repeated exposure to such food and practices especially through parental and peer encou ragement. By watching their parents and peers eating and enjoying healthy food, they can easily quite the bad eating habits and assume the healthy practice very easily (Palla, 2008). Among the adolescents, using coercive tactics as well as banning some foods may prove to

Costing and Economics Essay Example | Topics and Well Written Essays - 1000 words

Costing and Economics - Essay Example Prevention Costs: The planned costs incurred by an organization to ensure that errors are not made at any of the various stages during the delivery process of that product or service to a customer. The delivery process may include design, development, production and shipping. Examples of prevention costs include education and training, continuous improvement efforts, quality administration staff, process control, market research, field testing and preventive maintenance. Failure Costs: The costs incurred by a company because the product or service did not meet the requirements and the product had to be fixed or replaced or the service had to be repeated. These failure costs can be further subdivided in to two groups - Internal or External failures. Internal failures include all the costs resulting from the failures that are found before the product or service reaches the customer. Examples include scrap, rework, extra inventory, repair stations, re-design, salvage, corrective action reports and overtime due to nonconforming product or service. External failures are all the costs incurred by the company resulting when the customer finds the failure. These external failure costs do not include any of the personal costs of the customer. Examples of these costs include warranty, customer complaint administration, replacement product, recalls, shipping costs, analysis of warranty data, customer follow-up and field service departments. b) Relationship between Failure Costs and Prevention Costs: The following sketch illustrates that actual performance can fall short of customer satisfaction either because of quality of design failure or because of conformance quality failures. Actual Design Customer Performance Specifications Satisfaction Conformance Quality Quality of Design Failure Failure Conformance Quality refers to the performance of a product or service relative to its design and product specifications. For example, if a photocopying machine mishandles paper or breaks down, it fails to satisfy conformance quality. Products not conforming to specifications must be repaired, reworked, or scrapped at an additional cost to the organization. If non conformance errors remain after the product is shipped and the product breaks down at the customer site even greater repair costs as well as the loss of customer good will (often the highest quality cost) may result. Since as outlined above, there exists a strong relationship between prevention costs and failure costs, to ensure that actual performance achieves customer satisfaction companies must first design products to satisfy the customers through quality of designs, and they must then meet design specifications though conformance quality. Thus it may be seen that there is a direct relationship between the prevention cos t and failure costs and if the prevention costs are not taken care of by the company, it may lead to the incurring of additional quality costs in the form of internal or external failure costs.

HIV in african country Research Paper Example | Topics and Well Written Essays - 1500 words

HIV in african country - Research Paper Example The following are some of the cultural factors which contribute to increased rate of HIV/AIDS in South Africa. HIV in South Africa Tiruneh (2009, p.106) argues that in South Africa the rank of women is below that of men and the society is male dominated. During socialization, women are meant to the belief that women are inferior to them. Women are supposed to be submissive and have respect for men. Inequality in power between the two sexes put women at a higher risk of contracting the disease. Because of the position they hold in the society, women have no say on sexual matters. The choice of whether or not to use condoms is entirely depended on men. Discrimination against people with HIV makes it hard for prevention of the disease. Patients fear seeking medical assistance because they will be discriminated by the rest of the community members. Because of fear of signaling the HIV status, infected people fear adopting behaviors related to the disease. For instance, breast feeding mot hers continue to breastfeed their young children for fear that other people will question them the reasons behind lack of breastfeeding. Infected men fear using condom for fear of being suspected by their partners (Human Sciences Research Council, 2009, p.66). Sexuality is perceived as a source of economic benefit. Commercial sex workers are very many in South Africa, an aspect which contributes to the high rates of HIV and Aids transmission. Material possession and association with many partners is a sign of prestige among South African black men. In exchange for money and large gifts, young ladies are tempted to engage in sexual activities with aged men. The young ladies affect young men who in turn infect other women and the cycle goes on. The disease is also spread to older women by their husbands (Tiruneh, 2009, p.115). According to Tiruneh (2009, p.117), many people in South Africa, especially the illiterate ones, lack adequate knowledge concerning HIV disease, how it is trans mitted and the risks which expose an individual to the disease. Illiteracy levels are higher among girls who in most cases fail to complete basic education (Buve, Bishikwabo-Nsarhaza & Mutangadura, 2002, p.2014). The culture of South Africa requires women to undertake domestic chores which make them lack time to interact with the outside world. Lack of guidance and counseling on sexuality issues and poor access to protective devices like condoms make youths engage in unsafe sex. Other people fail to buy condoms for fear that it will portray them as immoral. Some of the cultural practices which are related to sexuality increase the prevalence of HIV and Aids disease. Many South Africans have negative attitudes toward condom use. First, it is associated to mistrust and unfaithfulness in relationships. Secondly, South African men believe that sex without condom is more pleasurable and it is good for human health (Brummer, 2002, p.12). Cultural Assessment Model Cultural assessment model s include research design, cross-cultural and panel. Ordinary Least Squares (OLS) regression will be used in the estimation of models used within the paper. The method will be used to determine the impacts that HIV disease has on regional, cultural, political and socioeconomic factors. Prevalence of the disease among the adult population will be used as the dependent variable. The number of infected people between the ages of 15

Jack Welshs Leadership Essay Example | Topics and Well Written Essays - 750 words

Jack Welshs Leadership - Essay Example He set up a priority of getting GE to occupy the #1 or #2 spot. Hence, he worked on massive changes to be implemented. Firstly, he sold almost 200 businesses of GE. He disposed off, the non-working, plagued businesses and acquired 370 acquisitions. He made the staffing 'lean and agile'. He also scrapped the strategic planning system and made it much simpler and focused. Besides this, he also took down massive downsizing, by removing employees who did not play an important role or contribution. He thus, retained only those employees who added value to the company. He also deleted the eight-level hierarchal system, reducing it to just half of it. 2. What is Welch's objective in the series of initiatives he launches in the late 1980's and early 1990s What is he trying to achieve in the round of changes he put in motion in that period Is there a logic or rationale supporting the change process Welsh clearly defined his objectives in the second phase of changes initiated. All the changes and activities he undertook had the underlying goal of creating a specific workplace culture. His intention was to create a culture that would be reflective of the company's brand image. More than this, the culture would give every employee the freedom to voice his opinion. His aim was to motivate a close-knit culture, where everyone could interact and work in cooperation and coordination for the best interest of the company. He also steered clear of the unnecessary bureaucratic pressure, in order to bring about a more focused work approach. He aimed at a decentralized method of work, with the building of small teams. However, he also believed in accountability. Welsh also took up the aspect of building a global business, as against a global company, in the wake of globalisation. This he did by strengthening and base and then moving across . Strenthening the quality of leadership in the organization was important, since teams had to function properly, for a collective overall work procedure. Every team was the micro unit of the whole macro company. In addition to this, a boundaryless functioning across the globe, with a collective and unified work culture was his vision. Hence, evidently, Welsh's strategies were aimed at changing with the changing times, especially in the wake of globalisation, without compromising on the company's culture and policies. 3. How does such a large, complex diversified conglomerate, defy the critics and continue to grow so profitably Have Welch's various initiatives added value If so, how GE has been a surprise spinner for many an on-looker. The critics continue to be surprised by its progress and innovation. Welsh's initiatives have always been towards

Childs Healthy Development in School Essay Example for Free

Childs Healthy Development in School Essay When people think of dramatic changes in children over time, they typically think about the first two or three years of life. Although these years are marked by striking changes, the developmental and social changes that occur between ages 6 and 14 are dramatic, as well. Imagine a six-year-old girl starting first grade—maybe she has braids in her hair and is wearing a cute dress; she looks like a little girl and she is likely to be quite excited about going off to school. Her parents still exercise great control over her comings and goings; their biggest worries are likely to be about her safety when crossing streets and about her adjustment to elementary school. Now imagine that same girl as a 14-year-old starting the ninth grade: She now looks like a full-grown woman, leading her parents to worry about the negative influences of peers, and the risk that she may come to physical harm during the many hours that she is away from home. Equally dramatic changes occur in the social contexts where youngsters spend time. A six-year-old boy is likely to be enrolled in a local neighborhood elementary school—perhaps within walking distance from home. By age 14, he will have changed schools at least once, moving into a junior high school or middle school. He may be looking forward to his classes, or he may have already psychologically turned his back on formal schooling. He may have sampled out-of-school activities from Scouts to basketball to handling a paper route. Because the experiences both boys and girls have in school and other activities will shape their development through this pivotal age period. Each period is marked by basic biological and cognitive changes, as well as changes in the social surroundings where children’s daily lives unfold. Exercising their growing autonomy in school and organized programs, children learn about the world outside the family, match themselves against the expectations of others, compare their performance with that of their peers, and develop customary ways of responding to challenges and learning opportunities. Through these years, they forge a personal identity, a self-concept, and an orientation toward achievement that will play a significant role in shaping their success in school, work, and life. Although researchers and policymakers have focused on the school as the critical arena in which development occurs and children’s futures are sculpted, out-of-school programs offer alternative environments in which children can learn about themselves and their worlds, and can discover opportunities for carving their own versions of success. Middle Childhood (6-8 years of age) Developmental Milestones Middle childhood brings many changes in a child’s life. By this time, children can dress themselves, catch a ball more easily using only their hands, and tie their shoes. Having independence from family becomes more important now. Events such as starting school bring children this age into regular contact with the larger world. Friendships become more and more important. Physical, social, and mental skills develop quickly at this time. This is a critical time for children to develop confidence in all areas of life, such as through friends, schoolwork, and sports. Here is some information on how children develop during middle childhood: Emotional/Social Changes Children in this age group might: * Show more independence from parents and family. * Start to think about the future. * Understand more about his or her place in the world. * Pay more attention to friendships and teamwork. * Want to be liked and accepted by friends. Thinking and Learning (Mental Changes) Children in this age group might: * Show rapid development of mental skills. * Learn better ways to describe experiences and talk about thoughts and feelings. * Have less focus on one’s self and more concern for others. Middle Childhood (9-11 years of age) Developmental Milestones Your child’s growing independence from the family and interest in friends might be obvious by now. Healthy friendships are very important to your child’s development, but peer pressure can become strong during this time. Children who feel good about themselves are more able to resist negative peer pressure and make better choices for themselves. This is an important time for children to gain a sense of responsibility along with their growing independence. Also, physical changes of puberty might be showing by now, especially for girls. Another big change children need to prepare for during this time is starting middle or junior high school. Here is some information on how children develop during middle childhood: Emotional/Social Changes Children in this age group might: * Start to form stronger, more complex friendships and peer relationships. It becomes more emotionally important to have friends, especially of the same sex. * Experience more peer pressure. * Become more aware of his or her body as puberty approaches. Body image and eating problems sometimes start around this age. Thinking and Learning (Mental Changes) Children in this age group might: * Face more academic challenges at school. * Become more independent from the family. * Begin to see the point of view of others more clearly. * Have an increased attention span. Young Teens (12-14 years of age). Developmental Milestones This is a time of many physical, mental, emotional, and social changes. Hormones change as puberty begins. Most boys grow facial and pubic hair and their voices deepen. Most girls grow pubic hair and breasts, and start their period. They might be worried about these changes and how they are looked at by others. This also will be a time when your teen might face peer pressure to use alcohol, tobacco products, and drugs. Other challenges can be eating disorders, depression, and family problems. At this age, teens make more of their own choices about friends, sports, studying, and school. They become more independent, with their own personality and interests, although parents are still very important. Here is some information on how young teens develop: Emotional/Social Changes Children in this age group might: * Show more concern about body image, looks, and clothes. * Focus on themselves; going back and forth between high expectations and lack of confidence. * Experience more moodiness. * Show more interest in and influence by peer group. * Express less affection toward parents; sometimes might seem rude or short-tempered. * Feel stress from more challenging school work. * Develop eating problems. Thinking and Learning ( Mental Changes ) Children in this age group might: * Have more ability for complex thought. * Be better able to express feelings through talking. * Develop a stronger sense of right and wrong. Changes in Social Surroundings The cognitive changes just described give children an expanded view of their social world and of themselves, providing the foundation for important social and emotional changes that also begin in these years. Along with their broadened exposure to adults and peers outside the family, children of these ages are typically given more freedom, more responsibilities, and more rights. This period is therefore marked by tensions between the new autonomy and the increasing expectations children encounter, which can either support or hamper the development of self-confidence. Broadening Social Worlds In the middle-childhood years, children spend less time under the supervision of their parents and come increasingly under the influence of teachers and activity Leaders such as Sunday school teachers, coaches of Little League sports, instructors of dance or ballet, music teachers, camp counselors, scout leaders. In contrast with the intimacy and familiarity that characterize family relationships, participation in school and formal programs exposes children to different Religious and ethnic groups, as well as diverse personal styles. They see adults acting in various social roles, and they see different adults acting in the same role—as teacher or camp counselor, for example. These experiences give children a chance to compare adults with one another and to observe how authority figures judge the behaviors and personalities of their peers. Increasingly, children spend time with their peers outside the orbit of parental control. Members of peer groups are responsible for managing their own relationships by controlling group dynamics, providing nurturance to each other, and sometimes establishing hierarchies within the group. As children get older, they also seek to contribute to their best friends’ happiness, and they become sensitive to what matters to other people. There is a beginning of a â€Å"we† feeling that goes beyond cooperation; children begin to adjust to the needs of others in pursuit of mutual interests. At the same time, of course, children are concerned with winning acceptance from their peers, and they must manage conflicts between the behavior expected of them by adults and the social goals of the peer group. Entering formal organizations such as schools and after-school programs represents a shift for children: In the preschool years, their social roles were defined for them at birth (as a daughter or a brother). In middle childhood, their roles in school, programs, and friendship groups reflect their personal qualities and achievements. 1. Developmental Variations: Behaviors within the Range of Expected Behaviors for That Age Group A) Developmental Variation : (Social Interaction Variation) Because of constitutional and/or psychological factors, children and adolescents will vary in their ability and desire to interact with other people. Less socially Adept or desirous children do not have a problem as long as it does not interfere with their normal development and activities. B) Common Developmental Presentations : Middle Childhood The child may not make friends easily and be less socially adept. The child may prefer solitary play at times. (Shyness) Adolescence The adolescent has limited concern regarding popular dress, interests, and activities. The adolescent finds it difficult to make friends at times. 2. PROBLEM: SHYNESS Middle Childhood The child is very shy, reticent, shows an increased concern about order and rules, is socially isolated, rarely initiates peer interactions, and prefers solitary activities to peer group activities. Adolescence The adolescent shows difficulty in social situations, has limited friendships, is socially isolated, may be a loner, prefers solitary activities to peer group activities, is reticent, has eccentric hobbies and interests, and has limited concern regarding popular styles of dress, behavior, or role models. Background Most people have felt shy at some time or in some situation. As many as 25% of high school and college students report having been shy most of their lives (Schwartz Johnson, 1985). Excessive shyness, however, reduces both the amount and quality of social interactions a child has with others and results in lowered peer acceptance and fewer opportunities to acquire social skills. It is not clear why some children are bashful and withdrawing whereas others tend to be more outgoing. Several factors may be involved, including genetics, temperament, anxiety, and lack of social skills. Development Some degree of shyness in children is to be expected and is part of the childs normal development (Berk, 1989). A fairly high percentage of preschoolers are described as bashful and avoiding contact with others (Schwartz Johnson, 1985). Between 30% and 50% of school-age children report feeling shy (Peterson, 1987). When shyness is experienced by the child in many or most situations over an extended period of time, interventions to help the child interact more appropriately are called for. Chronic and severe shyness can have a negative impact on social, emotional, and academic development. Shy children often have poor self-concept, feelings of failure, and make negative self-statements. The anxiety that accompanies shyness impairs memory and concentration and may keep children from asking for needed help in school. What Can I Do as a Parent? It will be important for your child to learn ways to reduce his or her anxiety in social situations. If the child does not possess the social skills needed to interact with others, it may be necessary to teach social skills directly. The child also needs to learn to feel better about himself or herself as a person. There are many ways to accomplish these goals. Make sure your child knows that they are loved and valued regardless of their behavior or performance. Talk with your child. about their experiences and help them to evaluate those experiences in nonjudgmental ways that allow them to feel good about themselves. Many times children judge themselves much more harshly than we realize and blame themselves for situations and events they cannot control. As a parent, you can give your child more independence and opportunities to demonstrate responsibility. Successful handling of independence and responsibility will help to foster an improved self-image. A childs image of himself or herself is built on a foundation of many small experiences. The more of those that demonstrate to the child that they possess the capability to succeed, the better the resulting self-image will be. Parents can seek out and provide activities that will allow the child to experience success in social environments. Structured group activities or small groups of one or two other children may facilitate success for the shy child. Parents can discuss, rehearse, and role-play activities with children such as introducing oneself, asking a peer to play, or joining a group of children who are playing a game. If the child is involved in a social-skills training program, parents can reinforce targeted social skills and provide opportunities for rehearsal of skills. If your child is severely shy and inhibited in most situations, the best course of action may include seeking professional help, either through the school, local mental health agency, or your family physician. Severe shyness affects many aspects of the childs life and should not be left unaddressed. What Can I Do as a Teacher? Shy children may be easily overlooked in a busy classroom because they do not present classroom management problems and usually comply with instructions. Teachers need to be sensitive to the needs of shy children and facilitate their interaction with others and their participation in the class. Because shy children are often characterized by anxiety, it is best to avoid drawing attention to them or putting them in situations that will require that they be the center of attention. Structured interactions and small group activities may best facilitate participation by shy students. When children are to work on projects in small groups, the teacher should form the groups rather than allowing students to group themselves. Teachers can take this opportunity to pair shy youngsters with socially competent students who will serve as models for them. Teachers need to avoid reinforcing shy behavior, to be sensitive to the needs of shy children but to refrain from giving the shy child special attention or privileges. When shy children interact appropriately that is the behavior that should be reinforced. There is a natural tendency to either ignore or be overly protective of shy children, but neither of these responses benefits the child. Shy children should be encouraged to interact, provided with opportunities to interact in small, structured settings, and reinforced for interacting. Direct social-skills training and contingency management procedures have been found to produce positive results and may be beneficial for the entire class.

Factors Affecting Web Applications Maintenance

Factors Affecting Web Applications Maintenance Chapter 1 1.1 Introduction Software engineering [PRE01] is the process associated with industrial quality software development, the methods used to analyze, design test computer Software, the management techniques associated with the control monitoring of Software projects the tools used to support process, methods, techniques. In Software Development Life Cycle, the focus is on the activities like feasibility study, requirement analysis, design, coding, testing, maintenance. Feasibility study involves the issues like technical/economical/ behavioral feasibility of project. Requirement analysis [DAV93] emphasizes on identifying the needs of the system producing the Software Requirements Specification document (SRS), [JAL04] that describes all data, functional behavioral requirements, constraints, validation requirements for Software. Software Design is to plan a solution of the problem specified by the SRS document, a step in moving from the problem domain to the solution domain. The output of this phase is the design document. Coding is to translate the design of the system into code in a programming language. Testing is the process to detect defects minimize the risk associated with the residual defects. The activities carried out after the delivery of the software comprises the maintenance phase. 1.2 Evolution of Software Testing Discipline The effective functioning of modern systems depends on our ability to produce software in a cost-effective way. The term software engineering was first used at a 1968 NATO workshop in West Germany. It focused on the growing software crisis. Thus we see that the software crisis on quality, reliability, high costs etc. started way back when most of todays software testers were not even born. The attitude towards Software Testing [BEI90] underwent a major positive change in the recent years. In the 1950s when Machine languages were used, testing was nothing but debugging. When in the 1960s, compilers were developed, testing started to be considered a separate activity from debugging. In the 1970s when the software engineering concepts were introduced, software testing began to evolve as a technical discipline. Over the last two decades there has been an increased focus on better, faster and cost-effective software. Also there has been a growing interest in software safety, protection and security and hence an increased acceptance of testing as a technical discipline and also a career choice. Now to answer, What is Testing? we can go by the famous definition of Myers [MYE79], which says, Testing is the process of executing a program with the intent of finding errors. According to Humphrey, software testing is defined as, the execution of a program to find its faults. Testing is the process to prove that the software works correctly [PRA06]. Software testing is a crucial aspect of the software life cycle. In some form or the other it is present at each phase of (any) software development or maintenance model. The importance of software testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spend 40-50% of its effort on testing. During testing, the software engineering produces a series of test cases that are used to rip apart the software they have produced. Testing is the one step in the software process that can be seen by the developer as destructive instead of constructive. Software engineers are typically constructive people and testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors are identified. A successful test is one that finds a defect. This sounds simple enough, but there is much to consider when we want to do software testing. Besides finding faults, we may also be interested in testing performance, safety, fault-tolerance or security. Testing often becomes a question of economics. For projects of a large size, more testing will usually reveal more bugs. The question then becomes when to stop testing, and what is an acceptable level of bugs. This is the question of good enough software. Testing is the process of verifying that a product meets all requirements. A test is never complete. When testing software the goal should never be a product completely free from defects, because its impossible. According to Peter Nielsen, The average is 16 faults per 1000 lines of code when the programmer has tested his code and it is believed to be correct. When looking at a larger project, there are millions of lines of code, which makes it impossible to find all present faults. Far too often products are released on the market with poor quality. Errors are often uncovered by users, and in that stage the cost of removing errors is large in amount. 1.3 Objectives of Testing Glen Myers [MYE79] states a number of rules that can serve well as testing objectives: Testing is a process of executing a program with the intent of finding an error. A good test is one that has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as yet undiscovered error. The objective is to design tests that systematically uncover different classes of errors do so with a minimum amount of time effort. Secondary benefits include Demonstrate that Software functions appear to be working according to specification. That performance requirements appear to have been met. Data collected during testing provides a good indication of Software reliability some indication of Software quality. Testing cannot show the absence of defects, it can only show that Software defects are present. 1.4 Software Testing Its Relation with Software Life Cycle Software testing should be thought of as an integral part of the Software process an activity that must be carried out throughout the life cycle. Each phase in the Software lifecycle has a clearly different end product such as the Software requirements specification (SRS) documentation, program unit design program unit code. Each end product can be checked for conformance with a previous phase against the original requirements. Thus, errors can be detected at each phase of development. Validation Verification should occur throughout the Software lifecycle. Verification is the process of evaluating each phase end product to ensure consistency with the end product of the previous phase. Validation is the process of testing Software, or a specification, to ensure that it matches user requirements. Software testing is that part of validation verification associated with evaluating analysing program code. It is one of the two most expensive stages within the Software lifecycle, the other being maintenance. Software testing of a product begins after the development of the program units continues until the product is obsolete. Testing fixing can be done at any stage in the life cycle. However, the cost of finding fixing errors increases dramatically as development progresses. Changing a Requirements document during the first review is inexpensive. It costs more when requirements change after the code has been written: the code must be rewritten. Bug fixes are much cheaper when programmers find their own errors. Fixing an error before releasing a program is much cheaper than sending new disks, or even a technician to each customers site to fix it later. It is illustrated in Figure 1.1. The types of testing required during several phases of Software lifecycle are described below: Requirements Requirements must be reviewed with the client; rapid prototyping can refine requirements accommodate changing requirements. Specification The specifications document must be checked for feasibility, traceability, completeness, absence of contradictions ambiguities. Specification reviews (walkthroughs or inspections) are especially effective. Design Design reviews are similar to specification reviews, but more technical. The design must be checked for logic faults, interface faults, lack of exception handling, non-conformance to specifications. Implementation Code modules are informally tested by the programmer while they are being implemented (desk checking). Thereafter, formal testing of modules is done methodically by a testing team. This formal testing can include non-execution-based methods (code inspections walkthroughs) execution-based methods (black-box testing, white-box testing). Integration Integration testing is performed to ensure that the modules combine together correctly to achieve a product that meets its specifications. Particular care must be given to the interfaces between modules. The appropriate order of combination must be determined as top-down, bottom-up, or a combination thereof. Product Testing The functionality of the product as a whole is checked against its specifications. Test cases are derived directly from the specifications document. The product is also tested for robustness (error-handling capabilities stress tests). All source code documentation are checked for completeness consistency. Acceptance Testing The Software is delivered to the client, who tests the Software on the actual h/w, using actual data instead of test data. A product cannot be considered to satisfy its specifications until it has passed an acceptance test. Commercial off-the-shelf (or shrink-wrapped) Software usually undergoes alpha beta testing as a form of acceptance test. Maintenance Modified versions of the original product must be tested to ensure that changes have been correctly implemented. Also, the product must be tested against previous test cases to ensure that no inadvertent changes have been introduced. This latter consideration is termed regression testing. Software Process Management The Software process management plan must undergo scrutiny. It is especially important that cost duration estimates be checked thoroughly. If left unchecked, errors can propagate through the development lifecycle amplify in number cost. The cost of detecting fixing an error is well documented is known to be more costly as the system develops. An error found during the operation phase is the most costly to fix. 1.5 Principles of Software Testing Software testing is an extremely creative intellectually challenging task. The following are some important principles [DAV95] that should be kept in mind while carrying Software testing [PRE01] [SUM02]: Testing should be based on user requirements: This is in order to uncover any defects that might cause the program or system to fail to meet the clients requirements. Testing time resources are limited: Avoid redundant tests. It is impossible to test everything: Exhaustive tests of all possible scenarios are impossible, because of the many different variables affecting the system the number of paths a program flow might take. Use effective resources to test: This represents use of the most suitable tools, procedures individuals to conduct the tests. Only those tools should be used by the test team that they are confident familiar with. Testing procedures should be clearly defined. Testing personnel may be a technical group of people independent of the developers. Test planning should be done early: This is because test planning can begin independently of coding as soon as the client requirements are set. Test for invalid unexpected input conditions as well as valid conditions: The program should generate correct messages when an invalid test is encountered should generate correct results when the test is valid. The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found. Testing should begin at the module: The focus of testing should be concentrated on the smallest programming units first then expand to other parts of the system. Testing must be done by an independent party: Testing should not be performed by the person or team that developed the Software since they tend to defend the correctness of the program. Assign best personnel to the task: Because testing requires high creativity responsibility only the best personnel must be assigned to design, implement, analyze test cases, test data test results. Testing should not be planned under the implicit assumption that no errors will be found. Testing is the process of executing Software with the intention of finding errors. Keep Software static during test: The program must not be modified during the implementation of the set of designed test cases. Document test cases test results. Provide expected test results if possible: A necessary part of test documentation is the specification of expected results, even though it is impractical. 1.6 Software Testability Its Characteristics Testability is the ability of Software (or program) with which it can easily be tested [PRE01] [SUM02]. The following are some key characteristics of testability: The better it works, the more efficient is testing process. What you see is what you test (WYSIWYT). The better it is controlled, the more we can automate or optimize the testing process. By controlling the scope of testing we can isolate problems perform smarter retesting. The less there is to test, the more quickly we can test it. The fewer the changes, the fewer the disruptions to testing. The more information we have, the smarter we will test. 1.7 Stages in Software Testing Process Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules that are composed of procedures functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of five stages that are illustrated in Table 1.1. Errors in program components, say may come to light at a later stage of the testing process. The process is therefore an iterative one with information being fed back from later stages to earlier parts of the process. The iterative testing process is illustrated in Figure 1.2 and described below: Unit Testing: Unit testing is code-oriented testing. Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. Module Testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures functions. A module encapsulates related components so it can be tested without other system modules. Sub-system (Integration) Testing: This phase involves testing collections of modules, which have been integrated into sub-systems. It is a design-oriented testing is also known as integration testing. Sub-systems may be independently designed implemented. The most common problems, which arise in large Software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces. System Testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems system components. It is also concerned with validating that the system meets its functional non-functional requirements. Acceptance Testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors omissions in the systems requirements definition (user-oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. 1.8 The V-model of Testing To test an entire software system, tests on different levels are performed. The V model [FEW99], shown in figure 1.3, illustrates the hierarchy of tests usually performed in software development projects. The left part of the V represents the documentation of an application, which are the Requirement specification, the Functional specification, System design, the Unit design. Code is written to fulfill the requirements in these specifications, as illustrated in the bottom of the V. The right part of the V represents the test activities that are performed during development to ensure that an application corresponding to its requirements. Unit tests are used to test that all functions and methods in a module are working as intended. When the modules have been tested, they are combined and integration tests are used to test that they work together as a group. The unit- and integration test complement the system test. System testing is done on a complete system to validate that it corresponds to the system specification. A system test includes checking if all functional and all non-functional requirements have been met. Unit, integration and system tests are developer focused, while acceptance tests are customer focused. Acceptance testing checks that the system contains the functionality requested by the customer, in the Requirement specification. Customers are usually responsible for the acceptance tests since they are the only persons qualified to make the judgment of approval. The purpose of the acceptance tests is that after they are preformed, the customer knows which parts of the Requirement specification the system satisfies. 1.9 The Testing Techniques To perform these types of testing, there are three widely used testing techniques. The above said testing types are performed based on the following testing techniques: Black-Box testing technique Black box testing (Figure 1.4) is concerned only with testing the specification. It cannot guarantee that the complete specification has been implemented. Thus black box testing is testing against the specification and will discover faultsofomission, indicating that part of the specification has not been fulfilled. It is used for testing based solely on analysis of requirements (specification, user documentation). In Black box testing, test cases are designed using only the functional specification of the software i.e without any knowledge of the internal structure of the software. For this reason, black-box testing is also known as functional testing. Black box tests are performed to assess how well a program meets its requirements, looking for missing or incorrect functionality. Functional testing typically exercise code with valid or nearly valid input for which the expected output is known. This includes concepts such as boundary values. Performance tests evaluate response time, memory usage, throughput, device utilization, and execution time. Stress tests push the system to or beyond its specified limits to evaluate its robustness and error handling capabilities. Reliability tests monitor system response to represent user input, counting failures over time to measure or certify reliability. Black box Testing refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and does not make use of source code testing of any kind. In the security paradigm, malicious input can be supplied to the program in an effort to cause it to break. If the program breaks during a particular test, then a security problem may have been discovered. Black box testing is possible even without access to binary code. That is, a program can be tested remotely over a network. All that is required is a program running somewhere that is accepting input. If the tester can supply input that the program consumes (and can observe the effect of the test), then black box testing is possible. This is one reason that real attackers often resort to black box techniques. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches. Black box testing tries to find errors in the following categories: Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors, and Initialization and termination errors. By applying black box approaches we produce a set of test cases that fulfill requirements: Test cases that reduce the number of test cases to achieve reasonable testing Test cases that tell us something about the presence or absence of classes of errors. The methodologies used for black box testing have been discussed below: 1.9.1.1 Equivalent Partitioning Equivalence partitioning is a black box testing approach that splits the input domain of a program into classes of data from which test cases can be produced. An ideal test case uncovers a class of errors that may otherwise before the error is detected. Equivalence partitioning tries to outline a test case that identifies classes of errors. Test case design for equivalent partitioning is founded on an evaluation of equivalence classes for an input condition [BEI95]. An equivalence class depicts a set of valid or invalid states for the input condition. Equivalence classes can be defined based on the following [PRE01]: If an input condition specifies a range, one valid and two invalid equivalence classes are defined. If an input condition needs a specific value, one valid and two invalid equivalence classes are defined. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined. If an input condition is Boolean, one valid and invalid class is outlined. 1.9.1.2 Boundary Value Analysis A great many errors happen at the boundaries of the input domain and for this reason boundary value analysis was developed. Boundary value analysis is test case design approach that complements equivalence partitioning. BVA produces test cases from the output domain also [MYE79]. Guidelines for BVA are close to those for equivalence partitioning [PRE01]: If an input condition specifies a range bounded by values a and b, test cases should be produced with values a and b, just above and just below a and b, respectively. If an input condition specifies various values, test cases should be produced to exercise the minimum and maximum numbers. Apply guidelines above to output conditions. If internal program data structures have prescribed boundaries, produce test cases to exercise that data structure at its boundary. White-Box testing technique White box testing (Figure 1.5) is testing against the implementation as it is based on analysis of internal logic (design, code etc.) and will discover faultsofcommission, indicating that part of the implementation is faulty. Designing white-box test cases requires thorough knowledge of the internal structure of software, and therefore the white-box testing is also called the structural testing. White box testing is performed to reveal problems with the internal structure of a program. A common goal of white-box testing is to ensure a test case exercises every path through a program. A fundamental strength that all white box testing strategies share is that the entire software implementation is taken into account during testing, which facilitates error detection even when the software specification is vague or incomplete. The effectiveness or thoroughness of white-box testing is commonly expressed in terms of test or code coverage metrics, which measure the fraction of code exercised by test cases. White box Testing involves analyzing and understanding source code. Sometimes only binary code is available, but if you decompile a binary to get source code and then study the code, this can be considered a kind of white box testing as well. White box testing is typically very effective in finding programming errors and implementation errors in software. In some cases this activity amounts to pattern matching and can even be automated with a static analyzer. White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that: Guarantee that all independent paths in a module have been exercised at least once Exercise all logical decisions Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity. There are several methodologies used for white box testing. We discuss some important ones below. 1.9.2.1 Statement Coverage The statement coverage methodology aims to design test cases so as to force the executions of every statement in a program at least once. The principal idea governing the statement coverage methodology is that unless a statement is executed, we have way of determining if an error existed in that statement. In other words, the statement coverage criterion [RAP85] is based on the observation that an error existing in one part of a program cannot be discovered if the part of the program containing the error and generating the failure is not executed. However, executed a statement once and that too for just one input value and observing that it behaves properly for that input value is no guarantee that it will behave correctly for all inputs. 1.9.2.2 Branch Coverage In branch coverage testing, test cases are designed such that the different branch conditions are given true and false values in turn. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing criterion than the statement coverage testing [RAP85]. 1.9.2.3 Path Coverage The path coverage based testing strategy requires designing test cases such that all linearly independents paths in the program are executed at least once. A linearly independent path is defined in terms of the control flow graph (CFG) of the program. 1.9.2.4 Loop testing Loops are very important constructs for generally all the algorithms. Loop testing is a white box testing technique. It focuses exclusively on the validity of loop constructs. Simple loop, concatenated loop, nested loop, and unstructured loop are four different types of loops [BEI90] as shown in figure 1.6. Simple Loop: The following set of tests should be applied to simple loop where n is the maximum number of allowable passes thru the loop: Skip the loop entirely. Only one pass thru the loop. Two passes thru the loop. M passes thru the loop where m N-1, n, n+1 passes thru the loop. Nested Loop: Beizer [BEI90] approach to the nested loop Start at the innermost loop. Set all other loops to minimum value. Conduct the simple loop test for the innermost loop while holding the outer loops at their minimum iteration parameter value. Work outward, conducting tests for next loop, but keeping all other outer loops at minimum values and other nested loops to typical values. Continue until all loops have been tested. Concatenated loops: These can be tested using the approach of simple loops if each loop is independent of other. However, if the loop counter of loop 1 is used as the initial value for loop 2 then approach of nested loop is to be used. Unstructured loop: This class of loops should be redesigned to reflect the use of the structured programming constructs. 1.9.2.5 McCabes Cyclomatic Complexity The McCabes Cyclomatic Complexity [MCC76] of a program defines the number of independent paths in a program. Given a control flow Graph G of a program, the McCabes Cyclomatic Complexity V(G) can be computed as: V(G)=E-N+2 Where E is the number of edges in the control flow graph and N is the number of nodes of the control flow graph. The cyclomatic complexity value of a program defines the number of independent paths in the basis set of the program and provides a lower bound for the number of test cases that must be conducted to ensure that all statements have been executed at least once. Knowing the number of test cases required does not make it easy to derive the test cases, it only gives an indication of the minimum number of test cases required. The following is the sequences of steps that need to be undertaken for deriving the path coverage based test case of a program. Draw the CFG. Calculate Cyclomatic Complexity V(G). Calculate the basis set of linearly independent paths. Prepare a test case that will force execution of each path in the basis set. 1.9.2.6 Data Flow based Testing The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program. Various data flow testing approaches have been examined [FRA88] [NTA88] [FRA93]. For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables. For a statement with S as its statement number, DEF(S) = {X| statement S contains a definition of X} USE(S) = {X| statement S contains a use of X} If statement S is if or loop statement, its DEF set is left empty and its USE set is founded on the condition of statement S. The definition of a variable X at statement S is live at statement S, if there exists a path from statement S to S which does not contain any condition of X. A definition-use chain (or DU chain) of variable X is of the type [X,S,S] where S and S are statement numbers, X is in DEF(S), USE(S), and the definition of X in statement S is live at statement S. One basic data flow testing strategy is that each DU chain be covered at least once. Data flow testing strategies are helpful for choosing test paths of a program including nested if and loop statements 1.9.3 Grey-Box testing technique Grey box testing [BIN99] designs test cases using both responsibility-based (black box) and implementation-based (white box) approaches. To completely test a web application one needs to combine the two approaches, White-box and Black-box testing. It is used for testing of Web based applications. The Gray-box testing approach takes into account all components ma Factors Affecting Web Applications Maintenance Factors Affecting Web Applications Maintenance Chapter 1 1.1 Introduction Software engineering [PRE01] is the process associated with industrial quality software development, the methods used to analyze, design test computer Software, the management techniques associated with the control monitoring of Software projects the tools used to support process, methods, techniques. In Software Development Life Cycle, the focus is on the activities like feasibility study, requirement analysis, design, coding, testing, maintenance. Feasibility study involves the issues like technical/economical/ behavioral feasibility of project. Requirement analysis [DAV93] emphasizes on identifying the needs of the system producing the Software Requirements Specification document (SRS), [JAL04] that describes all data, functional behavioral requirements, constraints, validation requirements for Software. Software Design is to plan a solution of the problem specified by the SRS document, a step in moving from the problem domain to the solution domain. The output of this phase is the design document. Coding is to translate the design of the system into code in a programming language. Testing is the process to detect defects minimize the risk associated with the residual defects. The activities carried out after the delivery of the software comprises the maintenance phase. 1.2 Evolution of Software Testing Discipline The effective functioning of modern systems depends on our ability to produce software in a cost-effective way. The term software engineering was first used at a 1968 NATO workshop in West Germany. It focused on the growing software crisis. Thus we see that the software crisis on quality, reliability, high costs etc. started way back when most of todays software testers were not even born. The attitude towards Software Testing [BEI90] underwent a major positive change in the recent years. In the 1950s when Machine languages were used, testing was nothing but debugging. When in the 1960s, compilers were developed, testing started to be considered a separate activity from debugging. In the 1970s when the software engineering concepts were introduced, software testing began to evolve as a technical discipline. Over the last two decades there has been an increased focus on better, faster and cost-effective software. Also there has been a growing interest in software safety, protection and security and hence an increased acceptance of testing as a technical discipline and also a career choice. Now to answer, What is Testing? we can go by the famous definition of Myers [MYE79], which says, Testing is the process of executing a program with the intent of finding errors. According to Humphrey, software testing is defined as, the execution of a program to find its faults. Testing is the process to prove that the software works correctly [PRA06]. Software testing is a crucial aspect of the software life cycle. In some form or the other it is present at each phase of (any) software development or maintenance model. The importance of software testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spend 40-50% of its effort on testing. During testing, the software engineering produces a series of test cases that are used to rip apart the software they have produced. Testing is the one step in the software process that can be seen by the developer as destructive instead of constructive. Software engineers are typically constructive people and testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors are identified. A successful test is one that finds a defect. This sounds simple enough, but there is much to consider when we want to do software testing. Besides finding faults, we may also be interested in testing performance, safety, fault-tolerance or security. Testing often becomes a question of economics. For projects of a large size, more testing will usually reveal more bugs. The question then becomes when to stop testing, and what is an acceptable level of bugs. This is the question of good enough software. Testing is the process of verifying that a product meets all requirements. A test is never complete. When testing software the goal should never be a product completely free from defects, because its impossible. According to Peter Nielsen, The average is 16 faults per 1000 lines of code when the programmer has tested his code and it is believed to be correct. When looking at a larger project, there are millions of lines of code, which makes it impossible to find all present faults. Far too often products are released on the market with poor quality. Errors are often uncovered by users, and in that stage the cost of removing errors is large in amount. 1.3 Objectives of Testing Glen Myers [MYE79] states a number of rules that can serve well as testing objectives: Testing is a process of executing a program with the intent of finding an error. A good test is one that has a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as yet undiscovered error. The objective is to design tests that systematically uncover different classes of errors do so with a minimum amount of time effort. Secondary benefits include Demonstrate that Software functions appear to be working according to specification. That performance requirements appear to have been met. Data collected during testing provides a good indication of Software reliability some indication of Software quality. Testing cannot show the absence of defects, it can only show that Software defects are present. 1.4 Software Testing Its Relation with Software Life Cycle Software testing should be thought of as an integral part of the Software process an activity that must be carried out throughout the life cycle. Each phase in the Software lifecycle has a clearly different end product such as the Software requirements specification (SRS) documentation, program unit design program unit code. Each end product can be checked for conformance with a previous phase against the original requirements. Thus, errors can be detected at each phase of development. Validation Verification should occur throughout the Software lifecycle. Verification is the process of evaluating each phase end product to ensure consistency with the end product of the previous phase. Validation is the process of testing Software, or a specification, to ensure that it matches user requirements. Software testing is that part of validation verification associated with evaluating analysing program code. It is one of the two most expensive stages within the Software lifecycle, the other being maintenance. Software testing of a product begins after the development of the program units continues until the product is obsolete. Testing fixing can be done at any stage in the life cycle. However, the cost of finding fixing errors increases dramatically as development progresses. Changing a Requirements document during the first review is inexpensive. It costs more when requirements change after the code has been written: the code must be rewritten. Bug fixes are much cheaper when programmers find their own errors. Fixing an error before releasing a program is much cheaper than sending new disks, or even a technician to each customers site to fix it later. It is illustrated in Figure 1.1. The types of testing required during several phases of Software lifecycle are described below: Requirements Requirements must be reviewed with the client; rapid prototyping can refine requirements accommodate changing requirements. Specification The specifications document must be checked for feasibility, traceability, completeness, absence of contradictions ambiguities. Specification reviews (walkthroughs or inspections) are especially effective. Design Design reviews are similar to specification reviews, but more technical. The design must be checked for logic faults, interface faults, lack of exception handling, non-conformance to specifications. Implementation Code modules are informally tested by the programmer while they are being implemented (desk checking). Thereafter, formal testing of modules is done methodically by a testing team. This formal testing can include non-execution-based methods (code inspections walkthroughs) execution-based methods (black-box testing, white-box testing). Integration Integration testing is performed to ensure that the modules combine together correctly to achieve a product that meets its specifications. Particular care must be given to the interfaces between modules. The appropriate order of combination must be determined as top-down, bottom-up, or a combination thereof. Product Testing The functionality of the product as a whole is checked against its specifications. Test cases are derived directly from the specifications document. The product is also tested for robustness (error-handling capabilities stress tests). All source code documentation are checked for completeness consistency. Acceptance Testing The Software is delivered to the client, who tests the Software on the actual h/w, using actual data instead of test data. A product cannot be considered to satisfy its specifications until it has passed an acceptance test. Commercial off-the-shelf (or shrink-wrapped) Software usually undergoes alpha beta testing as a form of acceptance test. Maintenance Modified versions of the original product must be tested to ensure that changes have been correctly implemented. Also, the product must be tested against previous test cases to ensure that no inadvertent changes have been introduced. This latter consideration is termed regression testing. Software Process Management The Software process management plan must undergo scrutiny. It is especially important that cost duration estimates be checked thoroughly. If left unchecked, errors can propagate through the development lifecycle amplify in number cost. The cost of detecting fixing an error is well documented is known to be more costly as the system develops. An error found during the operation phase is the most costly to fix. 1.5 Principles of Software Testing Software testing is an extremely creative intellectually challenging task. The following are some important principles [DAV95] that should be kept in mind while carrying Software testing [PRE01] [SUM02]: Testing should be based on user requirements: This is in order to uncover any defects that might cause the program or system to fail to meet the clients requirements. Testing time resources are limited: Avoid redundant tests. It is impossible to test everything: Exhaustive tests of all possible scenarios are impossible, because of the many different variables affecting the system the number of paths a program flow might take. Use effective resources to test: This represents use of the most suitable tools, procedures individuals to conduct the tests. Only those tools should be used by the test team that they are confident familiar with. Testing procedures should be clearly defined. Testing personnel may be a technical group of people independent of the developers. Test planning should be done early: This is because test planning can begin independently of coding as soon as the client requirements are set. Test for invalid unexpected input conditions as well as valid conditions: The program should generate correct messages when an invalid test is encountered should generate correct results when the test is valid. The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found. Testing should begin at the module: The focus of testing should be concentrated on the smallest programming units first then expand to other parts of the system. Testing must be done by an independent party: Testing should not be performed by the person or team that developed the Software since they tend to defend the correctness of the program. Assign best personnel to the task: Because testing requires high creativity responsibility only the best personnel must be assigned to design, implement, analyze test cases, test data test results. Testing should not be planned under the implicit assumption that no errors will be found. Testing is the process of executing Software with the intention of finding errors. Keep Software static during test: The program must not be modified during the implementation of the set of designed test cases. Document test cases test results. Provide expected test results if possible: A necessary part of test documentation is the specification of expected results, even though it is impractical. 1.6 Software Testability Its Characteristics Testability is the ability of Software (or program) with which it can easily be tested [PRE01] [SUM02]. The following are some key characteristics of testability: The better it works, the more efficient is testing process. What you see is what you test (WYSIWYT). The better it is controlled, the more we can automate or optimize the testing process. By controlling the scope of testing we can isolate problems perform smarter retesting. The less there is to test, the more quickly we can test it. The fewer the changes, the fewer the disruptions to testing. The more information we have, the smarter we will test. 1.7 Stages in Software Testing Process Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules that are composed of procedures functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of five stages that are illustrated in Table 1.1. Errors in program components, say may come to light at a later stage of the testing process. The process is therefore an iterative one with information being fed back from later stages to earlier parts of the process. The iterative testing process is illustrated in Figure 1.2 and described below: Unit Testing: Unit testing is code-oriented testing. Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. Module Testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures functions. A module encapsulates related components so it can be tested without other system modules. Sub-system (Integration) Testing: This phase involves testing collections of modules, which have been integrated into sub-systems. It is a design-oriented testing is also known as integration testing. Sub-systems may be independently designed implemented. The most common problems, which arise in large Software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces. System Testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems system components. It is also concerned with validating that the system meets its functional non-functional requirements. Acceptance Testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors omissions in the systems requirements definition (user-oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. 1.8 The V-model of Testing To test an entire software system, tests on different levels are performed. The V model [FEW99], shown in figure 1.3, illustrates the hierarchy of tests usually performed in software development projects. The left part of the V represents the documentation of an application, which are the Requirement specification, the Functional specification, System design, the Unit design. Code is written to fulfill the requirements in these specifications, as illustrated in the bottom of the V. The right part of the V represents the test activities that are performed during development to ensure that an application corresponding to its requirements. Unit tests are used to test that all functions and methods in a module are working as intended. When the modules have been tested, they are combined and integration tests are used to test that they work together as a group. The unit- and integration test complement the system test. System testing is done on a complete system to validate that it corresponds to the system specification. A system test includes checking if all functional and all non-functional requirements have been met. Unit, integration and system tests are developer focused, while acceptance tests are customer focused. Acceptance testing checks that the system contains the functionality requested by the customer, in the Requirement specification. Customers are usually responsible for the acceptance tests since they are the only persons qualified to make the judgment of approval. The purpose of the acceptance tests is that after they are preformed, the customer knows which parts of the Requirement specification the system satisfies. 1.9 The Testing Techniques To perform these types of testing, there are three widely used testing techniques. The above said testing types are performed based on the following testing techniques: Black-Box testing technique Black box testing (Figure 1.4) is concerned only with testing the specification. It cannot guarantee that the complete specification has been implemented. Thus black box testing is testing against the specification and will discover faultsofomission, indicating that part of the specification has not been fulfilled. It is used for testing based solely on analysis of requirements (specification, user documentation). In Black box testing, test cases are designed using only the functional specification of the software i.e without any knowledge of the internal structure of the software. For this reason, black-box testing is also known as functional testing. Black box tests are performed to assess how well a program meets its requirements, looking for missing or incorrect functionality. Functional testing typically exercise code with valid or nearly valid input for which the expected output is known. This includes concepts such as boundary values. Performance tests evaluate response time, memory usage, throughput, device utilization, and execution time. Stress tests push the system to or beyond its specified limits to evaluate its robustness and error handling capabilities. Reliability tests monitor system response to represent user input, counting failures over time to measure or certify reliability. Black box Testing refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and does not make use of source code testing of any kind. In the security paradigm, malicious input can be supplied to the program in an effort to cause it to break. If the program breaks during a particular test, then a security problem may have been discovered. Black box testing is possible even without access to binary code. That is, a program can be tested remotely over a network. All that is required is a program running somewhere that is accepting input. If the tester can supply input that the program consumes (and can observe the effect of the test), then black box testing is possible. This is one reason that real attackers often resort to black box techniques. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches. Black box testing tries to find errors in the following categories: Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors, and Initialization and termination errors. By applying black box approaches we produce a set of test cases that fulfill requirements: Test cases that reduce the number of test cases to achieve reasonable testing Test cases that tell us something about the presence or absence of classes of errors. The methodologies used for black box testing have been discussed below: 1.9.1.1 Equivalent Partitioning Equivalence partitioning is a black box testing approach that splits the input domain of a program into classes of data from which test cases can be produced. An ideal test case uncovers a class of errors that may otherwise before the error is detected. Equivalence partitioning tries to outline a test case that identifies classes of errors. Test case design for equivalent partitioning is founded on an evaluation of equivalence classes for an input condition [BEI95]. An equivalence class depicts a set of valid or invalid states for the input condition. Equivalence classes can be defined based on the following [PRE01]: If an input condition specifies a range, one valid and two invalid equivalence classes are defined. If an input condition needs a specific value, one valid and two invalid equivalence classes are defined. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined. If an input condition is Boolean, one valid and invalid class is outlined. 1.9.1.2 Boundary Value Analysis A great many errors happen at the boundaries of the input domain and for this reason boundary value analysis was developed. Boundary value analysis is test case design approach that complements equivalence partitioning. BVA produces test cases from the output domain also [MYE79]. Guidelines for BVA are close to those for equivalence partitioning [PRE01]: If an input condition specifies a range bounded by values a and b, test cases should be produced with values a and b, just above and just below a and b, respectively. If an input condition specifies various values, test cases should be produced to exercise the minimum and maximum numbers. Apply guidelines above to output conditions. If internal program data structures have prescribed boundaries, produce test cases to exercise that data structure at its boundary. White-Box testing technique White box testing (Figure 1.5) is testing against the implementation as it is based on analysis of internal logic (design, code etc.) and will discover faultsofcommission, indicating that part of the implementation is faulty. Designing white-box test cases requires thorough knowledge of the internal structure of software, and therefore the white-box testing is also called the structural testing. White box testing is performed to reveal problems with the internal structure of a program. A common goal of white-box testing is to ensure a test case exercises every path through a program. A fundamental strength that all white box testing strategies share is that the entire software implementation is taken into account during testing, which facilitates error detection even when the software specification is vague or incomplete. The effectiveness or thoroughness of white-box testing is commonly expressed in terms of test or code coverage metrics, which measure the fraction of code exercised by test cases. White box Testing involves analyzing and understanding source code. Sometimes only binary code is available, but if you decompile a binary to get source code and then study the code, this can be considered a kind of white box testing as well. White box testing is typically very effective in finding programming errors and implementation errors in software. In some cases this activity amounts to pattern matching and can even be automated with a static analyzer. White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that: Guarantee that all independent paths in a module have been exercised at least once Exercise all logical decisions Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity. There are several methodologies used for white box testing. We discuss some important ones below. 1.9.2.1 Statement Coverage The statement coverage methodology aims to design test cases so as to force the executions of every statement in a program at least once. The principal idea governing the statement coverage methodology is that unless a statement is executed, we have way of determining if an error existed in that statement. In other words, the statement coverage criterion [RAP85] is based on the observation that an error existing in one part of a program cannot be discovered if the part of the program containing the error and generating the failure is not executed. However, executed a statement once and that too for just one input value and observing that it behaves properly for that input value is no guarantee that it will behave correctly for all inputs. 1.9.2.2 Branch Coverage In branch coverage testing, test cases are designed such that the different branch conditions are given true and false values in turn. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing criterion than the statement coverage testing [RAP85]. 1.9.2.3 Path Coverage The path coverage based testing strategy requires designing test cases such that all linearly independents paths in the program are executed at least once. A linearly independent path is defined in terms of the control flow graph (CFG) of the program. 1.9.2.4 Loop testing Loops are very important constructs for generally all the algorithms. Loop testing is a white box testing technique. It focuses exclusively on the validity of loop constructs. Simple loop, concatenated loop, nested loop, and unstructured loop are four different types of loops [BEI90] as shown in figure 1.6. Simple Loop: The following set of tests should be applied to simple loop where n is the maximum number of allowable passes thru the loop: Skip the loop entirely. Only one pass thru the loop. Two passes thru the loop. M passes thru the loop where m N-1, n, n+1 passes thru the loop. Nested Loop: Beizer [BEI90] approach to the nested loop Start at the innermost loop. Set all other loops to minimum value. Conduct the simple loop test for the innermost loop while holding the outer loops at their minimum iteration parameter value. Work outward, conducting tests for next loop, but keeping all other outer loops at minimum values and other nested loops to typical values. Continue until all loops have been tested. Concatenated loops: These can be tested using the approach of simple loops if each loop is independent of other. However, if the loop counter of loop 1 is used as the initial value for loop 2 then approach of nested loop is to be used. Unstructured loop: This class of loops should be redesigned to reflect the use of the structured programming constructs. 1.9.2.5 McCabes Cyclomatic Complexity The McCabes Cyclomatic Complexity [MCC76] of a program defines the number of independent paths in a program. Given a control flow Graph G of a program, the McCabes Cyclomatic Complexity V(G) can be computed as: V(G)=E-N+2 Where E is the number of edges in the control flow graph and N is the number of nodes of the control flow graph. The cyclomatic complexity value of a program defines the number of independent paths in the basis set of the program and provides a lower bound for the number of test cases that must be conducted to ensure that all statements have been executed at least once. Knowing the number of test cases required does not make it easy to derive the test cases, it only gives an indication of the minimum number of test cases required. The following is the sequences of steps that need to be undertaken for deriving the path coverage based test case of a program. Draw the CFG. Calculate Cyclomatic Complexity V(G). Calculate the basis set of linearly independent paths. Prepare a test case that will force execution of each path in the basis set. 1.9.2.6 Data Flow based Testing The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program. Various data flow testing approaches have been examined [FRA88] [NTA88] [FRA93]. For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables. For a statement with S as its statement number, DEF(S) = {X| statement S contains a definition of X} USE(S) = {X| statement S contains a use of X} If statement S is if or loop statement, its DEF set is left empty and its USE set is founded on the condition of statement S. The definition of a variable X at statement S is live at statement S, if there exists a path from statement S to S which does not contain any condition of X. A definition-use chain (or DU chain) of variable X is of the type [X,S,S] where S and S are statement numbers, X is in DEF(S), USE(S), and the definition of X in statement S is live at statement S. One basic data flow testing strategy is that each DU chain be covered at least once. Data flow testing strategies are helpful for choosing test paths of a program including nested if and loop statements 1.9.3 Grey-Box testing technique Grey box testing [BIN99] designs test cases using both responsibility-based (black box) and implementation-based (white box) approaches. To completely test a web application one needs to combine the two approaches, White-box and Black-box testing. It is used for testing of Web based applications. The Gray-box testing approach takes into account all components ma