Connecting Practice

And what are the inputs, guidelines, and outputs to bear in mind in obtaining estimates for testing phase of a software project?

Inputs

• Defined statement of project scope for clear goals and focus work
• Defined user requirements - use cases and functional specs for delivering the required functionality
• Defined technical requirements
• Other supporting documents

Guidelines to create a detailed estimates

• Determine all the effort (lists of tasks the testing work entails) to be performed. This includes getting all the next actions visible.
• Determine complexity of the system.
• Form initial estimate for each task. This includes involving the individuals who will be doing the tasks to figure out how long a task will take based on their experience implementing similar things.
• Assign each task a ‘risk.’ Assign ‘High‘ risk to tasks that you lack knowledge and/or experience; assign ‘Medium‘ risk to tasks that you are familiar with and can complete the tasks; and assign ‘Low‘ risk to tasks that you are confident about and/or have been done many times before.
• Document any other risks that might affect the test work deliverables to address and bring test work in on time.
• Document assumptions made. Note that each task figure should be accompanied by a note on the assumption(s) that you’ve made in coming to this figure and/or interpreting the task requirements.
• Apply adjustments and reserve allowances to account for external factors that the project will depend upon. External factor examples: Tasks that require approval; incomplete component from another project - here document the effect of the dependency if task is not being met; and failure from delivering the required component to a satisfactory standard that cause development delays.
• Include contingency in the estimate. The contingency should be listed separately. If tasks need to use some of the contingency for certain reasons then the Lead should ask the PM for a portion of the contingency. The reasons for needing to use some of the contingency will be discussed and the impact on the test work timelines will be shown in the test plan and shared with the team.

Guidelines to schedule the test work

• Work out how many people will be needed on the team in order to complete the test work in the required time.
• Add test work milestones. Note that every test work task listed in the estimate should become a task in the schedule.
• Assign test work tasks to people who have the skills needed to do the task. There should be some gaps between tasks to represent risk.
• Add dummy tasks to represent known outages, such as: Public holidays, annual leave, training courses, and so on.
• Try to move high risk tasks as near to the beginning of the schedule as possible so that there is as much time as possible to deal with problems.
  Ensure that dependencies between tasks are respected - reorganise the schedule if necessary.
• Keep the schedule up-to-date with latest progress and changes regularly.

Outputs

• A project schedule with allowances for risk, internal dependencies, and known outages
• A list of other assumptions made during the estimation
• A list of the project’s external dependencies
• A list of other risks to the project schedule

Join QAST Practitioner Group, download the attached sample detailed estimate template file in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=60.0

The attached sample detailed estimate template file is meant to be used to create detailed estimates for testing phase (support and regression testing) of a software project.

Beginnings are important in a company that your quality assurance and software testing work is just started. It is then that expectations are formed. These early stages involve:

1. Gaining access to the developers at the outset; and
2. Forming effective relationships with the developers, and maintaining it. This includes developing and concentrating on the most important aspects of your relationship with the developers, such as:

• Rapport - Rapport is that state of interaction where you and the developers are “in tune.” The initial step in building rapport is to give all your attention to the developers.
• Assertiveness - It is when you engage to prove that you can look after yourself to commit, promote, and contribute quality change.

Moreover, in ensuring that you and developers have the sort of relationship that can weather any project issues, use your influencing styles to influence them in any actions and/or events. In this, you may consider any of the guidelines below:

1. Expressing values - Here your values about what is good or bad and important or unimportant features in a project touch a chord in developers and you capture interest. You invoke respect and admiration. You attract developers by strengthening what is good and important project features to achieve results.

2. Getting ready with the undertaking - Here you utilize and review general requirements and supporting documents. You think about what needs to be done, develop ideas, and collaborate with developers for assistance and information. You attract developers by understanding the project facts.

3. Ensuring that quality goals and objectives are clearly understood by developers - Here you provide coordinated plans. By setting plan, you manage situations and channel efforts. You attract developers by providing and bringing direction into their thinking.

4. Creating “pictures” of a desirable results - Here you are able to communicate what needs to be done to create a better results; bring developers to a quality review; expose them to the complexities and potential quality problems, technical issues, concerns, exceptions, assumptions, and/or risks; and give them understanding of what could happen. You attract developers by expressing readiness, practicality, and awareness.

5. Developing schedule - Here you negotiate work loads and time for project planning and estimation. You enable developers to identify needs, evaluate options, formulate action programs, and take initiatives for themselves. You attract developers by collaborating with them for agreement and decision making.

6. Presenting information - Here you collect data, evaluate information, built a logical case, make valid points, and appeal to reason to develop test specifications. You work closely with the developers to review use cases; describe the test cases clearly, concisely, and unambiguously with actual facts; and develop correct and accurate test data. You attract developers by demonstrating logically sound artifacts.

7. Finding defects - Here you identify developer’s defects, supply all the information, and show how these can be fulfilled to get the fix faster. You work at being a useful and helpful resource to them in providing all the information that they need, giving them careful and detailed instructions on how to make it fail in the same way, and/or finding answers to their own defects that concern them to know the cause. You attract developers by reporting defects effectively.

8. Finding issues - Here you identify specific project issues from inception, design, development, product rollout, product updates, and support in daily work. You record, analyze the risk, communicate, and join in the conversation with them. You attract developers by reporting issues effectively.

9. Meeting schedule - Here you deliver quality products. You meet the functional specifications that have been defined and ensure that defects are captured and fixed in the project before reaching our client’s environment. You attract developers by achieving specified quality goals and objectives within specified time and resource constraints.

10. Identifying and recommending improvements to quality process - Here you cause developers to discover that the current quality process is, in some ways, inadequate. You establishing quality standards, templates, checklists, criteria, guidelines, procedures, tools, and metrics in the framework of the quality initiative. This includes giving them quality process training. You attract developers by causing them to re-evaluate their works around them and learn new ways of thinking.

This piece is a quality material file which supports quality guidelines.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=57.0

Given the topic, I feel a need to acknowledge that I have to thank the owner of Here for software Testers!!!!!!!!!!! - All about Testing and Quality blog at for finding this guide materials, a good information in choosing a bug tracking system. The owner’s post (Saturday, January 6, 2007) influences my thinking to share more details about the topic.

A Bug Tracking System is constructed as a database. Usually it is designed to make bug tracking activities easy for project team to manage their specific bugs, generate reports, and assess the product (under test) situation on a build-by-build basis.

Moreover, a bug tracking system is evaluated usually by the manager for its viability and the results is reviewed by project sponsor or management for adoption. What could strike, inspire, and/or interest the management as positive about the bug tracking system are its features. The “what’s in it for us” reality could lead the management to approve or reject it.

Furthermore, the quality manager must identify and understand the requirements of the system needed to solve their certain problems and/or concerns before s/he can start to evaluate the bug tracking systems. Identifying and understanding these requirements will help him/her to build a list of features that s/he can use to guide his/her evaluations.

The following observation questions could help the quality manager to identify his/her bug tracking requirements:

• What are the different roles and responsibilities of the people who will use the system?
• What is your workflow for managing and resolving bugs? Identify the steps in the process,
  and determine who is responsible for each step.
• What information do you need to track for each bug?
• What reports and metrics do you need?
• Do you need to provide different levels of access to different users?

Further, the identified requirements for the system can be translated into a feature list. the feature list is the standard attributes or criteria of the system against which the quality of the bug tracking system to be measured or rated.

Below provides an example of a feature list that could be used to evaluate a bug tracking solution based on the identified requirements to achieve:

• Adaptability
• Change history
• Version control integration
• Customizable fields
• Ease of use
• E-mail notifications
• Reports
• Security
• Web-based client
• Workflow

The A Guide To Evaluating a Bug Tracking System By Stephen Blair, MetaQuest Software. The rest of this document provides tips and guidelines for evaluating these features. Hopefully these guidelines will help the quality manager choose a bug tracking system that meets his/her requirements.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=47.0

The following are some general quality process guidelines:

1. Ensure that the quality process reflects the project sponsor and client’s requirements. The project sponsor and client may mandate that you adopt certain standards and tools. If you do not find them sufficient to achieve the level of quality defined for the project, augment the standards and tools necessary. You may tell your project sponsor and/or client that the resources are not sufficient enough to achieve the level of quality you believe necessary for the project. Do some research for defining the supporting details.
2. If you are using subcontractors or vendors, make sure they understand the quality process and are committed to uphold it. Include reviews of their works. products, services, and/or processes. If the client requires you to certify that subcontractor processes meet certain requirements then record such requirements, and the corresponding reviews in the quality process.
3. Make sure that all team members understand the quality process and know that you expect them to participate in and support it.
4. If the quality process is extensive or complex, you may need to run training programs.
5. Make sure team members understand how their work contributes to achieving the quality process and commit to providing them with feedback about their performance in this area.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=23.0