The Software Development Life Cycle, or SDLC, is a method for producing high-quality, low-cost software in the least amount of time. SDLC is a well-structured flow of stages that enables a company to swiftly develop high-quality software that has been thoroughly tested and is ready for production. To assure high-quality goods or services development in hardware or software organisations, this Software Development Life Cycle will ensure delivery of efficient and high-quality software or hardware products to the end customer or clients.
Testing is necessary in order to identify any defects that are present in software which can cause harm. Without proper testing, we could potentially release a software which could malfunction and cause serious injuries. Examples can be:
- Software in a life support machine which can cause serious harm to a patient;
- Software in a nuclear plant which monitors nuclear activity can cause harm to the environment
- Banking or financial application which calculates exchange rates can cause financial loss to a business
The testing activity ends when the testing team completes the following milestones.
-
Test case execution: The successful completion of a full test cycle after the final bug fix marks the end of the testing phase.
-
Testing deadline: The end date of the validation stage also declares the closure of the validation if no critical or high-priority defects remain in the system. Code Coverage(CC) ratio: It is the amount of code concealed via automated tests. If the team achieves the intended level of code coverage (CC) ratio, then it can choose to end the validation.
-
Mean Time Between Failure (MTBF) rate: Mean time between failure (MTBF) refers to the average amount of time that a device or product functions before failing. This unit of measurement includes only operational time between failures and does not include repair times, assuming the item is repaired and begins functioning again. MTBF figures are often used to project how likely a single unit is to fail within a certain period of time
Test coverage is a quality metric to represent the amount (in percentage) of testing completed for a product. It is relevant for both functional and non-functional testing activities. This metric is used to add missing test cases.
It’s considered not possible to perform 100% testing of any product. But you can follow the below steps to come closer.
- Set a hard limit on the following factors:
- Percentage of test cases passed
- Number of bugs found
- Set a red flag if:
- Test budget is depleted
- Deadlines are breached
- Set a green flag if:
- The entire functionality gets covered in test cases
- All critical and major bugs must have a ‘CLOSED’ status
Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications; this can be done with checklists, issues list, and walkthroughs and inspection meetings.
Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.
Build: It is an installable software that is given to the testing team by the development team. Release: It is an installable software that is handed over to the customer by the tester or developer.
Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable
A good code is code that works, is free of bugs and is readable and maintainable.
Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.
Because testing during the design phase can prevent defects later on. We recommend verifying three things...
- Verify the design is good, efficient, compact, testable and maintainable.
- Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module).
- Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.
Software Quality Assurance is oriented to prevention. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with.
Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers and testers.
The role of QA (Quality Assurance) is to monitor the quality of the "process" used to produce the software. While the software testing, is the process of ensuring the functionality of final product meets the user's requirement.
A software quality assurance engineer tasks may include following things amongst others
- Writing source code
- Software design
- Control of source code
- Reviewing code
- Change management
- Configuration management
- Integration of software
- Program testing
- Release management process
Has a "test to break" attitude.
- Takes the point of view of the customer,
- Has a strong desire for quality,
- Has an attention to detail, He's also
- Tactful and diplomatic and
- Has good a communication skill, both oral and written. And he
- Has previous software development experience, too.
To support testing during development of application following tools can be used:
- Test Management Tools: JIRA, Quality Center etc.
- Defect Management Tools: Test Director, Bugzilla
- Project Management Tools: SharePoint
- Automation Tools: RFT, QTP, and WinRunner, Selenium
A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It's the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual's or team's competency.
Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.
Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.
Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an application's externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable.
A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.
A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a...
- Test case identifier
- Test case name
- Objective
- Input data requirements/steps
- Expected results.
Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.
The test strategy includes an introduction, resource, scope and schedule for test activities, test tools, test priorities, test planning and the types of tests that has to be performed.
The requirements specified by the users in the business requirement document may not be exactly translated into a functional specification. There will be a trace on between functional specification and business requirements. It is done on a one-to-one basis. This helps finding the gap between the documents. These gaps are the closed by the author of the Functional specifications (FS) or deferred after discussions
Testers should understand these gaps and use them after getting this signed off from the author of the FS. The final FS form may vary from the original
All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want.
Each level of testing is either considered black or white box testing.
Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality.
White box testing is based on knowledge of the internal logic of an application's code. Typically done by developers.
Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.
Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers should perform functional testing.
It is a testing phase where the tester tries to break the system by randomly trying the system's functionality. It can include negative testing as well.
Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance with customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application's functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.
System testing is black box testing, performed by the Test Team, the purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input. Upon completion of integration testing, system testing is started.
A style of testing that attempts to blend both “white box” and “black box” test strategies.
Similar to system testing, the macro end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.
Regression testing is like retesting after fixing or modification. Expected results from are compared to results of the software under test
Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.
Performance testing verifies loads, volumes, and response times, as defined by requirements.
Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.
Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions. For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server
Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.
Alpha testing is testing of an application when the development is nearing completion and when the application is not steady. Minor design changes can still be made as a result of alpha testing.
Beta testing is testing an application when development and testing are essentially completed, and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.
Data driven testing is an automation testing framework, which tests the different input values on the AUT. These values are read directly from the data files. The data files may include csv files, excel files, data pools and many more
Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes
Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch entails.
It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.
Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication.
- Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore, there will be problems.
- The schedule is unrealistic if too much work is crammed in too little time.
- Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.
- It's extremely common that new features are added after development is underway.
- Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.
When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested.
In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...
- Deadlines, e.g. release deadlines, testing deadlines;
- Test cases completed with certain percentage passed;
- Test budget has been depleted;
- Coverage of code, functionality, or requirements reaches a specified point;
- Bug rate falls below a certain level; or
- Beta or alpha testing period ends.
Agile testing is software testing, is testing using Agile Methodology. The importance of this testing is that, unlike normal testing process, this testing does not wait for the development team to complete the coding first and then doing testing. The coding and testing both go simultaneously. It requires continuous customer interaction.
• Unit testing • Integration testing and regression testing • System testing • Smoke testing • Functional testing • White box and Black box testing • Performance testing • Alpha and Beta testing • Load testing and stress testing • Shakeout testing
• Test Management Tools: JIRA, Quality Center etc. • Defect Management Tools: Test Director, Bugzilla • Project Management Tools: SharePoint • Automation Tools: RFT, QTP, and WinRunner, Selenium
It is the document that describes the application functionalities of the user in detail. This document has the further details of the Business Requirement Document. This is a very crucial step in Software Development Life Cycle (SDLC). Sometimes the Business Requirement Document and Business Design Document can be lumped together to make only one Business Requirement Document.
A review is an evaluation of a said product or project status to ascertain any discrepancies from the actual planned results and to recommend improvements to the said product. The common examples of reviews are informal review or peer review, technical review, inspection, walkthrough, management review. This is one of the manual testing interview questions.
Once the Business Analysts complete the requirement document, they call a meeting to explain how the functionalities work, what the process is in the designed application and other details. The Business Analysts explain the high level functionalities of the application (software) that is going to the built. The participant members in the meeting may provide feed back and various point of views are expressed. This is walk-through meeting.
Priority is the level of business importance, which is assigned to a defect found. On the other hand, severity is the degree of impact, the defect can have on the development or operation of the component or the system.
Quality assurance and testing is not the same. Testing is considered to be a subset of QA. QA is should be incorporated throughout the software development life cycle while testing is the phase that occurs after the coding phase.
The goals of QA are very different from the goals of testing. The purpose of QA is to prevent errors is the application while the purpose of testing is to find errors.
Quality control (QC) and quality assurance (QA) are closely linked but are very different concepts. While QC evaluates a developed product, the purpose of QA is to ensure that the development process is at a level that makes certain that the system or application will meet the requirements.
Regression testing is performing tests to ensure that modifications to a module or system do not have a negative effect on previous releases. Retesting is merely running the same testing again.
It is impossible to fine all errors in an application mostly because there is no way to calculate how many errors exist. There are many factors involved in such a calculation such as the complexity of the program, the experience of the programmer, and so on.
The main difference between debugging and testing is that debugging is typically conducted by a developer who also fixes errors during the debugging phase. Testing on the other hand, finds errors rather than fixes them. When a tester finds a bug, they usually report it so that a developer can fix it.
-
Bug release is when software or an application is handed over to the testing team knowing that the defect is present in a release. During this the priority and severity of bug is low, as bug can be removed before the final handover.
-
Bug leakage is something, when the bug is discovered by the end users or customer, and not detected by the testing team while testing the software.
- Build: It is a number given to Installable software that is given to the testing team by the development team.
- Release: It is a number given to Installable software that is handed over to the customer by the tester or developer.