Thursday, June 07, 2007

Best Practices…


While developing a product one comes across many situations in which a person needs to take decisions which might present all alternatives which seem wrong or all alternatives which seem
correct. In case of such tough decisions, one has to be guided by some best practices which can
help him to solve this problem if not present a readymade solution to the problem.

The best practices can categorized into broad categories:
1) 10 must haves for a Quality Engineer.
2) Four things which any professional or entrepreneur cannot afford to forget.

The best practices of a Quality Engineer ensure that quality of the final product is ensured.

1. Know the technology
In the area of software development, technology is changing rapidly. What is new trend today
may become obsolete tomorrow. In this fast changing world a tester should keep abreast with
the latest in the technology world. A Tester should know what technology is being used for
developing applications. He should know the supporting technology associated with OS. This
will make sure that the tester will find bugs at the early stage, thus reducing the price for the fixing of bugs. Also, studying the technology helps study the competitor better and thus helping your product to have a good standing in the market. Studying the technology would also help the Quality Engineer to understand the workflow and the product better.

2. Learn from past experiences
Before writing the test plan and the test cases, QE should try to scan data from past projects,
which are similar in nature. This may give them some better test cases, issues that were
identified in the end of the cycle, some areas that could be automated. If the application is extension of earlier project, high priority and severity bugs should be regressed for current version of application.

3. Ensure sufficient coverage of feature workflow
The key to success of the testing effort is that when a customer uses the product, he/she
should be able to seamlessly use it. This kind of seamless experience can only be ensured if the
common user workflows have been tested thoroughly. The challenge here is that different users
use different features and in fact might even use the same feature in a different way. Here is
where the role of sufficient coverage comes in.

Coverage can broadly be classified into two categories:
a) Coverage of different functionalities present in the software
The software performs a series of tasks. However the usage of these tasks may vary depending
on the requirement of the customer. Once the possible workflows have been identified, one needs to prioritize the workflows depending upon the number of users who would use the particular feature.

b) Coverage of the different routes while going through the workflow of the software
Common functionalities can be accomplished in many different ways in most software. E.g. in
order to copy a text in Microsoft Word application, one can use the keyboard shortcut Ctrl+C, or
right click on the selected text and select copy. One can also use the edit menu to do the same.
Each of these three routes is important because a user can copy text using any of these. As a
Tester, one needs to find all possible routes of accomplishing a task. After the routes have been
Identified, Quality Engineer needs to see how much probable are these in a real world scenario.
Also study of usage of this feature in comparison to other features needs to be done. As for our
example, we need to know how much common it is for the user to use the ‘copy’ feature in
comparison to other features like ‘find’, ‘replace’, ‘cut’ etc.

4. Make a matrix for hardware to be supported by application (and prioritize the hardware)
Many applications support different configurations of hardware. A proper matrix ensures that application is working on important configuration of hardware.

5. Assign two QEs (primary and secondary)
An application has multiple features. There should be two QE assigned to a feature. The
QE can be assigned as primary QE and secondary QE. Primary QE is responsible for creating
test plan, test cases, setting test environment, executing testing, reporting bug and regression of
bugs. Secondary QE can work as a back up. He can be involved for reviewing test plan and
script, helping primary QE in setting up testing environment, executing some part of test cases at different interval and in regression of bugs. This will help in getting control of bug myopia (blindness to a bug if working for a long time in testing a feature).

....... to be continued

Thursday, May 17, 2007

Software Development Life-cycle

 

Definition: A systematic and orderly approach to solving problems related to software systems.

General problem-solving steps:

 • Planning - identify the scope and boundary of the problem, and plan the development strategy and goals.

    As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.

• Analysis - study and analyze the problems, causes, and effects. Then, identify and analyze the requirements that must be fulfilled by any successful solution.

This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved .

• Design - if necessary, design the solution - not all solutions require design.

In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc... are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

• Implementation - implement the solution.

The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

• Testing - verify the solution works.

Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.

• Support - analyze the implemented solution, refine the design, and implement improvements to the solution. Different support situations can thread back into the previous steps.

The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

Methodology

Definition: An organized, documented set of procedures and guidelines for one or more phases of the software life cycle.

The physical implementation of the logical life cycle that incorporates

  1. step-by-step activities for each phase
  2. individual and group roles to be played in each activity
  3. deliverables and quality standards for each activity
  4. tools and techniques to be used for each activity.

A methodology is “how” the software development life-cycle is executed. There are many ways in which this can be achieved.

The Waterfall Model

The Spiral Model

 

 

Monday, February 05, 2007

Software Test Automation Job Interview Questions

Hi,
Here is a list of probable "Software Test Automation" interview questions.

1. What automating testing tools are you familiar with?
2. How did you use automating testing tools in your job?
3. Describe some problem that you had with automating testing tool.
4. How do you plan test automation?
5. Can test automation improve test effectiveness?
6. What is data - driven automation?
7. What are the main attributes of test automation?
8. Does automation replace manual testing?
9. How will you choose a tool for test automation?
10. How you will evaluate the tool for test automation?
11. What are main benefits of test automation?
12. What could go wrong with test automation?
13. How you will describe testing activities?
14. What testing activities you may want to automate?
15. Describe common problems of test automation.
16. What types of scripting techniques for test automation do you know?
17. What are principles of good testing scripts for automation?
18. What tools are available for support of testing during software development life cycle?
19. Can the activities of test case design be automated?
20. What are the limitations of automating software testing?
21. What skills needed to be a good software test automator?
22. How to find that tools work well with your existing system?
23. Describe some problem that you had with automating testing tool.
24. What are the main attributes of test automation?
25. What testing activities you may want to automate in a project?
26. What are some of the common misconceptions during implementation of an automated testing tools for the first time?

Monday, January 22, 2007

What is a Web Service?

The W3C defines a Web Service as a software system designed to support interoperable machine to machine interaction over a network. Web services are frequently just API's that can be accessed over a network, and executed on a remote system hosting the requested services.

Among the many ways devised to enable humans to use software running on distant computers, HTML transported over HTTP and presented via a web browser is surely the most successful yet. By using this relatively simple, accessible message format, applications can be used by people all over the world without installing custom client software on their computers.

What about when you want to connect one system to another that is running on a distant computer? Lots of approaches to distributed computing have been tried over the years, and many of these are still in use. But none has achieved the same degree of explosive growth and re-use as we have seen with HTML for web UI. The term "web services" encompasses applications that employ a specific combination of technologies to make themselves accessible to other systems running on remote machines. The most significant web services technologies address three questions:

  • How do I find web services that I want to use?
  • Once I find a service, how do I learn how it works?
  • How do I format messages to a web service?

Finding a Web Service:

In the simplest case, you could learn about a web service in the normal course of communicating with your friends, co-workers and business partners. Universal Description, Discovery and Integration (UDDI) offers a more structured approach. UDDI is a standard for establishing and using registries of web services. A company could establish its own private registry of web services available internally, or to its partners and customers. There also are several public UDDI registries that anyone can search, and to which anyone can publish the availability of their own web services.

Understanding a Web Service:

Once you identify a web service that you'd like to use, you need to know how it works: What kinds of messages does it respond to? What does it expect each message to look like? What messages does it return, and how do you interpret the responses? The Web Services Description Language (WSDL) provides a way to declare what messages are expected and produced by a web service, with enough information about their contents to enable using the service successfully with little or no additional information. When you create a web service, you can create a description of the service using WSDL and distribute the description file (often called a WSDL file) to prospective users of the web service, either directly or by including a link to the WSDL file in a UDDI registry entry.

Communicating With a Web Service:

Now that you've obtained the WSDL description of a Web Service, you're ready to invoke it. Web Services communicate with one another via messages in a format known as XML. XML (Extensible Markup Language), like HTML, is a descendent of Standard Generalized Markup Language (SGML). HTML focuses on the way information is to be presented. XML, on the other hand, focuses on the structure of the information, without regard to presentation issues. That's one reason XML is well suited to exchanging information between automated systems. Web services exchange XML messages with one another, typically using either HTTP or SMTP (e-mail) to transport the messages. The Simple Object Access Protocol (SOAP) is a further specification of how to use XML to enable web services to communicate with one another. A SOAP message is just an XML message that follows a few additional rules, most of which deal with how the elements of the message are encoded, and how the message as a whole is addressed.

Friday, January 05, 2007

A Strategy for Planning

Here is a good article on ST.

--------------------------------------

Traditionally, strategic planning has been a process that involves documenting business goals and objectives, then developing specific plans and initiatives to achieve the desired end state. This process while effective, is limited in several ways. Strategic planning is often bounded by management perspective, is not inclusive of diverse thinking, and does not stimulate innovation.

full article here

Sunday, November 05, 2006

Life Cycle of a Software Bug


Bug tracking workflow, i.e., the lifecycle of a bug or defect, describes the states of the bug or defect from it is created to it is closed. The following are some commonly used terms for software bug tracking (if you are in a hardware or help desk customer support situation, it could be completely different):

new

When a bug is newly created, it has a state 'new'. Some people separate this 'new' state into two states, namely, 'open' before the bug is assigned and 'assigned' after the bug is assigned. In the case of Bugzero, since a newly created bug is always assigned, you may just call it 'new' or 'open' without the 'assigned' state.

You still can have an 'assigned' state if you decide to have all the newly submitted bugs to be sent to a manager (with 'new' state), and the manager then really assigns the bug. You can configure the workflow such that the next allowed state for 'new' is 'assigned'.

open

Some people call a newly created and yet to be assigned bug a state 'open'.

assigned

Some people call a newly created and assigned bug a state 'assigned'.

fixed

A bug that has been fixed by a developer has a state of 'fixed'. Normally, this is a state before the bug is confirmed (by QA) to be really fixed. If a bug is confirmed to have been fixed, it should have a state of 'closed'. Some systems allow you to configure that, only Developers can fix a bug.

resolved

Similar to 'fixed'.

closed

If a bug is confirmed (by QA) to have been fixed, it should have a state 'closed'. Some systems allow you to configure that, only QA can close a bug.

reopened

A 'closed' bug can be re opened if it re-surfaced or it is found to be not really fixed.

suspended

A bug can be 'suspended' if it is determined that the bug should not be fixed immediately or a fix can be delayed. Some people call it 'deferred'. Some systems allow you to configure that only a certain person, such as a Manager, can suspend a bug.

deferred

Similar to 'suspended'.

analyzed

If more information is needed to fix the bug, it can be conveniently set to a state 'analyzed'. You may want call it a different name, such as 'update'.