What types of documents one need for QA, QC, and Software Testing?

For every process, some documents are vital and in this article we have discussed about the type of documents required in the below mentioned three processes:

       1. QA or quality assurance

       2. QC or quality control and

       3. Software testing

First let us see what are these three processes? 

Quality Assurance

"Quality assurance is a process that involves implementation of planned and systematic activities in a quality software system or application so that all the quality requirements of the software system or application under question are met". 

It has also got the following attributions:

1. Systematic measurement
2. Comparison with a standard
3. Monitoring of processes
4. Associated feedback loop
5. Error prevention

This whole process deals with two principles:

1. Fit for purpose and
2. Right first time

Quality Control Process

- It is a process involving a wholesome review of the quality of all the factors that have direct as well as indirect involvement in the production of the software or application. 

- This process is one of the best practices that are used for inspection of the software systems as well as applications. 

- The software products and artifacts are put through a visual examination.

- The developers or testers who are to examine the software system or application are provided with a list containing the description of the unacceptable software defects.

- The products and artifacts are visually tested and the defects are dug out and are reported to the management who are responsible for taking the action against software product release.

- This process plays a great role in the stabilization of the software production process.

Software Testing

- Software testing is a self justifying term and is just like an investigation seeking out defects and flaws in software systems and applications. 

- All the stake holders get to know about the quality of the software system or application under test.

- Tools here used are nothing but normal testing techniques that are intended to dig out the bugs and errors. 

- This process verifies:

1. Meets the requirements as stated in its documentation.
2. Works in the desired way.
3. Whether its implementation with same characteristics is possible or not.
4. Satisfaction of the stake holders.

Now let us mention what all documents are required for all the above discussed three processes:

1. First main document is the software requirements specifications document.
2. Use  cases document
3. Solution document
4. Software design documents
5. Test plan document: this document should contained detail description of the following:

(a)  Scope of the functionality the test case will test.

(b)  Expected outcome

(c)  Technique used

6. Test cases documentation containing procedure as well as the obtained results.
7. Business requirements documents
8. Functional specifications documents
9. Project member details documents containing information about the team members including testers, test lead, pm etc.
10. Software testing schedule document.
11. Traceability matrix: this document is used to check whether or not the test cases match with the requirements stated in the SRS.
12. Documents which are specific to a particular organization for quality control.
13. Discovery documents (only for quality control): this document states the business needs.
14. Test reports
15. Bug reports: this report includes all the missing, additional, wrong deviations in the functionalities or features of the software system or application.
16.  Release report: obtained at the end of testing.
17. Test scenarios
18. Test case templates
19. Test case form
20. Logs
21. Weekly status reports
22. Test scripts
23. Resolution
24. Test bed

Business requirements specification (BRS) and software requirements specification (SRS) are a must for the quality assurance and quality control processes. 

Explain Automation of Smoke Testing?

Smoke testing though being a very useful, quick  software testing methodology, if not carried out in an automated way can take up a lot of time and efforts. 

Need for Automation

There is one more thing to manually carry out smoke testing which is that if later if you come to know that the testing was being carried out in wrong direction then it will surely give you a headache to perform whole of the testing once again and again if required. 

Why automation of smoke testing useful?

- Automation of smoke testing proves to be very useful in saving time and efforts.

- Smoke testing is considered to be one of the most effective ways that are used for the validation of the changes that are made to the software system or application program code at a high level before a detailed testing is undertaken on the new build. 

- Carrying out smoke tests can help a lot to stabilize the builds and verify that there are no major problems in the software system or application.

- The reliability factor of the smoke testing determines the success of the smoke test i.e., the more you can rely up on the smoke test for finding major problems, the more you can cut down the costs and increase the quality measures of the software product or artifact.

- Smoke testing provides a reliable, scalable solution that can be quickly and easily be automated. 

- One of the best things about automating the smoke test is that it does not require any programming.

- Smoke tests can be quickly written and automated by testers of any skill level within few minutes.

What functions are provided by the tools used for automating smoke tests?

There are so many tools available for automating the smoke tests. With these tools you can perform the following functions:

1. With these tools smoke tests can be written and automated within few minutes and without requiring any programming.
2. Using these tools all the builds can be validated before any changes are incorporated in to them.
3. These tools are quite helpful when it comes to stabilizing the whole build process and verifying the readiness of a build for further full scale QA testing.
4. With these tools quick tests can be conducted ensuring that the basic functionality is still intact and is working properly.
5. The overall quality of the product can be improved since the problems can be detected early.
6. Costs can be reduced ensuring that the team is having sufficient time for developing the product.

How a smoke test is automated?

- Smoke testing is usually preceded by quality assurance.

- As soon as the errors are discovered, it requires less efforts and money to get fixed.

-In automated smoke test, a continuous build process is deployed that automatically performs a smoke test each time a build is finished developing. 

- With such a methodology, the developers come to know easily if the recently developed build caused the problem. 

- Depending upon the configuration of the build tool and the software system or application, the process of implementing the automated smoke tests will vary despite of the basic steps being followed the same. 

- After the successful completion of the build, some set up steps are performed before the application is tested. The steps may include:

1. Copying files to the appropriate places.

2. Setting up the data base tables.

3. Starting a server.

4. Installing licenses.

- Next step is to obtain all the QA files required for the smoke test and running the smoke test. 

- The report of the smoke test is saved and final step involves clean up including the steps:

1. Stopping a server
2. Emptying data base tables and
3. Deleting files.

Understanding Application Programming Interfaces(APIs)

Application Programmable Interfaces (APIs) are collections of software functions or procedures that can be used by other applications to fulfill their functionality. APIs provide an interface to the software component.These form the critical elements for the developing the applications and are used in varied applications from graph drawing packages, to speech engines, to web-based airline reservations systems, to computer security components.

Each API is supposed to behave the way it is coded i.e. it is functionality specific. These APIs may offer different results for different type of the input provided. The errors or the exceptions returned may also vary. However, once integrated within a product, the common functionality testing/integration testing may cover only those paths. By considering each API as a black box, a generalized approach of testing can be applied. But, there may be some paths which are not tested and lead to bugs in the application. Applications can be viewed and treated as APIs from a testing perspective.

The distinctive attributes that make testing of APIs slightly different from testing other common software interfaces like GUI testing.
- Testing APIs requires a thorough knowledge of its inner workings: Some APIs may interact with the operating system kernel, other APIs, with other software to offer their functionality. Thus, an understanding of the inner workings of the interface would help in analyzing the call sequences and detecting the failures caused.
- Adequate programming skills: API tests are in form of sequences of calls, namely, programs.Each tester must possess expertise in the programming language that are targeted by the API.
- Lack of domain knowledge: Involve the testers from the initial stage of development. This would help the testers to have some understanding on the interface and avoid exploring while testing.
- No documentation: Without the documentation, it is difficult for the test designer to understand the purpose of calls, the parameter types and possible valid/invalid values, their return values, the calls it makes to other functions and usage scenarios. Hence, proper documentation would help test designer design the tests faster.
- Access to source code: The availability of the source code would help tester to understand and analyze the implementation mechanism used; and can identify the loops or vulnerabilities that may cause errors.
- Time constraints: Thorough testing of APIs is time consuming, requires a learning overhead and resources to develop tools and design tests.

Understanding Agile Testing and Agile Development Methodologies

First Definition: Agile testers treat the developers as their customer and follow the agile manifesto. The Context driven testing principles act as a set of principles for the agile tester.
Second Definition: It can also be treated as the testing methodology followed by testing team when an entire project follows agile methodologies.

Traditional QA seems to be totally at loggerheads with the agile manifesto in the following regard where process and tools are a key part of QA and testing, QA people seem to love documentation, QA people want to see the written specification and where is testing without a plan.
The question arises is there a role for QA in agile projects or not? The answer is maybe but the roles and tasks are different.

The context driven principles guidelines for the agile tester are:
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project's context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem is not solved, the product does not work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right times to effectively test our products.

In the second definition, we described agile testing as a testing methodology adopted when an entire project follows agile development methodology.
Some agile development methodologies that are being practiced currently are extreme programming (XP), crystal, adaptive software development (ASD), scrum, feature driven development (FDD), dynamic systems development method (DSDM) and Xbreed.

What's the role of documentation in QA?

Sometimes, for people who are new to the software line (and specifically new to the testing business), there are questions about how important documentation would be to regular Quality work. After all, the major work is about testing some software and getting the bugs resolved, how important could testing be ? Well, the role of documentation in enabling the success of QA activities is critical. Note that documentation can be in electronic form as well, no necessity that it should be only paper, and in fact, recent trends are more towards having electronic forms that can be placed in source control areas in their specific directory locations.
QA practices should be documented such that they are repeatable, and are not dependent on individual people. Software artifacts and processes such as requirement and design specifications, design documents such as architecture, HLD, LLD, business rules, inspection reports, configuration control design and operational documents, code changes, software test plans, test cases, bug reports and decision making on important bugs, user manuals, etc. should all be documented such that these can be referred later (and prove very useful in case the project personnel are changed or should be transitioned to other teams).
As a part of documentation, there needs to be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used in all cases, else you will find later that it is hard to figure out why something changed and what were the reasons behind it.
One of the most common reasons for failures or overruns / delays in a complex software project is to have poorly documented requirements specifications. Requirement specifications are the details describing an application's externally-perceived functionality and properties. The condition for requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'user needs to enter their date of birth while creating their profile'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project.
Care should be taken to involve ALL of a project's significant 'customers' and important stakeholders in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible. This also helps in ensuring that changes later are minimized (can never be eliminated).
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
Test plans need to be documented properly with good change control, since a test plan forms the basis of determining the areas of testing, scope, responsibilities, etc. A test plan forms the first level of generation of confidence in the test strategy for the project.