Learn Software Development » Document

How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer

ashish — Tue, 18 Oct 2011 19:16:37 +0000

If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, that they find using it so easy that they are even willing to pay a premium for such products. What this brings out is the importance of ensuring that you have workflows that appeal to customers, and this means that you need to get your UI designer into the product development process. However, it is not easy to integrate the working of processes with the working style of UI designers. In my experience, getting them to work with the kind of deadlines and schedules that you can impose on engineers and QE can be a difficult task, and this process can interfere with their creative juices.
So, what happens in the case of Scrum ? Well, for Scrum work, we typically say that features should be worked upon when you get close to the Sprint, since that is when the prioritization of features for a Sprint actually happens. However, when the sprint starts, the team starts working on the tasks, which means that the UI for those tasks should be ready. Which automatically means that the UI for tasks should start before the Sprint planning activities (seems a bit strange that some activities for tasks should occur before the Sprint in which the task should be worked on, but there is no other way to get the UI in place).
For this to happen, it is also necessary that there is a parallel planning process underway, whereby the Product Owner has a list of prioritized tasks (already there as part of the Product Backlog); with the difference being that the tasks for the next Sprint should be confirmed during the previous Sprint. In addition, there should be a schedule in place which tracks the work being done by the UI designer, and this planning needs to happen with the Product Backlog, so that it should never happen that the UI designer is getting too many tasks. If this happens, then the UI will not be ready when the team is starting work on the tasks in the Sprint.
So, in the Sprint before a particular Sprint, the Product Owner, one or 2 assigned team members, and the UI designer should be working on a list of tasks for which the UI is required at the start of the subsequent Sprint, and should aim to get a high level workflow document and a UI wireframe in place. Once the actual Sprint starts, the Scrum team will start working with the UI designer to get the final UI based on the User Stories outlined by the Product Owner.

The documents / artifacts created in Scrum

ashish — Tue, 26 Jan 2010 18:56:47 +0000

First, for all those of you are asking what an artifact is. Well, if you consider the Wikipedia definition, “An artifact is one of many kinds of tangible byproduct produced during the development of software.”, it can be used in the current case to refer to the documents that we generate from the Scrum process. The reason I explained what an artifact was, because I had to refer to find the meaning myself, and I would consider that there would be a number of people who would not know what an artifact was. In simple language, it means the documents that one generates from the process, but can also mean other deliverables from the process.
In the case of Scrum, there are 2 main types of artifacts that we generate, one relating to the various documentation, and the other referring to the actual product generated at the end of the Sprint cycle (and for which a demo is given), as well as the final completed process generated from the overall process. The product is assumed to contain all the features that one planned to complete for the current Sprint, with any failures to complete some of these features being evaluated in the Sprint review.

Now, let us consider the various documents that get generated from the entire Scrum process.
Product Backlog: This is the overall prioritized list of features that are being evaluated for getting added to the product. This documents is owned by the Product Owner.
Sprint Backlog: The Sprint Backlog is the listing of features that are to be implemented in the current Sprint cycle, and is created during the Sprint Planning process. The Sprint Backlog is owned by the feature team.
Burndown charts: The Sprint Burndown chart and Release Burndown chart are reports that depict the amount of work required to be completed for the Sprint and Release respectively. They are one of the most important tools to be used for depicting the progress of activities during the progress of the Scrum, and are extremely important in determining whether the schedule of features will be met.

What’s the role of documentation in QA?

ashish — Thu, 12 Feb 2009 03:48:10 +0000

Sometimes, for people who are new to the software line (and specifically new to the testing business), there are questions about how important documentation would be to regular Quality work. After all, the major work is about testing some software and getting the bugs resolved, how important could testing be ? Well, the role of documentation in enabling the success of QA activities is critical. Note that documentation can be in electronic form as well, no necessity that it should be only paper, and in fact, recent trends are more towards having electronic forms that can be placed in source control areas in their specific directory locations.
QA practices should be documented such that they are repeatable, and are not dependent on individual people. Software artifacts and processes such as requirement and design specifications, design documents such as architecture, HLD, LLD, business rules, inspection reports, configuration control design and operational documents, code changes, software test plans, test cases, bug reports and decision making on important bugs, user manuals, etc. should all be documented such that these can be referred later (and prove very useful in case the project personnel are changed or should be transitioned to other teams).
As a part of documentation, there needs to be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used in all cases, else you will find later that it is hard to figure out why something changed and what were the reasons behind it.
One of the most common reasons for failures or overruns / delays in a complex software project is to have poorly documented requirements specifications. Requirement specifications are the details describing an application’s externally-perceived functionality and properties. The condition for requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, ‘user-friendly’ (too subjective). A testable requirement would be something like ‘user needs to enter their date of birth while creating their profile’. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project.
Care should be taken to involve ALL of a project’s significant ‘customers’ and important stakeholders in the requirements process. ‘Customers’ could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren’t met should be included if possible. This also helps in ensuring that changes later are minimized (can never be eliminated).
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as ‘The product shall…..’. ‘Design’ specifications should not be confused with ‘requirements’; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
Test plans need to be documented properly with good change control, since a test plan forms the basis of determining the areas of testing, scope, responsibilities, etc. A test plan forms the first level of generation of confidence in the test strategy for the project.

Details (sub-parts) of a test plan !!

ashish — Tue, 13 Jan 2009 18:11:03 +0000

A software test plan is a document that is critical to any software project. This is the document that is the proper reference to the process that QE follows during the testing process. Having a software test plan is a critical requirement of quality processes, and the document by itself takes some time to prepare (given the importance of the document for the overall process). So let us talk in some more detail of what a test plan should be like:
The software project test plan document describes properties of the testing effort such as the objectives, scope, approach, and focus. One advantage of the process of preparing a test plan is that it provides a useful way to think through the efforts needed to validate the acceptability of a software product, and the consequence of this effort is that such a completed document helps people outside the test group understand the ‘why’ and ‘how’ of product validation. One major need for such a document is that it should be thorough enough to be useful, and succinct enough at the same time so that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers: Which is the software for which this document captures the test process
• Revision history of document including authors, dates, approvals: A document could go through many versions, so this field captures the current version number
• Table of Contents: Very useful, and needed for most documents
• Purpose of document, intended audience
• Objective of testing effort: What should be the goal of the testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.: A test plan by itself is not complete, since a project has different areas covered by different documents
• Relevant standards or legal requirements
• Traceability requirements: Traceability determines how the various requirements are mapped to the different test plans
• Relevant naming conventions and identifier conventions: Very useful for people not involved in the preparation of this test plan
• Overall software project organization and personnel/contact-info/responsibilties: Such a section provides contact details of the key people in the group
• Test organization and personnel/contact-info/responsibilities: The same as above, but covers people in the testing organization
• Assumptions and dependencies: Assumptions can make a lot of difference to the success and failure of a project (and its test plan) and need to be carefully validated
• Project risk analysis: Risk analysis provides a good list of items that could cause risk to the project
• Testing priorities and focus: Any testing process has certain areas of focus (high risk areas, high impact areas, high change areas), and these need to be highlighted
• Scope and limitations of testing: There are some parts of the testing that may not be able to be covered, and this section attempts to cover this part
• Test outline – a breakdown of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Data structures – Outline of data input, equivalence classes, boundary value analysis, error classes
• Details of the Test environment – hardware, operating systems, other required software, data configurations, interfaces to other systems; all these items should be detailed so that anybody picking up the test plan will have enough information
• Test environment validity analysis – differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes: CM stands for Configuration Management
• Test data setup requirements
• Database setup requirements: If the software requires a database, then these instructions will be needed
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation – justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution – tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs: For some cases, people doing the testing may need some special training
• Test site/location: Where will the testing be done. For some specialized equipment, the testing would need to be done at the location where the equipment is based.
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues – These are very important from a legal point of view
• Open issues
• Appendix – glossary, acronyms, etc.
All of these sections, when completed, will provide a test plan that should be the single document that will guide the testing process

Some testing definitions

ashish — Tue, 09 Dec 2008 18:46:19 +0000

Some definitions of key testing terms:

What is software ‘quality’?
Trying to attain software quality implies being able to meet the following goals: reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. It is not easy to objectively define quality. It will depend on who the ‘customer’ is and their overall influence in the scheme of things. if you were to take a holistic view of the customers, you would involve the following people: end-users, customer acceptance testers, customer contract officers, customer management, the development organization’s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of ‘customer’ will have their own slant on ‘quality’ – the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.

What is the ‘software life cycle’?
A software life cycle is one of the most popular terms that a person working in software is expected to know. The life cycle begins when an application is first conceived and ends when it is no longer in use. The various in-between parts of the life cycle is enough to fill a separate book, but as a first level, the terms includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

What is ‘Software Quality Assurance’?
Software QA involves the entire software development paradigm from beginning to end – monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ‘prevention’, to ensuring that such processes are defined that make it more difficult to get into problems.

What is ‘Software Testing’?
When a software is written by developers, it is a given that there will be sections that will not be working properly. Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions, and can cover a wide gamut of activities. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’.