-
Search
-
Recently Written
-
Categories
-
Archives
-
Blogroll
-
Admin
SEO for large, dynamic web sites
One of the websites I have done SEO work for is rather large. We’re talking 300,000+ pages on average. Obviously, it is a highly dynamic website and people have asked me how to manage optimization for these types of sites so here are some key strategies to consider when developing SEO for the larger scale compared to smaller sites:
- Try to ingrain an SEO methodology in the design phase
This sounds pretty obvious but its much easier and affordable in the long run to build the site with SEO in mind first instead of optimizing it later. Think about the common requirements before an ounce of code is written and make sure that everyone involved in the development of the site (managers, developers, content writers) understand the value of SEO and how it should affect their responsibilities. Search engine optimization should be part of everyone’s workflow.
- Prioritizing is a necessity
On large-scale, dynamic websites it usually isn’t feasible to manage SEO in thousand-page chunks. If you’ve started from scratch correctly (see above) then you may already have an SEO-minded organization with a great architecture and lots of quality content in place. Lucky you! Even so, moving forward always requires prioritization. Talk with the decision makers and determine which topics/products/terms are top-tier, second-tier, etc. You may even have to subdivide each tier based on category/region/sub-topic.
This may sound obvious, but I can’t stress the importance of it enough because it sets the foundation for everything that follows. If you are managing the entire project, it gives you and your team that foundation for other SEO work (backlinks, etc) but it also lets you gauge your success a chunk at a time. You will be able to itemize your results to specifically identify what is working and what isn’t and then move on to the other tiers with what you’ve learned.
- Don’t repeat yourself
Highly templated sites with lots of pages run a high risk of being filtered for duplicate content. This will depend on the theme of the site but if we’re talking about hundreds of thousands of pages, most of them may look very similar. To combat duplicate content, make sure your CMS is SEO-friendly or install/build custom tools that will allow you to inject quality content into the best areas of each page. Not all templates are SEO-friendly and even if they are they may not completely meet your needs.
Look at the code: is your important stuff in the important places? If you don’t have access to the code, talk with the designers/developers and try to reach a solution that will work.
If you’re using a home-grown CMS, try some multivariate testing to determine where in your template the SEO content has the best results.
- Be patient
A large website requires a lot of indexing and a lot of time. Just because you’ve got half a million pages deployed, doesn’t mean that they will all show up in Google next week. This is why your SEO workflow must be prioritized; so that you can reliably estimate results based on previous experiences within the same site.
- Sitemaps are a must
The quickest way to get your large website seen by many spiders is to provide a sitemap. I would caution against providing a sitemap to your entire site right off the bat, however. Since your SEO objectives are prioritized, update your sitemap as you reach new chunks/tiers.
- Keep it fresh
We all know that search engines like content that is updated routinely. Keeping content fresh becomes more of a problem the larger a site becomes. If you have a large staff of content writers on hand, then you probably don’t have too much to worry about. Otherwise, it comes back to prioritization. Make sure your top-tier topics get content updates as often as possible.
News feeds, product updates, press releases and relevant interviews are a few great types of content that you can use to keep your primary pages attractive. If you are able to convince management about the value of SEO, then try to get department head(s) to routinely write content or blog about their areas of expertise. Though it will depend on the nature of your site, there are a variety of ways to keep content up-to-date.
- Proceed as you would normally
All the standard SEO rules and principles apply for large sites, too. Develop a strong linking strategy, mask your dynamic page URLs, etc. Above all, focus on the user experience. If all your hard work ends up getting in the way of a usable and friendly website, then noone wins.
Large websites will test your personal and team management skills more than your optimization skills. They may seem daunting and unmanageable at first, but once you prioritize and balance your workload effectively, they’re not too scary. And if you find yourself overwhelmed, just remember to be patient, and know that every page is another revenue source and larger sites have more opportunities for traffic and that means…… well, you know that what means 
Artical Location: http://www.submergedmexican.org/seo-for-large-dynamic-web-sites/
Cost Benefit Model and Financial Analysis in Software Testing
There is no hard and fast rule for calculating cost and benefit analysis of quality assurance. There are some basic rules that every company has to follow but rest of criteria has been defined according to every company’s own circumstances and conditions. The development strategies in every company are influenced by some factors. These factors might be company specific, customer specific or some times the mix of both. These specific factors have strength to draw new measures or decisions even though the economic feasibility has been proven in mathematical form.
Some of these factors can be the good employees that take 100% responsibility of their work and encouraged an environment of testing product from staff. The other factor might be the involvement of client in testing, such as UAT (User Acceptance Testing). Cost benefit analysis also said to give reasonable proof in favour or implementation and benefit of quality assurance. On the other hand these analyses also take cares that the cost that are being spend on quality assurance is properly justified. Testing is one of important measure of quality management systems. Cost benefit analysis also estimates that cost spend on testing can also be justified or not (Golner, 2003).
The cost spend can be determine by three things, the number of errors found, users working on these errors and average effort during each error. The theory of error in cost benefit analysis is little bit different as compared normal concept of error. In cost benefit analysis error is only fault that need effort to fix and effort need money.
The unit of cost spend in testing is PD [Person Day]. One PD is equal to eight hours of work (Normal one day office time worldwide).
Golner (2003), Wieczorek (2001) and Rothermel (2006) all are agreed that If the cost is represented by “C”, the Users working on error is represented by “U”, number of Errors are represented by “ER” and average effort during work per effort is represented by “BM” then following equation can be true;
C = BM * U * ER [PD]
In the above equation we are unknown of the average effort by user on each error (BM). The average effort per user per error can be determined by following equation.
BM = e * p [PD per error and user]
Where;
e = Average effort per error in Person day [PD]
p = Proportion of Users working on error.
The effort caused by data loss during error does not calculated with BM. Because no one would sure about the loss before its happening that’s why this loss is almost impossible to calculate without empirical studies. Effort by user on each error can be calculated through empirical studies. Wiczorek (2006) reported in his studies that it is the time spend on one error by user is between half an hour to half a day. Therefore
0.0625< e< 0.5 [PD per error and user]
In this case the proportion p is only 50% although the users affected with error is 100% but it is possibility that 30% of user might be not present, 10% also not directly involved, they might hear error from someone else and further 10% might got warning from other users and do not able to use error oriented function. Then the result would be
0.03125< BM <0.25
The minimum cost could be (If the error effort is half an hour per error and user)
CMIN = 0.03125 * U * ER [PD]
The maximum cost could be (effort time is half a day per error and user)
CMAX = 0.25 * U * ER [PD]
The average cost can be
CM = 0.14 * U * ER [PD]
Importance of Cost Analysis in Software Testing
Software quality assurance is actually measurement of processes in Software development life cycle and it also measures software through testing during development and after development of software. No doubt it is very recognized and treated as one of pillars for software development. The soul of software development based on four dimensions that are functionality, quality control, deadlines and cost analysis. The scope of any software project is restricted in these dimensions. If the cost of project and deadlines are specified in advance then functionality and quality assurance has to be limited within these boundaries (Goldner, 2001). So both cost and time have great impact on the quality and working of quality assurance.
There are a lot of miss understanding on the cost of quality in software industry. There are two types of opinions. First says that quality of product should achieve its maximum level and in their opinion it is very economical. This ideal is known as “quality is free” in the industry and first time presented by Juran and Gryna (1998). Their point of view at that time was that the cost of defect prevention is increasing and the ratio of rework is decreasing with high speed as compared with increase in defect prevention so the net cost of project is low hence, quality is free. The other group has different opinion. They think that there is no need for high quality levels and quality can be scarified to gain other objectives of project such as in time delivery and project cost. For example a study of implementing Capability Maturity Module from SEI reports a quote of a development manager “I’d rather have it wrong than have it late we can always fix it later” (Pulk et. al. 1994). The experience shows that there are always return of quality expenses (Slaughter et. al. 1998). The quality improvements always results in saving money that over comes the impression of spending money on quality assurance. But quality assurance only able to save cost if the costs spend on quality assurance is properly planned and used and it is big managerial issue. The cost of quality assurance is very important because every hour and every penny used for rework (caused by poor quality) can be used to improve whole process. Slaughter (1998) presents two major divisions of quality assurance cost. First is conformance and other is non-conformance.
Conformance is actually the cost used to achieve proper quality standard. Broadly speaking there are two basic elements to invest in quality improvement. These are prevention and appraisal.
Prevention is actually the cost used to prevent the defects before their occurrence this includes staff training or design methods etc. and appraisal is actually measuring of quality.
Appraisal ensures that software product is achieving to its desired quality by evolution, audit and software testing etc.
The non conformance costs are actually the costs spend for rework. This includes failures, retesting and software failure on customer site.
It is responsibility of management that costs spend on quality assurance must be justified. Many companies are adopting the system for financial evaluation and also considering on software quality investment (Banker, 1997). It is recommended that software quality should be analyzed as investment because it is possible that company spend a huge investment on quality and not able to justify it (Juran et. al. 1998). If conformance and non conformance costs are properly monitored then there is chance that conformance policies will help company to reduce cost spend on quality.
Economics of Quality Assurance
There is always a statement used that is “Quality Assurance is Expensive” - but it is still confusing that comparing the cost of quality assurance with what?
If we compare the cost of Quality Assurance with the cost of the basic development effort then quality assurance may appear expensive. However, this would be a fake picture because the total lifecycle quality is dependent on quality assurance. The more faults are there in the software or processes the longer time will take to correct them and will take time and money to spend on reporting faults and re-testing them.
Asking the cost of quality assurance is actually the wrong idea to do. It is much more interesting to ask the cost of not to implement quality assurance. Software quality assurance is very helpful for indicating and removing or even predicting faults even before their occurrence.
The cost of faults escalates as project progresses from one stage of the development life cycle to the next. A requirement fault found during a review of the requirement specification will cost very little to correct since the only thing that needs changing is the requirement specification document. If a requirement fault is not found until system testing then the cost of fixing it is much higher. The requirement specification will need to be changed together with the functional and design specifications and the source code. After these changes some component and integration testing will need to be repeated and finally some of the system testing. If the requirement fault is not found until the system has been put into real use then the cost is even higher since after being fixed and re-tested the new version of the system will have to be shipped to all the end users affected by it.
Furthermore, faults that are found in the field (i.e. by end-users during real use of the system) will cost the end-users time and effort. It is possibility that the fault makes the users’ work more difficult or perhaps impossible to do. The fault could cause a failure that corrupts the users’ data and takes time and effort to repair.
The longer a specification fault remains undetected and more likely that it will cause other faults because it may encourage false assumptions. In this way faults can be multiplied so the cost of one particular fault can be considerably more than the cost of fixing it.
Normally it is observed that cost of testing is lower than the cost linked with faults because of poor quality or retesting or re fixing faults. A very few companies take record of these figures.
Some of the more spectacular software failures are well known. For example the Ariane 5 rocket of ESA (European Space Agency) exploded 37 seconds into its launch because of a software fault. This fault cost $7billion. Although it had been tested a series of errors meant that out-of-date test data was used. Another example is the Mariner Space probe. This was meant to be going to Venus but lost its way as a result of a software fault. The FORTRAN program had a full stop instead of a comma in a FOR (looping) statement that the compiler accepted as an assignment statement. (Thetechmag, 2003)
Of course not every software fault causes such huge failure costs. The consequences of faults in safety critical systems can be much more serious. The follow examples are all real cases.
Therac-25 (Canada) - this machine was used in the treatment of cancer patients. It had the capability of delivering both x-rays and gamma rays. The normal dose of x-rays is relatively low while gamma ray dosage is much higher. Switching from one type of ray to the other was a slow process but the operators discovered that if they typed fast it could be made to switch more quickly. However, it only appeared to have switched. Six people died as a result of having too high an x-ray dose. This was a design fault. (Vliet, 2003)
Risk Assessment in Software Testing
Even the best developed software product is useless if it can not be used (Horch, 1998). It seems a very basic common sense concept but security and reliability of product is often main concern of organizations. Risks are the thing like hazards or hurdles which come across during the achievement of required level of software reliability and project goals. Specifically risk is the unwanted event of some potential and that if this event occur, it will result in some damage to either functionality, correctness or any thing else (McGregor et. al. 2001). Testing always find problems in software product but the main job of tester is to prioritize these problems. Experienced testers always have idea where the problem is likely to occur so they arrange whole testing process according to that. This fashion of testing is also called risk based testing but clearly saying it is mostly on personal judgement (Amland, 2000). Metrics is very good idea for measuring of software quality quantitatively and is very suitable for risk based testing. Amland (2000) presents a risk model in his recent research and it is very helpful for risk exposure. There are actually two basic concepts of this model. First is volume of faults present in the software. For example if one software component has some fault and it is detected with testing then it is more possibility that again the fault find on this document. It may not be that same fault but any other one. So components with detected faults must be more carefully examine in re-testing and regression testing. As the amount of known faults increases it is more likely that there are other faults exists which is not detected yet (Myers, 1997). Second basic element in risk model is cost of fault. It is common practices that companies deploy software and it contains faults. Although companies choose to build project with the knowledge they known but when the budget got limited and other constraints are also effecting like schedule stress, shipment of project etc. however when companies got limited budget then they prioritize risks to most critical risks and pay most attention on them. Chen et. al. (2002) defines a mathematical to calculate risk exposure that is
RE (f) = P (f) * C (f)
Where;
RE (f) is risk exposure of function f.
P (f) is probability of fault occurrence in function.
C (f) is the cost if a fault is executed in function f.
White Box Software Testing Technique
White box techniques are normally used after an initial set of tests has been derived using black box techniques. They are most often used to measure “coverage” - how much of the structure has been exercised or covered by a set of tests.
Coverage techniques serve two purposes: test measurement and test case design. In common with all structural testing techniques, coverage techniques are best used on areas of software code where more thorough testing is required. Safety critical code, code that is vital to the correct operation of a system, and complex pieces of code are all examples of where structural techniques are particularly worth applying.
There are a lot of structural elements that can be used for coverage. Such as;
· Statement Coverage
· Branch Coverage
Besides statement coverage and branch coverage, there are number of different types of control flow coverage techniques most of which are tool supported. These include branch or decision coverage, LCSAJ (linear code sequence and jump) coverage, condition coverage and condition combination coverage.
Black Box Software Testing Technique
Behavioral techniques can be further subdivided into functional and non-functional techniques. Functional testing techniques are input / output-driven testing techniques. They view the software as a black box with inputs and outputs, but have no knowledge of how it is structured inside the box. In essence, the tester is concentrating on the function of the software, like what it does, not how it does it. Non-functional aspects of a system (also known as ‘quality’ aspects) include performance, usability portability, maintainability, etc. This category of technique is concerned with examining how well the system does something, not what it does or how it does it. There are following different type of black-box testing techniques:
· Equivalence Partitioning;
· Boundary Value Analysis;
· Designing Test Cases
· State Transition Testing; and lot more
The standard also defines how other techniques can be specified. This is important since it means that anyone wishing to conform to the Software Component Testing Standard is not restricted to using the techniques that the standard defines.
1 Equivalence Partitioning
This technique can be applied at any level of testing and is often a good technique to use first. It is a common sense approach to testing. The idea behind the technique is to divide or partition a set of test conditions into groups or sets that can be considered the same or equivalent, hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes, the two terms mean exactly the same thing.
2 Boundary value analysis
Boundary value analysis is based on testing on and around the boundaries between partitions. If you have done “range checking”, you were probably using the boundary value analysis technique, even if you weren’t aware of it. There are both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions).
3 Design Test Cases
The next step is to design the test cases. The more test conditions that can be covered in a single test case, the fewer the test cases that are needed. Generally, each test case for invalid conditions should cover only one condition. This is because programs typically stop processing input as soon as they encounter the first fault. However, if it is known that the software under test is required to process all input regardless of its validity it is sensible to continue as before and design test cases that cover as many invalid conditions in one go as possible. In either case, there should be separate test cases covering valid and invalid conditions.
4 State Transition Testing
State transition testing is used where some aspect of the system can be described in what is called a “finite state machine”. This simply means that the system can be in a (finite) number of different states, and the transitions from one state to another are determined by the rules of the “machine”. This is the model on which the system and the tests are based. Any system where you get a different output for the same input, depending on what has happened before, is a finite state system.
Software Testing Techniques
Software Testing is actually testing every possible combination of inputs and preconditions and demonstrated that it is an impractical goal. Therefore, as we cannot test everything we have to select a subset of all possible tests. In practice the subset we select is a very tiny subset and yet it has to have a high probability of finding most of the faults in a system. The selection of subsets for testing is not easy job and it must not be just random selection. Because the whole credibility of testing is depend upon these selected subsets. These subsets must have four qualities. First is subset should be “effective” such as it mush have potential to find faults, second is subset should be “exemplary” such as it represent other cases of its type. The third is “evolvable” such as it must be easy to maintain, and fourth is “economic”. Different techniques offer different ways of looking at the software under test and off course each technique provides a set of rules or guidelines for the tester to follow in identifying test conditions and test cases. Testing techniques makes testing more effective and more efficient. There are many different types of software testing technique, each with its own strengths and weaknesses. Each individual technique is good at finding particular types of fault and relatively poor at finding other types. These techniques are actually based on an understanding of the system’s behavior also known as “Black Box” (functions and non-functional attributes such as performance or ease of use - what the system does) or its structure also known as “White Box”, how it does it.
Functional Testing
Functional testing gives us the first opportunity to test the system as a whole and is in a sense the final baseline of integration testing in the small. Typically we are looking at end to end functionality from two perspectives. One of these perspectives is based on the functional requirements and is called requirement-based testing. The other perspective is based on the business process and is called business process-based testing. Requirements-based testing uses a specification of the functional requirements for the system as the basis for designing tests. A good way to start is to use the table of contents of the requirement specification as an initial test inventory or list of items to test (or not to test). We should also prioritise the requirements based on risk criteria (if this is not already done in the specification) and use this to prioritise the tests. This will ensure that the all the crucial and important test are included in the system testing effort.
Business domain based testing uses knowledge of the business profiles (or expected business profiles). Business profiles describe the birth to death situations involved in the day to day business use of the system. For example, a personnel and payroll system may have a business profile along the lines of: someone joins company, he or she is paid on a regular basis, and he or she leaves the company. Another business process-based view is given by user profiles. User profiles describe how much time users spend in different parts of the system. For example, consider a simple bank system that has just three functions: account maintenance, account queries and report generation. Users of this system might spend 50% of their time using this system performing account queries, 40% of their time performing account maintenance and 10% of their time generating reports. User profile testing would require that 50% of the testing effort is spent testing account queries, 40% is spent testing account maintenance and 10% is spent testing report generation (Pomeranz, 1998).
Component / Unit Testing
Component testing is actually dividing software in different component or units and then testing them separately. This type of testing also called Unite testing or program testing. With the popularity of object oriented programming the concept of objects based software testing is rapidly increase. Begin recognized as bottom up technique, it is obvious that object oriented programming favor similar testing method (Olan, 2005). In component testing process a component of software code tests and compares with expected results.
Component testing runes as structural testing process because all components are tested separately. Any mismanagement can cause test any components more than once or not at all testing any components etc. Normally the components testing process runes in five stages (Wieczorek et. al. 2001).
1. Test Planning
2. Test Specification
3. Test Execution
4. Test Recording
5. Checking for Components Test Completion
We can not assume how much testing is required for any type of component. Some time little bit testing is enough and some times tester has to test some components more than once. It all depends upon the presence of errors. Normally the criteria is that if more faults are found then more testing is required and if less faults are found then less testing is required. Regardless of testing effort on any component, component testing always began with test planning and always ends with checking for competition. It is clear that all components are tested stand alone. However, there are some issues for integrate these small components and off course this integration also has some sequence (such as top to bottom or bottom to top etc.). There are number of test design and test measurement techniques that can be used for component testing. These include both black box and white box techniques. The quality management standard also allows other test design and test measurement techniques to be defined so you do not have to restrict yourself to the techniques defined by the quality management standard in order to comply with it.
