nginx (pronounced as “engine X”) is a HTTP server and mail proxy server written by Igor Sysoev. nginx  is a lightweight, high performance web server/reverse proxy and e-mail (IMAP/POP3) proxy, licensed under a BSD-like license. It runs on UNIX, GNU/Linux, BSD variants, Mac OS X, Solaris, and Microsoft Windows.

Nginx is one of a handful of servers written to address the C10K problem. Unlike traditional servers, Nginx doesn’t rely on threads to handle requests. Instead it uses a much more scalable event-driven (asynchronous) architecture. This architecture uses small, but most importantly, predictable amounts of memory under load.
Even if you don’t expect to handle thousands of simultaneous requests, you can still benefit from Nginx’s high-performance and small memory footprint. Nginx scales in all directions: from the smallest VPS all the way up to clusters of servers.

Basic HTTP features:
Handling of static files, index files and auto-indexing
Reverse proxy with caching
Load balancing
fault tolerance
SSL support
FastCGI support, with caching, although it doesn’t have CGI support.
Name- and IP-based virtual servers
FLV streaming
MP4 streaming, using the MP4 streaming module
Web page access authentication
gzip compression

Mail proxy features:
User redirection to IMAP/POP3 backend using an external HTTP authentication server;
User authentication using an external HTTP authentication server and connection redirection to internal SMTP backend;
Authentication methods:
POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
SSL support
STARTTLS and STLS support.

Suppored Operting Systems:
FreeBSD 3 — 7 / i386; FreeBSD 5 — 7 / amd64;
Linux 2.2 — 2.6 / i386; Linux 2.6 / amd64;
Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
MacOS X / ppc, i386;
Windows XP, Windows Server 2003.

Performance:
nginx has reverse proxy server feature
nginx has Load balancer feature

Other HTTP features:
name- and IP-based virtual servers;
keep-alive and pipelined connections support;
flexible configuration;
reconfiguration and online upgrade without interruption of the client processing;
access log formats, bufferred log writing, and quick log rotation;
4xx-5xx error codes redirection;
rewrite module;
access control based on client IP address and HTTP Basic authentication;
PUT, DELETE, MKCOL, COPY and MOVE methods;
FLV streaming;
speed limitation;
limitation of simultaneous connections or requests from one address.

Experimental features:
embedded perl.

Question: When Smoke & Sanity Testing is performed in the STLC? Which of them is performed earlier & the other later & why?

Ans: Sanity testing: It is just to test the basic functionalities of a software product and application. it is done by testers.
Sanity Testing is subset of regression testing and a group of test cases are executed that are related with the changes made to the application.

Smoke testing: it is a form of regression testing. When an application made some new changes to modules or added new modules to a application then a smoke test is performed that it is working fine or not. It can be done by both developers and testers but most of time dev team perform this.
In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.
A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide
There are no certain rules for this, the both ensure whatever we are releasing it should be defect free and tester should catch defect ASAP so we can reduce time and cost to deliver best product.
In Some organizations, Sanity Testing is done first and then Smoke testing because Sanity Testing is a sub set of major function testing to check build is stable or not and major function working fine or not and smoke testing is like cursor testing where user just touch every part of the application it can be called as ad-hoc.
But in some organizations, Smoke is done first and later the sanity, but again its depend on organization to organization
Software sanity tests are commonly conflated with smoke tests. A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive. If the smoke test fails, it is impossible to conduct a sanity test.
In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct. If the sanity test fails, it is not reasonable to attempt more rigorous testing.
Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests and unit tests on an automated build as part of their development process.

Quality Assurance

Quality Control

A planned and systematic set of activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified requirements.

The process by which product quality is compared with applicable standards; and the action taken when nonconformance is detected.

An activity that establishes and evaluates the processes to produce the products.

An activity which verifies if the product meets pre-defined standards.

Helps establish processes.

Implements the process.

Sets up measurements programs to evaluate processes.

Verifies if specific attribute(s) are in a specific product or service

Identifies weaknesses in processes and improves them.

Identifies defects for the primary purpose of correcting defects.

QA is the responsibility of the entire team.

QC is the responsibility of the tester.

Prevents the introduction of issues or defects

Detects, reports and corrects defects

QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.

QC evaluates if the application is working for the primary purpose of determining if there is a flaw / defect in the functionalities.

QA improves the process that is applied to multiple products that will ever be produced by a process.

QC improves the development of a specific product or service.

QA personnel should not perform quality control unless doing it to validate quality control is working.

QC personnel may perform quality assurance tasks if and when required.

Validation

Verification

Am I building the right product

Am I building the product right

Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.

The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and performs the selected functions in the correct manner.

Am I accessing the right data (in terms of the data required to satisfy the requirement)

Am I accessing the data right (in the right place; in the right way).

High level activity

Low level activity

Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment

Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards

Determination of correctness of the final software product by a development project with respect to the user needs and requirements

Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.

Metric is a mathematical number that shows a relationship between two variables. It is a quantitative measure of the degree to which a system, component or process possesses a given attribute. Software Metrics are measures that are used to quantify the software, software development resource and software development process.

Metric generally classified into:

· Process Metric
· Product Metric

Process Metric: Metric used to measure the characteristic of the methods, techniques and tools employed in developing, implementing and maintaining the software system.

Product Metric: Metric used to measure the characteristic of the documentation and code.

The metrics for the test process would include status of test activities against the plan, test coverage achieved so far, among others. An important metric is the number of defects found in internal testing compared to the defects found in customer tests, which indicate the effectiveness of the test process itself.

Previous Entries