|
Testing can make or break an application depending on the importance you give it
September 25, 2006
URL:http://www.drdobbs.com/tools/test-drive-your-software/193005451
What does a developer do when you've been asked to test an application? The straightforward answer is--it depends. Usually, a tester's mind in a non-structured IT environment is crowded with all sorts of questions, including:
Of course, it doesn't have to be this way. Testing plays as important a part--if not greater--than any other stage in the Software Development Life Cycle (SDLC). Testing is the only component which has its own lifecycle that intersects with every stage of the SDLC. They Figure 1 describes how the Software Testing Life Cycle (STLC) relates to the SDLC.
There are any numbes of options that make it tough to decide which testing methodology is best suited for a tester's needs. This is where analyzing industry best practices can help. One good example is the standardized approach we've adapted at Data Inc. after more than a decade of working with Fortune 100 companies. This standardized approach is flexible enough to be customized to meet the needs of any industry, whether part of an overall SDTC or scaled up to work with the entire SDLC.
The planning stage is at the heart of the methodology. This is when project managers address isues such as:
Once issues such as these have been addressed, project managers are in a position to gauge to a certain extent the risk being taken with software. Obviously, greater importance to testing would reduce the risk of poor quality software. Another point to keep in mind is that planning is an ongoing process--it has a starting point, but no defined end. Remember, there is a chance that teams will get things right the first time, so always plan for backups and contingencies. Brainstorming with an organization's team is another good way to flush out potential problems. At this stage, the Test Lead or Software Project Manager may choose to create a formal document stating some of the decisions made. The document is a work-in-progress until the end of the step 2
When the team locks in the high-level and more generic parts of the plan, the next step is to get closer to the project at hand and to find answers to questions such as:
Getting these answers can be time consuming and this is where it pays to have testers with the right "people skills." Test leads and their groups need to reach out to Business Analysts, Development Mangers, Release Managers, and Project Managers to get development timelines, release structures, dependencies and milestones which will eventually help in creating the right testing process. In the end, the team should have a fair idea of the requirements and the effort needed for testing them. Again, it is always advisable to put in a "buffer" or a contingency factor in to the Level of Effort (LOE) calculations.
Another aspect that should be formalized and finalized are the types of testing that will be carried out. Typically, the types of testing, in sequence, would include:
The need for further details on each testing piece is not required since the extent, usage, and form of each type varies from company to company and industry to industry. Then there is also the concept of blackbox, greybox, and whitebox testing which help define how technical the testing is going to be. It's common to have more ground-level testing as development begins and tend become more high level (or scenario specific) as teams move towards the software deployment date. If a team does plan to use specific tools to carry out testing, this is a good time to lay them out and make those critical decisions regarding which tool is the right one for application needs. This process can be shortened as well provided a testing team has the right combination of experiences with various tools. One thing to always remember no matter what is to start small, experiment with the chosen tool, play with a demo license if unsure, before choosing it for the entire project.
Lastly, the team leader needs to work towards creating a Work Breakdown Structure (also referred to as "WBS" or "Testing Project Plan") that maps the resources and the types of testing being done to the release milestones. In this step, project managers need to make sure that the timeline is feasible, ultimately approving, changing or rejecting the timeline depending on their experiences in the past. When finalizing the plan, don't forget to state the potential risks involved. It is the responsibility of the team lead or QA manager to define the testing windows and ensure adequate amount of time is allocated for testing. This may also involve explaining and disseminating information to Senior Management. Make sure that the entire team keeps all thoughts straight and facts handy.
This is also the right stage to formulate what the final testing sign off would constitute and the final sign off dates. Most importantly, all of this should be made available to the entire Project team and approval should be obtained from key players.
Clearly, lots of critical decisions need to be made and the meatier part of the process is coming up. However, before starting the actual testing, project leaders and teams need to ensure that several questions pertaining to set-up have been answered including:
Answers to these questions become exceedingly important if there is (or will be) an offsite or offshore component to a testing team. Lots of managers breeze over this stage, then realize their mistake later when things start to fall apart. So before moving on, managers need to make sure that they have decided and locked in on the test plan template and the bug reporting that works for the project.
Most industry-standard tools provide the flexibility to customize down to the last field. For those who want to go the cheaper route, there is always Microsoft Excel. Another important component is the Reporting templates, which often have two separate versions, depending on the size of the project:
Furthermore, each tester should know exactly whom to reach out to for specific bugs/questions. Project managers and developers should be aware of the testing being carried out. While this might be straightforward, this often becomes a challenge.
One important criterion for success is having the right change control system implemented. Without a proper change control system, a testing team could spend weeks fixing bugs and one last (untested) code change could take it all away and make the project look like a failure.
How does a testing team prevent this? By ensuring each and every "significant" code push in to the Test environment must, at the least, have:
Lastly, the Test Lead should ensure that an appropriate test environment (which mimics the current or proposed production environment as closely as possible) should be provided to the testers. This should also include production like data (which is often obfuscated to protect confidential client information) in case of existing applications or appropriate "dummy" data that would exist in production after the software went live.
In this step a testing team is finally at the stage where they need to put all their prep work to use. A testing team must use their templates and timelines to first prepare all test cases and plans. This should include a review of the test plans for completeness and authenticity. Ensure each test case has, at least a serial number, description, priority, relevant test data and the expected outcome or result. Negative test cases should be marked appropriately. One important consideration to take into account is, if the application will be automated, the team should mark each test case that is considered important and relevant enough to automate. Final plans should be signed off by concerned Dev Managers, Business Analysts and the Team Lead. Some organizations even ask end users to review the test plans and "informally" sign off on them.
Once completed, a testing team will be all set to begin. Refer to the WBS in step 2, use the test plans and execute them within the timelines stated. Delays coming early in the testing project should be appropriately communicated to the team lead over an informal conversation or a formalized report, varying in frequency from company to company. The team lead in turn should communicate to other key players in the project ensuring that testing functions as one integrated unit of the SDLC.
Also, do not forget to create the appropriate metrics along side the testing. Before one knows it, people will start asking for them and will start determining the "health" of the release based on the QA reports.
Several successful test cycles later, the testing manager and team will have managed to sign off on the software and ultimately facilitating successful deployment. Does this mean the mission is complete? Absolutely not! If the software was a success, there will always be additional work including new releases and new deadlines. At this point, the team has definitely come a long way given that all necessary testing related processes have been set in place. However, this will be the true test of expansibility. This is a test of how efficient and comprehensive the test strategy, testing templates and protocols are. The key point to note here is that incorporating flexibility and adaptability in your initial approach goes a long way to ensure that the testing team has minimum rework with every new deployment.
This step has been put at the end, although it could come in earlier depending on the stage the software development is at. Automation of software should only be considered after the code has stabilized and test cases being considered have "almost" entered the maintenance phase. Given that automation in itself is a mammoth task to undertake involving many different aspects, knowing certain key steps listed below can help in making it a successful experience:
Now that you have had a taste of the testing methodology, let's talk a little about the flavors which some key industries present. Note that the information provided here is generic and does not essentially constitute the characteristics of every company's STLC process.
Testing can make or break an application depending on the importance given to it. Just knowing this is not enough though. It is the "undefined" responsibility of every tester and testing manager to constantly work towards improving the testing process and increasing their contribution to the SDLC. Remember, as the software changes, so do the resources testing it. So always build appropriate documentation along the way to streamline the training process. This goes a long way in keeping the testing procedure intact and the software quality consistent.
Tushar is a project lead with DATA Inc.. As an authority in software quality assurance, Tushar has managed on-site and off-shore development and testing teams; developing and implementing methodologies for quality assurance activities across organizations ranging from start-up dot com organizations to Fortune 100 MNCs with product- and project- based delivery models.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.