Who should test? and what? – An Overview

Who should do the testing?

Software Testing is not the job of one person. It is teamwork. The size of the team depends upon the complexity and size of the software being tested. The software developer should have minimum or no role in the testing process as everyone knows that for a person who has developed the software, it is very difficult to pin point errors in his own creations.


Seven soft skills crucial for a good tester are – that He or She must:

1) Be Cautious
2) Be Curious
3) Have Patience
4) Have Perseverance
5) Be Analytical
6) Be Critical but with an attitude of not jumping to conclusions.
7) Be Good Communicator

Thus “More the soft skills a tester has, better tester He or She is”

Above all, a Most Successful Tester is the one:

1) Who is completely passionate.

2) Who is always eager to learn more & more.

3) Who never gives up.

Various personnel and their roles during development & testing are:

A) Customer: Provides funding, provides requirements, approves changes and some of the test results.

B) Project Manager: Plans and manages the project.

C) Software Developer: Designs the codes and builds the software.

D) Testing coordinator: Creates test plans and test specifications based on the requirements and functional and technical documents.

E) Testing person: Executes the tests and documents the results.


Role based demarcation exclusive to the field of Testing:

1) Junior Software Testers: Are the ones having good theoretical knowledge of testing & would have participated in good number of seminars on testing or would have passed some courses in testing. Such individuals are not expected to have experience on testing; however little experience can be desirable.

2) Software Testers: Are the ones having good ability to understand testing packs, do testing, and doing documentation / defect logging. Such individuals usually do repetitive work & are invariably involved in front-end testing. Usually at least 6 months of testing experience is preferred for this role.

3) Senior Software Testers: Are the ones having responsibility of doing all tasks usually performed by a Tester. In addition to this they are involved in back-end testing. The senior testers also do updating of test cases. Usually 1 to 2 years of experience of testing is preferred for this role.

4) Testing Analysts: Are the ones having expertise in extracting requirements out of documentation & doing thorough verification with business & ascertaining the correctness of all the information. The testing analysts also do writing of test cases, executing the tests & reporting the findings thereafter. Usually 2 to 3 years of experience of testing along with at least 1-year experience of analysis is preferred for this role.

5) Testing Managers: Are the ones having experience of doing all the tasks described above. Apart from this they possess the ability of managing the entire testing process, personnel as well as the testing environment. Usually 3 to 4 years of experience of testing along with at least 1-year of managerial experience & sound expertise of Project Management is ideal for this role.

6) Testing Consultants: Are the senior people having experience of doing all the tasks described above. Consultants are usually good communicators having proven ability of man management, with the help of which they are able to effectively handle the client & the senior executives of the organization. This includes doing systematic analysis of the current testing process of the client & ability to guide the client with their expert comments & recommendations to improve. Consultants have great expertise of manual testing in addition to sound knowledge of specialized fields like Automation, Usability & Security etc.

Generally persons with 5 years or more of Testing & Project Management experience in some senior capacity are appointed as testing consultants.

7) Test Automators: Are the ones having good skills of development plus sound experience of manual testing & have acquired specialization of Automated Testing; but as of date they would not prefer to get involved in manual testing. Automators have thorough knowledge & experience of using different Automation Tools. Usually 1 to 2 years of experience of test automation is preferred for this role.

Next question comes as to what should be tested?

According to Myer (The great Testing Guru) - for most of the programs, it is impractical to attempt to test the program with all possible inputs, due to a combinatorial explosion. For those inputs selected, a testing oracle is needed to determine the correctness of the output for particular test input.

Myer also says that, for most programs, it is impractical to attempt to test all execution paths through the product, due to combinatorial explosion. It is also not possible to develop an algorithm for generating test data for paths in an arbitrary product, due to the inability to determine path feasibility.

The point, which is being emphasized here, is that complete or exhaustive testing is just not possible. This is because exhaustive testing requires every statement in the program and every possible path combination to be executed at once.



Amit Ahuja

Free Download SQL Books

1) Teach Yourself SQL in 21 Days




Amit Ahuja

Waterfall Model

There are various software development approaches defined and designed which are used/employed during development process of software, these approaches are also referred as "Software Development Process Models".

Waterfall Model

Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases.

The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model are more visible.

The stages of "The Waterfall Model" are:

Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionality. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

Advantages and Disadvantages

Advantages

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

Disadvantages

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.

Common Errors in Requirements Analysis

In the traditional waterfall model of software development, the first phase of requirements analysis is also the most important one. This is the phase which involves gathering information about the customer's needs and defining, in the clearest possible terms, the problem that the product is expected to solve.

This analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.

Well, at least that's the way it's supposed to work theoretically. In reality, there are a number of problems with this theoretical model, and these can cause delays and knock-on errors in the rest of the process. This article discusses some of the more common problems that project managers experience during this phase, and suggests possible solutions.

Problem 1: Customers don't (really) know what they want

Possibly the most common problem in the requirements analysis phase is that customers have only a vague idea of what they need, and it's up to you to ask the right questions and perform the analysis necessary to turn this amorphous vision into a formally-documented software requirements specification that can, in turn, be used as the basis for both a project plan and an engineering architecture.

To solve this problem, you should:

* Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.
* Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.
* Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve.
* Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverabl

Problem 2: Requirements change during the course of the project

The second most common problem with software projects is that the requirements defined in the first phase change as the project progresses. This may occur because as development progresses and prototypes are developed, customers are able to more clearly see problems with the original plan and make necessary course corrections; it may also occur because changes in the external environment require reshaping of the original business problem and hence necessitates a different solution than the one originally proposed.

Good project managers are aware of these possibilities and typically already have backup plans in place to deal with these changes.

To solve this problem, you should:

* Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.
* Set milestones for each development phase beyond which certain changes are not permissible -- for example, disallowing major changes once a module reaches 75 percent completion.
* Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan is updated accordingly.


Problem 3: Customers have unreasonable timelines

It's quite common to hear a customer say something like "it's an emergency job and we need this project completed in X weeks". A common mistake is to agree to such timelines before actually performing a detailed analysis and understanding both of the scope of the project and the resources necessary to execute it. In accepting an unreasonable timeline without discussion, you are, in fact, doing your customer a disservice: it's quite likely that the project will either get delayed (because it wasn't possible to execute it in time) or suffer from quality defects (because it was rushed through without proper inspection).

To solve this problem, you should:

* Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.

* Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection.

* Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favorable outcome for both parties.


Problem 4: Communication gaps exist between customers, engineers and project managers

Often, customers and engineers fail to communicate clearly with each other because they come from different worlds and do not understand technical terms in the same way. This can lead to confusion and severe miscommunication, and an important task of a project manager, especially during the requirements analysis phase, is to ensure that both parties have a precise understanding of the deliverable and the tasks needed to achieve it.

To solve this problem, you should:

* Take notes at every meeting and disseminate these throughout the project team.

* Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently.


Problem 5: The development team doesn't understand the politics of the customer's organization

The scholars Bolman and Deal suggest that an effective manager is one who views the organization as a "contested arena" and understands the importance of power, conflict, negotiation and coalitions. Such a manager is not only skilled at operational and functional tasks, but he or she also understands the importance of framing agendas for common purposes, building coalitions that are united in their perspective, and persuading resistant managers of the validity of a particular position.

These skills are critical when dealing with large projects in large organizations, as information is often fragmented and requirements analysis is hence stymied by problems of trust, internal conflicts of interest and information inefficiencies.

To solve this problem, you should:

* Review your existing network and identify both the information you need and who is likely to have it.
* Cultivate allies, build relationships and think systematically about your social capital in the organization.
* Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience.
* Use initial points of access/leverage to move your agenda forward.

Kinds of Testing that should be considered for Websites.

Black box testing – Testing not based on any knowledge of the internal design or code. Tests are based on requirements and functionality.


Incremental Integration Testing – Continuous testing of website as new functionality is added; requires that various aspects of an web applications functionality be independent enough to work separately before all parts of the program are completed.


Integration Testing – Testing that is done on combined parts of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, pages in a website etc.


Functional Testing – Black box type testing geared to functional requirements of an application; testers should do this type of testing. This doesn’t mean that the programmers shouldn’t check that their code works before releasing it (which of course applies to any stage of testing.)

System Testing – Black box type testing that is based on overall requirements specifications; covers all combined parts of a web application.

End-to-end Testing – Similar to system testing; the ‘macro’ end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity Testing or Smoke Testing – typically an initial testing effort to determine if a new web application is performing well enough to accept it for a major testing effort. For example, if there are lots of missing links, missing images, missing validations, or corrupting databases, the website may not be in a ’sane’ enough condition to warrant further testing in its current state.


Regression Testing – re-testing after fixes or modifications of the website or its pages. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.


Acceptance Testing – final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.


Load Testing – testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.


Stress Testing – term often used interchangeably with ‘load’ and ‘performance’ testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

Performance Testing – term often used interchangeably with ’stress’ and ‘load’ testing. Ideally ‘performance’ testing (and any other ‘type’ of testing) is defined in requirements documentation or QA or Test Plans.


Usability Testing – testing that is done for ‘user-friendliness’. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.


Security Testing – testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.


Compatibility Testing – testing how well website performs in a particular hardware/software/operating system//browser/network etc. environment.


Exploratory Testing – often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the website as they test it.


Ad-hoc Testing – similar to exploratory testing, but often taken to mean that the testers have significant understanding of the website before testing it.

User acceptance Testing – determining if website is satisfactory to an end-user or customer.


Alpha Testing – testing of a web application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.


Beta Testing – testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.