Few Bits and pieces about Software Testing.
After 10 years working in Construction industry, I am trying my hand in Software industry with learning about testing software applications ( Desktop & Web based applications). This area seems to be very hot!!! area of software development and implementation. This blog is my understanding of process of testing. So please do comment.
What is Software Testing?
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. (wiki) In other words, it is to ensure that whether the application is working as per customer requirements or not and the application is acceptable to all its STAKEHOLDERS.
How is Software Testing done?
In face of the question it seems to be a foolish question to ask. “How do you test a software/ website” . Well, to answer the question, easiest way is to employee to sit and go through each and every module & element of the software and run it with a set of sample data. Voila!!! Manual Testing is born. But before the term was coined and became a specialized area in Software Industry under Quality Control & Assurance, this area was generally done by the developers or one team member of the software developing team.
Methodology of Testing a Software.
In any industry, there are a set of steps to follow and documentation to be done–be it cooking or surveying or software development. This documentation and planning process has come to be known in software industry as SDLC–Software Development Life Cycle
Software Development Life Cycle: is similar to any other life cycle (oops!!! birth to death??–there is no death for software. Is there?.) i.e. identifying the steps from start to finish and documenting them. SDLC is in 7 steps /Phases.
- Requirements capturing
- Support & Maintenance
All documentation is saved in a repository with version system so as to be able to track all documentation and editions.
My understanding of the SDLC
Software life starts with client/ customer identifies an area of requirement where a software can be used or implemented. This is identified as Business Requirement. To fulfill this need for software, an request for proposal (RFP) is sent out from the Client/Customer to select Software Developing Company/ies (SDC). (wow!!! feels very similar as any other Tendered Contract)
SDC would be responding with their tenders/ proposals, and the Client/Customer shall contract the work to one of the SDC . In the background, as is with any contract in any major business, a number of meetings do take place before contract is signed and immediately after the contract is signed/awarded. Results of the meeting– identifying the key team players i.e. Project owner (point of contact from Client), Project Manager (@SDC) etc. and with documentations– Project Management Plan, Business Requirement Specifications etc are developed.
Business Requirement Specifications
So now we got one Major document –Business Requirement Specifications (BRS) which outlines the major requirements
Business requirements in the context of software engineering or the software development life cycle, is about eliciting and documenting business requirements of business users such as customers, employees, and vendors early in the development cycle of a system to guide the design of the future system. Business requirements are often captured by business analysts, who analyze business activities and processes, and often study As-is process to define a target To-be process.
Business requirements often include
- Business context, scope, and background, including reasons for change
- Key business stakeholders that have requirements
- Success factors for a future/target state
- Constraints imposed by the business or other systems
- Business process models and analysis, often using flowchart notations to depict either ‘as-is’ and ‘to-be’ business processes
- Logical data model and data dictionary references
- Glossaries of business terms and local jargon
|Traditional BRD Structure|
eg: In London, a major tunnel project CrossRail Tunnel is being under taken–BRS would state that Tunnel from East end (Stratford) of the city to connect west end (Heathrow Airport) of the city with list of expected railway stations in between– in very broad terms and which doesn’t have any very detailed plans but over view of Budget, Time-frame, alignment and Project Management Plan. This BRS is not useful to the builder/tunneler who is going to do the physical work. He would need detailed Architectural, Design drawings , personal, etc based on whether tunnel is being build or a station or public access or railway section . Similarly, in Software development, this one would be called as Software Requirement Specification(SRS) where BRS is studied by respective technically capable personal and convert it to SRS.
Software Requirement Specification
A software requirements specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements. (Non-functional requirements impose constraints on the design or implementation such as performance engineering requirements, quality standards, or design constraints.) The specification may include a set of use cases that describe interactions the users will have with the software.
Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedule
With SRS, the key players in the SDC now can understand what is required, and this document is passed on to Software Architects where they Design or Plan the software–High Level Design & Low Level Design where software structure, behavior and views of the system are designed along with Data Base structure, GUI screens, UML etc. NOTE: here is just a screen design or database structure like number of tables and tables names & fields etc
This document is then given to both development/engineering team and Quality Control (Testing) team where their respective documentations are done.
The development team have got their own set of documentation GUI, Database & data-tables etc
The QC team would also have their set of documentation to identify test cases and data so as to quality check the developed software.
All documentation done at each level reviewed at the same level and then mapped to the level above starting from BRS so as to not to miss any item as specified in BRS
This would maintain accountability in both ways from Top-Down and Bottom-Up
same in QC
BRS>SRS>FRS>(HLD>LLD)TestPlan>Test Scenarios> Test Cases>Test Execution>Build Testing> System Level Testing> User Acceptance Testing>Production&Installation Testing.