SQA Methodologies
This section is specific to testing methodologies. For methodology related to the software development life cycle and the overall quality assurance picture, see the SQA Industry Standards tab. There are many books on software testing, so we are not going to repeat that information here, but we will explain some basic principles of SQA, as it relates to software testing, to keep you out of trouble and provide you with some samples for you to use in your project. For samples and templates go to the SQA Documentation Samples and Templates tab.
Know and understand the current software development life cycle or product development process being used by your organizations before initiating any changes. Then research new processes located at the SQA Industry Standards tab. These standards should be used as guidelines during your software testing activities. Remember that software testing is only one phase of the entire software quality assurance process. Software quality assurance should be practiced by the entire company, not just the SQA or the software testing group. For a sample of "SQA Methodologies and Testing" processes go to the SQA Documentation Samples and Templates tab.
Before you start a project you should understand the underlying architecture of the product and the production environment that is being targeted. Understanding the system architecture and related technology will allow you to write better defects and therefore save development time. Then work to duplicate this production environment into to your test box, as much as you can. You may not be able to entirely duplicate the production environment, because the cost may be expensive, but try your best. In some cases the test box may be underpowered, so it will be important to test in a live production environment before release, if possible. The most important thing is to make sure that the SQA Team has its own testing box, separate from development and the staging area, otherwise changes will occur often and make it difficult to trace problems to its source.
If you want a successful project and ensure quality, make sure that you have the proper project documentation in place: Project Plan and Schedule, Customer or Product Requirements, System and/or Functional Specification, Data Base Model if backend testing is required, Website blueprint if testing a website, Development Design Specification, User Documentation, etc. These documents are the basics and more may be generated. Get the documents as early as you can, so that you can start writing test documentation. Also make sure that you are part of review team that is reviewing this documentation and report problems as soon as possible. It is cheaper to correct problems on paper, then it is if the product has already reached the coding phase. If you are following the Extreme Programming process, then the process is entirely different and you must learn to adapt and follow the new process. And the most important thing is make sure that the SQA Team is involved in the project from the beginning to end of the project, including but not limited to the design walkthrough. You may not understand it all, but the more information you have early on, the better you will prepare yourself for testing the product.
The SQA Project Leader Guide was written to assist SQA Project Leaders to manage a project from an SQA perspective. For a sample of "SQA Project Leader Guide" go to the SQA Documentation Samples and Templates tab.
The Test Plan or Quality Plan is a high level strategic SQA document that describes the overall test strategy of the project. Make sure the SQA Team reviews it before publishing it outside of your group. For a sample of a "Test or Quality Plan" go to the SQA Documentation Samples and Templates tab.
The underlying parts of the test environment should be built as soon as it is defined by the engineering architect and should be tested with a dummy application, while the SQA Team is waiting for the actual product or pieces of the product to be delivered to the team. This will shake out any bugs related to the foundation of the product. As soon as it is completed, smoke test it for completeness. Also, as stated previously, make it as close to production as possible and make sure that the test environment is separate from development. You should actually have 3 areas for the product to progress into: Development, Test and Stage, before going into the Production environment.
If you are doing any kind of database testing you will need to know the data model or the definition of tables and items contained in the database for the product. Request this from your Data Base Administrator.
Site Architecture/Page Schematics
If you are testing a website, get a schematic or site diagram of what the flow is suppose to look like or how customers are suppose to navigate through the site. Also get a tool in SQA to check for broken links on the site, especially when major changes are implemented.
Configuration Testing (OS, Browsers, speeds)
In the internet world configuration testing is a must. Web pages behave differently across browsers, operating systems, screen size and Internet access. The main browsers are Internet Explorer and Netscape. Try at least 2 versions of each. Operating systems: NT, 98 2nd Edition, ME, Windows 2000, Linux and Mac. Get a configuration SQA lab setup in your group and included tools. Setting up a lab with a switch box connecting to one monitor and many computers will work just fine and it is not expensive.
Forms data validation is very important across various browsers and versions. Also do some error checking and ensure that users are entering the correct information.
Don't start your entire testing effort, until a smoke test is conducted first, to make sure that the build received is the correct one and completed with all the latest functionality. If you can, get a listing of the new contents, functionality or fixes.
If your development team is not doing design/code reviews and unit testing your project could be in jeopardy. Arrange to verify the fact that this process is being implemented by your development group.
If you are building the product in incremental pieces or parts it may be necessary to do create an Integration Plan that will layout the incremental parts, so that you know what you are testing as the product evolves and is integrated to create a fully functional product over time.
Test Cases are the most important documents for the SQA project and the most time consuming for creating them. Be sure the keep them updated, so that they remain useful for future projects, if required. And review them before publishing to other groups in your organization. Also use some form of document numbering system, so these documents can easily be identified and retrieved when required. Mercury Interactive's Test Director is probably the best tool for organizing manual test cases and automated test scripts. The actual method of creating test cases is best described by Glenford Myers, in his book "The Art of Software Testing". In his book he talks about boundary value analysis, equivalence partitioning, logic-coverage and cause-effect graphing. Reading the functional specification and just cranking out those test cases is not enough. There should be some method for creating them. CaliberRBT by Starbase (go to Product tab) and RT/TT by Software Prototype Technologies are the best 2 integrated products that automate the process of creating test cases, using cause and effect logic diagramming with Visio software. These products also allow you to do requirements analysis. A sample of test cases is available at the SQA Documentation Samples and Templates tab.
When executing your test cases, be aware that 100% of test cases written will be executed at the completion of the final code delivery. So in the beginning do not expect to execute all your test cases. Test the product as early as you can, test it often and always remain focused on what your are testing on the current build. When doing regression testing, you may not always have time to execute all test cases again, so always test the core functional parts first, then new functionally and then any bug fixes. The core functional test will ensure that previous functionality was not broken due to new functionality and bug fixes. Testing is an iterative continuos process, so be selective and strategic in your planning.
Writing good defect reports is critical to the entire software testing effort. These reports must be written concisely and have enough detail, so that the developer can understand the problem and duplicate it. Writing good defect reports requires product knowledge, an understanding of the underlying architecture and the tools used to develop the product.
At the completion of the testing project, a Quality Assurance Report should be written. This report is your stamp of approval and communicates to the rest of team that the product is either ready or not ready to be shipped. The report consists of a short summary of the project and current outstanding problems. . The last published defect report is also included and any release notes. A sample of this report is in the "QA Project Leaders Guide". Go to the SQA Documentation Samples and Templates tab.
Always conduct a postmortem at the end of your project and the product is in production. This time is an opportunity to improve quality processes in your organization. A company should always strive for constantly updating and improving internal company processes. If you would like us to send you information on how to conduct a postmortem go to the SQA Documentation Samples and Templates tab.
Performance or load testing is detrimental to the successful launch of a website into production. Many Internet companies have suffered the consequences of not performing this task. Testing concurrency and determining the maximum load on your server and/or application is critical. There are many other performance issues to be considered. For a sample of "Performance Testing" documentation go to the SQA Documentation Samples and Templates tab.
Automation, if implemented correctly and consistently, is a very important aspect of the entire testing phase of the software development life cycle. Automation needs to be strategically planned, so that the tools for automation can be used as early as possible in the project. When planning automation think about whether writing the code for automating the testing task is shorter, than doing it manually or repeatedly over time. Try to have a separate team for automation, because automation is a lot like development and should adhere to the same coding standards and practices. For a sample of the "Automation Plan" documentation go to the SQA Documentation Samples and Templates tab.
Configuration Control/Release Management
Configuration Control or Release Management is another very important task in the software product development life cycle. Standards and processes should be written to manage this task during the project. Pick the right tool that your team will use for doing builds, checking in/out code or documentation and getting the final product build into production. A lot can be done to automate the build process and will depend heavily on the talent you hire to manage this task. Release management works in conjunction with the configuration control person to manage each build, create release notes and to make sure the schedule and tasks for the build process are conducted in a professional manner. For a sample of a "Configuration Management Plan" go to the SQA Documentation Samples and Templates tab.
The Change Control Board (CCB) is the focal point for managing changes to the product. They define the next release and what new product or new features will be done and what outstanding defects will be fixed in the next release. It is also the final meeting place to prepare and get the release into production. The players of this board can be made up of many different groups and depends on how your organization currently operates and should consist of the main decision makers of the company.
The Defect Review Committee is different than the CCB. The (DRC) is constantly maintaining and updating the defect data base for current projects, production problems and general maintenance. They develop current reports and statistics for the executive staff and keeps them informed of critical defects in the current project(s) and in production. Current project defects are fixed by the project development team and production problems are fixed by the maintenance group. The players of this review committee can be made up of many different groups and depends on how your organization currently operates and should consist of key members of the company. For a sample of a "Defect Control Process" go to the SQA Documentation Samples and Templates tab.
White box testing consists of testing a product
when a frontend GUI (Graphical User Interface) is not available or some other
form of testing,other than GUI testing is involved, like using SQL to test
the validity of data in the backend database. It could also mean developing
a test harness using Java or automating the testing function by developing
shell scripts in Unix, etc. The point is that white box testing requires a
deeper understanding of technologically and the tools associated with testing
the product.
