One of his friends had tried his website as input in Web Page Analyzer and the result had many warnings, etc for the site. So he wanted to make sure everything was ok.

I tried the same and I got the following results:

TOTAL_SIZE – Warning! The total size of this page is 459078 bytes, which will load in 94.09 seconds on a 56Kbps modem. Consider reducing total page size to less than 100K to achieve sub 20 second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback.

IMAGES_SIZE – Warning! The total size of your images is 149086 bytes, which is over 100K. Consider switch graphic formats to achive smaller file sizes (from JPEG to PNG for example). Finally, substitute CSS techniques for graphics techniques to create colored borders, backgrounds, and spacing.

MULTIM_SIZE – Warning! The total size of your external multimedia is 298365 bytes, which is over 30K. Consider optimizing your multimedia files for size, or replacing them with lower-bandwidth alternatives, or eliminating them altogether.

From the three issues identified above, we could notice a real issue – the first one – ie. the file contents were not compressed.
The other two issues are just the fact that the site requires large images and multimedia files.

I realized one thing – sites like this one is quite useful as they can be verified by the QA team – by adding it to the QA Testing Checklist at Auro Infotech and verifying each item identified. The idea is that the site should have been developed with all the key points in mind to have it optimized for speed, search engines, coding standards, design standards, etc. This site, similar to the W3C validator, can be added to our QA Testing Checklist to make sure we check the site before we give to our clients.

Have you seen something similar? Please do let us know.

STLC at AI begins right from the Requirement Analysis phase. The Test Lead analyzes the requirements for a project from the client.

Next, test cases are prepared with the help of test management tool called “Test Link”.

TestLink helps us to easily create and manage Test cases as well as organize them into Test plans.

These Test plans allow team members to execute Test cases and track test results dynamically, generate reports, trace software requirements, prioritize and assign tasks.

Once the design is completed, it is tested to match with the client requirement and then signed off to begin the coding.

After coding the entire application is tested with the test plan.

Errors are reported into “Mantis” which automatically sends the bug report via email to the Project Lead/Developer.

Mantis is a web based bug tracking tool which is integrated with Test Link where the bugs can be managed.

The bugs are included into the relevant test cases and striked off once fixed/resloved and the status of the test case is changed to “pass”.

By this way AI is able to easily manage the complete cycle in testing an application.

Though it is called as a single checklist, there are ten sub categories of items, each one with its own checklist it is logically grouped into Level 1, 2 and 3, based on the practical implementation phase of the QA testing.

Level 1 QA Checking

This contains all the items that are checked when the application is first submitted for QA. They are:

1. Version control
2. Design Standards
3. Functionality Testing
4. Integration Testing
5. SEO
6. Y-Slow
7. Coding Standards

Level 2 QA Checking

This level contains all the elements that are checked in parallel with the User Acceptance Testing.

1. Cross-Browser Testing.

Level 3 QA Checking

This contains the QA related items that can be done in isolation.

1. Load Testing
2. Security Testing

Every application in Auro Infotech goes through this rigorous QA testing process before it is released. We hope this will help any web based application to be quite robust once it goes through this levle of testing.

Please let us know if you are aware of any other testing procedures that might be useful for a web based application that we are not following at Auro Infotech.

The idea of any website is to provide relevant and meaningful data to the visitors. Google and other search engines are constantly searching for such websites to be displayed in its search results whenever visitors to google look for keywords related to this website.

Though SEO is a series of steps meant to optimize a webpage/website in order to facilitate the searching and indexing of the site by the search engines, the commercialization of SEO has made it into a business of its own, and is not considered by many as a integral part of any web site development.

At Auro Infotech, we have made SEO as a part of our core set of tasks to be delivered on every project. The following are some of the basic SEO related items developed by our developers and checked by the QA team:
1. Tags, keywords, description, etc in place in each page
2. Headings and sub headings given
3. Keyword density on the page is measured right
4. Javascripts in external files if possible
5. Unique Page titles on each page on the site
6. All www links are redirected using 301 redirect to avoid www

Did we miss anything out? Let us know what you think.

QA Testing Process is embedded closely into our Auro Project Development Life Cycle model and hence is dependent on a few important parameters.

Baseline Parameters:

During the discussion process with any client for a new website development (or enhancement) we ask our clients some important questions related to QA testing of their website.

1. Which Operating Systems would you like your site to be tested on?

2. browsers would you like the site to be tested on?

3. Which versions of browsers would you like the site to be tested on?

4. Which display resolutions would you like the site to be tested on?

We facilitate this question with a simple spreadsheet (will post a copy of it here shortly).

For a typical website, the recommendation from Auro Infotech is something like:

1. Operating Systems: Windows and Mac

2. Browsers: Internet Explorer, FireFox, Safari, Chrome

3. Versions: IE 6, IE 7, FF2, FF3

4. Resolutions: 1024 by 768, 1200 by 800, 1600 by 1200.

In the past we have seen clients ask us to test on some things outside the above recommended list (eg. Mobile devices, 800 by 600, etc).

This baselining helps us to start the project with a clear understanding of the client expectations and helps us to plan the development better.

Version Numbers:

Every project has a major and minor version number using which each project is labeled.

We use the following format: Project Name v <Major Version Number> . <Minor Version Number>

Examples are given below:

- Weavez v1.0 (We typically use 1.0 if this is a brand new website we are developing).

- Floretz v2.0 (We typically use 2.0 if we get a website that is already built by some other team and we are taking it over)

- Flair Tours v1.1 (If a client asks for a minor change to be done to a website, we increase only the minor version and not the major version.)

- Music Plugin v2.5 (If it is a change that is not minor but not large enough to be called major, we just create a version .5 from the current version).

The team at Auro Infotech gets a better idea of the type of changes going on in any project from the minor version number.

QA Testing Cycle:

Our development team typically develops the applications and does their part of testing (called developer testing) on one standard browser (typically the one that the client uses personally).

Once the development task is completed our QA Testing Cycle begins.

The Auro QA Testing Cycle is documented below:

1. The Project Leader initiates the QA Testing Cycle by requesting the QA team to test the website. This initiation is done by providing the requirements document, static screenshots and the link to the website on our testing server.

2. The QA team assigns a QA Lead for each website, responsible for the quality of the website.

3. The QA Lead studies the documents, screenshots and works with the testing website links. After this, the QA Lead plans for a meeting with the Project Team to get a demo of the website and get a full understanding of the system.

4. At this point the QA Lead prepares the QA Testing Specifications Document and gets it approved by the Project Leader.

5. The QA Lead tests the application and presents the results of the testing in Test Results Document to the Project Team.  This round of testing is called Build 1.

6. The Project Lead decides whether to accept a finding or reject it. The web development project team fixes the findings that are accepted and all findings rejected by the Project Lead are sent to the Project Manager for approval.  The Project Manager decides whether the rejected findings can be ignored, as they are accountable to the client on the quality of the final product.

7. Once the issues are fixed, the web development project team promotes the changes to testing server and submits Build 2 for QA testing.

8. This cycle continues until the QA team has signed off on all the test specifications (except the findings rejected by the PL and approved by the PM).

9. Once the QA team signs off the website on one browser, it is submitted to the client saying it is ready for User Acceptance Testing (UAT). At this point, the QA team continues to test the website on other browsers. This helps us to save time during the parallel testing.

10. Once the QA team signs off on the entire website, the website is officially ‘Out of QA’ and ‘into full UAT’.

This completes the QA Testing Process Cycle as defined at Auro Infotech.

The idea is that Auro Infotech’s contribution is to give all the saturdays in the month to be spent towards learning a new product each month. This 32 hours of contribution from Auro Infotech (four days) should be added to one or two hours every day in the month (26 or 27 days) to generate around 60 hours of learning time, so that the employee can fully learn the concepts and details of any one product each month.

Please note that the success or failure of this Monthly Technology Project fully depends on your commitment and involvement during the month.

Every Saturday, the plan should be to start the day early and end the day by 6pm IST.

Each team member should do the following:

Week 0: Preparation
1. Pick one technology that has not been picked by any other person.
2. Talk to your mentor about the technology and get the approval for the same.

Week 1: Analysis

1. Study about the technology of choice.

2. Pick five products within that technology.
3. Prepare a write up on the full list of features available in the five products
4. Identify one product on which a Proof of Concept (POC) will be developed. These POCs should be relevant to our projects.

Week 2: Requirements and Design
1. Prepare a set of requirements, project plan and screenshots of the Proof of Concept (POC).
2. Prepare a database design and all relevant information necessary for approval
3. Coding can be started if you have a very good understanding of the product and the end result.

Week 3: Coding and Testing
1. Complete coding on the Proof of Concept
2. Perform thorough testing of the POC and submit it for User Acceptance Testing
3. The support team will move the code from your testing servers, to a live server at the end of this week and after that you will not have access to do any changes to the code after this. So please do a thorough testing of the POC before you submit it for promotion to the live server.

I will be the guide/counsellor/mentor for all these POCs for now until some of our leaders mature into mentors. For now, I will also be the final user of the product so I will be signing off on the POC before the start of week 4.

Week 4: Presentation and Winner Selection
1. Each person will present their Proof of Concept to the team for 30 minutes using slideshows followed by a demo.
2. Every team member should vote anonymously for the Proof of Concept on various factors such as:
a. Presentation – how well was the team member able to present the POC with relevance to the product.
b. Simplicity – how simple is the POC to use
c. Feature Set – is the POC developed rich in features?
d. Adoptability – Do I feel I can use the sample POC provided and build on it?

Points, Voting, Winner Selection:
1. Monthly Winner Selection:
Each month three winners will be selected based on four inputs:
a. Popularity Votes (33%): This is decided by the team that participates in the votes on the presentation Day.
b. Mentor Votes (33%): This is decided by the mentors who work closely with the team members during the month.
c. Judges Votes (33%): This is decided by the judges who attend the presentations on the presentation day.

In case of a tie in the popularity, mentor and judges votes, the administrator will decide the winners from among the team members who are tied for any given position.

Each month, three winners will be chosen and given a cash award of Rs.5000, Rs.3000 and Rs.2000 respectively.

2. Points and Grand Prize:
Each month, the team members collect points from three four sources:
a. Popularity Points: The votes cast by the team members on presentation day are added to the points obtained by the team members.
b. Mentor Points: Team members collect upto five points from their mentors based on their delivery each week (Week 1, 2, 3 and 4 deliverables). These points are decided by the mentors for high quality and timeliness on each deliverable.
c. Judges Points: The judges will rank the presenters from 1 to n (where n is the number of presenters). If your rank is m in a given month, you get n-m+1 points from the judges for the given month.

A simple formula based sheet will be presented with a easy way to track these points.

At the end of the calendar year, the top three winners with the most points will be given a cash award of Rs.50,000, Rs.30,000 and Rs.20,000 respectively.

Note:
1. Working in teams is not an option. Each team member has to learn by themselves.
2. If there is an extra week in the month, please plan to study more about the technology you have chosen for the month.
3. If there are only three working saturdays in a month, please plan your projects accordingly.
4. If you have pending client work from the week, you have to manage your time to accommodate the Monthly Technology Projects and your pending client work. No excuses will be accepted on failing on either one of them.
5. This Monthly Technology Project is open for all employees.
6. It is advised that you do not cast your vote to yourself. If you still insist doing it, you are free to do so.
7. If a technology was picked by a team member, but not presented, it can be picked by any other team member in the future, except the same person who missed presenting it.

We are allocating a budget of 2.2 Lakh Rupees for this exercise for 2009.

Please find below the plan for Presentation Day. All timings are in IST.

Overview:
On the Presentation day, all employees will have to attend the office in person in Chennai, and remotely from 9am to 6pm IST.
The presentation sessions will start at 9 am and end at 5pm

Voting Process:
The voting will start at the end of the day. It will be through an anonymous polling system, where except the admin no one will know who you voted for. Every employee will login to the voting system (details will be announced shortly) and cast their vote to their favorite POC.

Session Details:
Each member will have 30 minutes during their session.
10 minutes of Slideshow Presentation
15 minutes for Online Demo
5 minutes for Q&A and Judges Feedback

Timings:
10am to 11.30am: 3 sessions
11.30 to 11.45: break
11.45 to 1.00: 3 sessions

1.00 to 1.45: lunch

1.45 to 3.15: 3 sessions
3.15 to 3.30: break
3.30 to 5.00: 3 sessions

5.00 to 5.15: Overall Judges Feedback
5.15 to 5.30: Polls open for a)Team Members. b) Judges
5.45: Results of winners announced

Exceptions:
Any one who cannot attend office on Presentation Day must obtain permission from the administrator ahead of time. Your participation in this initiative will be expected to be 100% as this is a training exercise for the team and is beneficial to the team only based on 100% participation.