Software quality

1. Software quality • software quality measures • how well software is designed (quality of design), • and how well the software conforms to that design (quality of conformance)

2. This definition emphasis from three points: • Software requirements are the foundations from which quality is measured. • Lack of conformance to requirement is lack of quality. • Specified standards define a set of development criteria that guide the manager is software engineering. • If criteria are not followed lack of quality will almost result. • A set of implicit requirements often goes unmentioned, like for example ease of use, maintainability etc.

3. Software product quality • Product quality conformance to requirements or program specification; related to Reliability • Scalabilitysystem is said to scale if it is suitably efficient and practical when applied to large situations • Correctnessrefers to the input-output behaviour of the algorithm (each input it produces the correct output). • Completenessrefers to the ability of the algorithm to find a solution if one exists, and if not, to report that no solution is possible. • Absence of bugsis any problem with a computer, whether caused by software or hardware

4. Fault-toleranceis the property that enables a system to continue operating properly in the event of the failure of some of its components • ExtensibilityIt is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. • Maintainabilityis the ease with which a product can be maintained • DocumentationThe writing of product documentation

5. Source code quality • Readability • Ease of maintenance, testing, debugging, fixing, modification and portability • Low complexity • Low resource consumption: memory, CPU • Number of compilation or lint warnings • powerful input validation and error handling

6. Methods to improve the quality: • Refactoring • Code Inspection or software review • Documenting code

7. Software Testing Fundamentals • Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.

8. Testing methods

9. The box approach • Software testing methods are traditionally divided into white- and black-box testing. • These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

10. White box testing • White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these.

11. Types of white box testing • API testing (application programming interface) - testing of the application using public and private APIs • Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) • Fault injection methods - improving the coverage of a test by introducing faults to test code paths • Mutation testing methods • Static testing - White box testing includes all static testing

12. Mutation testing methods • which involves modifying programs' source code or byte code in small ways. In short, any tests which pass after code has been mutated are considered defective

13. Static testing • It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. • It is primarily syntax checking of the code and/or manually reviewing the code or document to find errors. • This type of testing can be used by the developer who wrote the code, in isolation. • Code reviews, inspections and walkthroughs are also used.

14. Black box testing • Black box testing treats the software as a "black box"—without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing.

15. Advantages and disadvantages: • The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. • Using the principle, "Ask and you shall receive," black box testers find bugs where programmers do not. • On the other hand, black box testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed.

16. black box testing has the advantage of "an unaffiliated opinion", on the one hand, and the disadvantage of "blind exploring", on the other.