Dashboard using ElasticSearch, Logstash & Kibana - 1

All set ? I will try my best to list down the exact steps followed by me to get the ELK stack working on windows. I have tried to get in as much details as possible , special thanks to my co-worker – Kiran, for helping me with this research

This guide was installed successfully on  - Windows 7 Enterprise

Let’s get started

1. Dowload ElasticSearch , Logstash and Kibana from here

2. Create folders in your local drive say c:\Elastic and extract all the folders. So, after it is done, here is how it looks

c:\Elastic\elasticsearch

c:\Elastic\logstash

c:\Elastic\Kibana

Optionally, you can create a new folder say – elasticlogs , which will house the log files, incase you want to dump it there

c:\Elastic\elasticlogs

In the Elasticsearch\bin folder , edit the elasticsearch.yml to include  -

http.cors.enabled: true

Create a logstash config file with

                input {
                file {
                  type => "XMLLogs"
                  path => ["C:/ElasticLogs/*.*","//networkpath/*.*"]
                }
                }
                output {
                 stdout {codec => rubydebug }
                elasticsearch {
                   host => "localhost"
                    protocol => "http"
                    }
                }

3. Download  and install the latest version of Java JDK and install it depending on your OS architecture

4. Set your Java path , to do this

Right click on the My Computer icon on your desktop and select properties

Click the Advanced Tab

Click the Environment Variables button

Under System Variable, click New

Enter the variable name as JAVA_HOME

Enter the variable value as the install path "C:\Program Files\Java\jdk1.8.0_06" (update your java version accordingly

Click Ok

Click apply changes

5. Install IIS

1. First, go to Control Panel, and then click on Programs. You’ll see a link for “Turn Windows features on or off”
2. 
3. If you expand the Internet Information Services tree node, you can see that there are a lot of options beneath it. You will probably want to explore these options, because even if you click on IIS, some of the necessary options for doing development aren’t checked.
4. 
5. Once you’ve gone ahead and checked the items you want, and clicked OK, you’ll see this dialog for a while….
6. 
7. Now when you navigate in your browser to localhost, you’ll see the new default page…
8. 

6. Open IIS Manager, by going to command prompt and using “inetmgr”  IIS manager will open, now stop the "Default Web Site"

7. Create a new website for Kibana as shown below
Right click on "sites" in the left part of IIS Manager and click "Add Website" . In the end it should look something like this

You can add mime types as below if your IIS version is older

".": application/octet-stream
".json": text/html

8. Start elasticsearch by hitting this in command prompt C:\Elastic\elasticsearch\bin>elasticsearch

9. Check if your elastic search is working by pointing your browser to localhost:9200

You should get something like this.

10. Now reboot your server so you can test that everything is automatically starting on boot.

Congrats you have installed it!

 

Some Tips:

To clear elasticsearch cache
1. Install curl - http://www.confusedbycode.com/curl/
2    run from cmd - curl -XDELETE "http://localhost:9200/_all"

Starting logstash
logstash.bat agent -f logstash.conf
 
To check if the logstash config file is correct with parameters
  logstash.bat agent -f logstash.conf --configte

Setting up the Logstash and ElasticSearch to run as an automatic service.

1.  Start elasticsearch and put it on autostart
Open a console and go to "c:\Elastic\elasticsearch\bin\" & type the following command:

service install

You should get service has installed

Now type – service manager and  something similar to below should appear

 

You have to change on the tab the "Startup type" from Manual to Automatic and then press Apply this should make Elasticsearch start automatically on server boot.
This window contains some more options such as how much memory Elasticsearch will use you can find this on the "Java" tab I would suggest to make this fitting for your server if you have a servers that will handle a huge amount of logs I would increase the "Maximum Memory Pool: 1024" at least to a higher amount.
Before you close the window make sure to press "Start" so it actually will run right now

This is everything to start ElasticSearch automatically on boot to test that it is working open a browser and go to the url you used in IIS  or go to: //127.0.0.1:9200/
If you see a json string something like what you saw in step 9  picture then it means your Elasticsearch is running

2. Create a Logstash startup bat file

A “run.bat" should simply contain this line -

logstash.bat agent –f  logstash.conf

Now place your "run.bat" in the folder: C:\Elastic\logstash\bin

3. Start Logstash & Autostart it
For this step we need another small program to create a proper windows service so please go ahead and download "NSSM" (the Non-Sucking Service Manager)

Once you have the zip file simply unzip it and copy the file from the unzipped folder you now have: "nssm-2.24\win64" (nssm.exe) to "C:\Elastic\logstash\bin" so it should result in you having "C:\Elastic\logstash\bin\nssm.exe".
Now open a Command Prompt and type:

cd c:\Elastic\lostash\bin

nssm install logstash

Ensure you have the details filled as below

Also make sure that "Startup type" is on Automatic.

Now the following step is additional but recommended if you are 100% going to use Elasticsearch, click on the "Dependencies" tab and add the following: elasticsearch-service-x64

The reason for this step is that Logstash can do difficult if you have a Elasticsearch output but it is not actually running.
Now this is all so press on the "Install service" button to finish setting up a service for Logstash.

Now, you actually can stop and start Logstash or Elasticsearch, easily from  "services.msc" as they are now windows services.

Read more

Key word driven Automation framework

Keyword-based test automation framework can be categorized under fourth generation automation approach. It is a Software testing technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.
Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data.
Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
When the software under test is changed, revisions to the test and to the automation scripts are necessary. By using a keyword-based framework, organizations can greatly reduce the amount of maintenance needed, and avoid rewriting entire test scripts. When there is changes made on the software the entire automation need not be changed, the existing automation can be modified by testers or business analysts. When required, changes to automated keywords can be completed by automation engineers without affecting the rest of the test, and can be swapped into other tests in the library as needed.

Read more

Baseline? Benchmark?

[Me] : - What’s the difference between Baseline and Benchmarking with respect to performance testing?

[Guruji]:-Creating a baseline is the process of running a set of tests to capture performance metric data for the purpose of evaluating the effectiveness of subsequent performance-improving changes to the system or application. A critical aspect of a baseline is that all characteristics and configuration options except those specifically being varied for comparison must remain invariant.

With respect to Web applications, you can use a baseline to determine whether performance is improving or declining and to find deviations across different builds and versions. For example, you could measure load time, the number of transactions processed per unit of time, the number of Web pages served per unit of time, and resource utilization such as memory usage and processor usage. Some considerations about using baselines include:

A baseline can be created for a system, component, or application. A baseline can also be created for different layers of the application, including a database, Web services, and so on.

A baseline can set the standard for comparison, to track future optimizations or regressions. It is important to validate that the baseline results are repeatable, because considerable fluctuations may occur across test results due to environment and workload characteristics.

Baselines can help identify changes in performance. Baselines can help product teams identify changes in performance that reflect degradation or optimization over the course of the development life cycle. Identifying these changes in comparison to a well-known state or configuration often makes resolving performance issues simpler.

Baselines assets should be reusable. Baselines are most valuable if they are created by using a set of reusable test assets. It is important that such tests accurately simulate repeatable and actionable workload characteristics.

Baselines are metrics. Baseline results can be articulated by using a broad set of key performance indicators, including response time, processor capacity, memory usage, disk capacity, and network bandwidth.

Baselines act as a shared frame of reference. Sharing baseline results allows your team to build a common store of acquired knowledge about the performance characteristics of an application or component.

Avoid over-generalizing your baselines. If your project entails a major reengineering of the application, you need to reestablish the baseline for testing that application. A baseline is application-specific and is most useful for comparing performance across different versions. Sometimes, subsequent versions of an application are so different that previous baselines are no longer valid for comparisons.

Know your application’s behavior. It is a good idea to ensure that you completely understand the behavior of the application at the time a baseline is created. Failure to do so before making changes to the system with a focus on optimization objectives is frequently counterproductive.

Baselines evolve. At times you will have to redefine your baseline because of changes that have been made to the system since the time the baseline was initially captured.

Benchmarking is the process of comparing your system’s performance against a baseline that you have created internally or against an industry standard. In the case of a Web application, you would run a set of tests that comply with the specifications of an industry benchmark in order to capture the performance metrics necessary to determine your application’s benchmark score. You can then compare your application against other systems or applications that also calculated their score for the same benchmark. You may choose to tune your application performance to achieve or surpass a certain benchmark score. Some considerations about benchmarking include:

You need to play by the rules. A benchmark is achieved by working with industry specifications or by porting an existing implementation to meet such standards. Benchmarking entails identifying all of the necessary components that will run together, the market where the product exists, and the specific metrics to be measured.

Because you play by the rules, you can be transparent. Benchmarking results can be published to the outside world. Since comparisons may be produced by your competitors, you will want to employ a strict set of standard approaches for testing and data to ensure reliable results.

You divulge results across various metrics. Performance metrics may involve load time, number of transactions processed per unit of time, Web pages accessed per unit of time, processor usage, memory usage, search times, and so on

Read more

Perf testing terminologies

Capacity	The capacity of a system is the total workload it can handle without violating predetermined key performance acceptance criteria.
Capacity test	A capacity test complements load testing by determining your server’s ultimate failure point, whereas load testing monitors results at various levels of load and traffic patterns. You perform capacity testing in conjunction with capacity planning, which you use to plan for future growth, such as an increased user base or increased volume of data. For example, to accommodate future loads, you need to know how many additional resources (such as processor capacity, memory usage, disk capacity, or network bandwidth) are necessary to support future usage levels. Capacity testing helps you to identify a scaling strategy in order to determine whether you should scale up or scale out.
Component test	A component test is any performance test that targets an architectural component of the application. Commonly tested components include servers, databases, networks, firewalls, and storage devices.
Endurance test	An endurance test is a type of performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models and load volumes anticipated during production operations over an extended period of time. Endurance testing is a subset of load testing.
Investigation	Investigation is an activity based on collecting information related to the speed, scalability, and/or stability characteristics of the product under test that may have value in determining or improving product quality. Investigation is frequently employed to prove or disprove hypotheses regarding the root cause of one or more observed performance issues.
Latency	Latency is a measure of responsiveness that represents the time it takes to complete the execution of a request. Latency may also represent the sum of several latencies or subtasks.
Metrics	Metrics are measurements obtained by running performance tests as expressed on a commonly understood scale. Some metrics commonly obtained through performance tests include processor utilization over time and memory usage by load.
Performance	Performance refers to information regarding your application’s response times, throughput, and resource utilization levels.
Performance test	A performance test is a technical investigation done to determine or validate the speed, scalability, and/or stability characteristics of the product under test. Performance testing is the superset containing all other subcategories of performance testing described in this chapter.
Performance budgets or allocations	Performance budgets (or allocations) are constraints placed on developers regarding allowable resource consumption for their component.
Performance goals	Performance goals are the criteria that your team wants to meet before product release, although these criteria may be negotiable under certain circumstances. For example, if a response time goal of three seconds is set for a particular transaction but the actual response time is 3.3 seconds, it is likely that the stakeholders will choose to release the application and defer performance tuning of that transaction for a future release.
Performance objectives	Performance objectives are usually specified in terms of response times, throughput (transactions per second), and resource-utilization levels and typically focus on metrics that can be directly related to user satisfaction.
Performance requirements	Performance requirements are those criteria that are absolutely non-negotiable due to contractual obligations, service level agreements (SLAs), or fixed business needs. Any performance criterion that will not unquestionably lead to a decision to delay a release until the criterion passes is not absolutely required ― and therefore, not a requirement.
Performance targets	Performance targets are the desired values for the metrics identified for your project under a particular set of conditions, usually specified in terms of response time, throughput, and resource-utilization levels. Resource-utilization levels include the amount of processor capacity, memory, disk I/O, and network I/O that your application consumes. Performance targets typically equate to project goals.
Performance testing objectives	Performance testing objectives refer to data collected through the performance-testing process that is anticipated to have value in determining or improving product quality. However, these objectives are not necessarily quantitative or directly related to a performance requirement, goal, or stated quality of service (QoS) specification.
Performance thresholds	Performance thresholds are the maximum acceptable values for the metrics identified for your project, usually specified in terms of response time, throughput (transactions per second), and resource-utilization levels. Resource-utilization levels include the amount of processor capacity, memory, disk I/O, and network I/O that your application consumes. Performance thresholds typically equate to requirements.
Resource utilization	Resource utilization is the cost of the project in terms of system resources. The primary resources are processor, memory, disk I/O, and network I/O.
Response time	Response time is a measure of how responsive an application or subsystem is to a client request.
Saturation	Saturation refers to the point at which a resource has reached full utilization.
Scalability	Scalability refers to an application’s ability to handle additional workload, without adversely affecting performance, by adding resources such as processor, memory, and storage capacity.
Scenarios	In the context of performance testing, a scenario is a sequence of steps in your application. A scenario can represent a use case or a business function such as searching a product catalog, adding an item to a shopping cart, or placing an order.
Smoke test	A smoke test is the initial run of a performance test to see if your application can perform its operations under a normal load.
Spike test	A spike test is a type of performance test focused on determining or validating performance characteristics of the product under test when subjected to workload models and load volumes that repeatedly increase beyond anticipated production operations for short periods of time. Spike testing is a subset of stress testing.
Stability	In the context of performance testing, stability refers to the overall reliability, robustness, functional and data integrity, availability, and/or consistency of responsiveness for your system under a variety conditions.
Stress test	A stress test is a type of performance test designed to evaluate an application’s behavior when it is pushed beyond normal or peak load conditions. The goal of stress testing is to reveal application bugs that surface only under high load conditions. These bugs can include such things as synchronization issues, race conditions, and memory leaks. Stress testing enables you to identify your application’s weak points, and shows how the application behaves under extreme load conditions.
Throughput	Throughput is the number of units of work that can be handled per unit of time; for instance, requests per second, calls per day, hits per second, reports per year, etc.
Unit test	In the context of performance testing, a unit test is any test that targets a module of code where that module is any logical subset of the entire existing code base of the application, with a focus on performance characteristics. Commonly tested modules include functions, procedures, routines, objects, methods, and classes. Performance unit tests are frequently created and conducted by the developer who wrote the module of code being tested.
Utilization	In the context of performance testing, utilization is the percentage of time that a resource is busy servicing user requests. The remaining percentage of time is considered idle time.
Validation test	A validation test compares the speed, scalability, and/or stability characteristics of the product under test against the expectations that have been set or presumed for that product.
Workload	Workload is the stimulus applied to a system, application, or component to simulate a usage pattern, in regard to concurrency and/or data inputs. The workload includes the total number of users, concurrent active users, data volumes, and transaction volumes, along with the transaction mix. For performance modeling, you associate a workload with an individual scenario.

Read more

Perf, Load & Stress testing

[Me] : - I think the most confused definition lies in understanding what exactly is performance, load and stress tests. Can you pls help us out?

[Guruji]:-Performance tests are usually described as belonging to one of the following three categories:

Performance testing: This type of testing determines or validates the speed, scalability, and/or stability characteristics of the system or application under test. Performance is concerned with achieving response times, throughput, and resource-utilization levels that meet the performance objectives for the project or product. In this guide, performance testing represents the superset of all of the other subcategories of performance-related testing.

Load testing: This subcategory of performance testing is focused on determining or validating performance characteristics of the system or application under test when subjected to workloads and load volumes anticipated during production operations.

Stress testing: This subcategory of performance testing is focused on determining or validating performance characteristics of the system or application under test when subjected to conditions beyond those anticipated during production operations. Stress tests may also include tests focused on determining or validating performance characteristics of the system or application under test when subjected to other stressful conditions, such as limited memory, insufficient disk space, or server failure. These tests are designed to determine under what conditions an application will fail, how it will fail, and what indicators can be monitored to warn of an impending failure

Read more

TMMi

[Me] : - Guruji, what’s this TMMi?

[Guruji]:-  Just like the CMMI staged representation, the TMMi has a staged architecture for process improvement. It contains levels that an organization passes through as its testing process evolves from one with an ad-hoc and unmanaged nature to a mature and controlled process with defect prevention as its main objective. Achieving each level ensures that adequate improvements have been made as a foundation for the next stage. The internal structure of the TMMi contains testing practices that can be learned and applied systematically to support quality improvement in incremental steps. There are five levels in the TMMi that define a maturity hierarchy and an evolutionary path to test process improvement.

Read more

Testing Types & Testing Techniques

[Me]:- Guruji, what’s the difference between testing types and testing techniques. I find a lot of confusion.

[Guruji]:- Testing types deal with what aspect of the computer software would be tested, while testing techniques deal with how a specific part of the software would be tested. That is, testing types mean whether we are testing the function or the structure of the software. In other words, we may test each function of the software to see if it is operational or we may test the internal components of the software to check if its internal workings are according to specification. On the other hand, 'Testing technique' means what methods or ways would be applied or calculations would be done to test a particular feature of a software  (Sometimes we test the interfaces, sometimes we test the segments, sometimes loops etc.)

Read more

Project Terminology

[Me]:- Guruji, I am lost. My Boss has been throwing a lot of Jargons at me lately and I am not able to Digest. I am being yorked.

[Guruji]:- Don’t worry my son, check out these samples below, you will now be on front foot and take all the balls on the full toss and whack them for a six J

alpha	A very early release of a product to get preliminary feedback about the feature set and usability.
beta	A pre-released version of software that is sent to customers for evaluation and feedback.
blocking bug	A defect that prevents further or more detailed analysis or verification of a functional area or feature, or any issue that would prevent the product from shipping.
buddy build	A build of a product or component that is meant for verifying a fix or unblocking an area. (Also known as buddy drop and private build.)
buddy drop	See buddy build.
buddy test	A set of tests run by a tester on a private build from a developer.  Looking for system integration issues prior to checkin.
bug committee	See War Team
build acceptance test (BAT)	See build verification test.
build verification test (BVT)	An automated test suite run on each new build to validate the integrity of the build and basic functionality before the new build is released for general testing. (Also known as build acceptance test.)
check-in test	A test run by a developer to determine whether his code has affected the general stability of the product. (Also known as developer quicktest.)
code complete	A development milestone marking the point at which all features for the release are implemented and functionality has been verified against the functional specification.  Not to be confused with Feature code complete.
code freeze	A determinate time when no check-ins can be made into the source tree of a project without approval of the triage committee.
configuration testing	Testing on a variety of hardware platforms and software configurations (OS/drivers) to determine how the software behaves.
content plan	A non-technical document that describes the content associated with a user assistance project in detail. For example, the text and images that appear on each page of a wizard, tutorial, or interactive content.
critical update	A broadly released fix for a specific problem addressing a critical, non-security related bug.
Create-Read-Update-Delete	Create, Read, Update, Delete.  The fundamental operations performed on a database
design change request	A requested change to the functional specification after it is deemed frozen.
developer quicktest	See check-in test.
documentation plan	A document that includes the non-technical details of a user assistance deliverable. For example, an online Help plan describes the audience for the Help content, the style guide to be used, topic types, and format that will be delivered.
dot release	an incremental release to the product that signifies that only one or a couple of files were recompiled and added to the setup image.
exit criteria	A set of criteria that a product or service must meet before a particular milestone is complete.
feature code complete	A intra-milestone deliverable marking the point at which all code to enable a feature is supposed to be written and is fully testable
feature team	A team (of developers, testers, user interface designers, writers, editors, localizers, product planners, product marketing, and program managers) that is responsible for a feature.
freeze	A point at which an implementation or functional specification cannot change without significant justification and approval in a product-wide triage meeting.
functional specification	A document that describes the user problem, requirements, and functionality details of a feature or set of features.
globalization	The process of designing and implementing a product and/or content (including text and non-text elements) so that it can accommodate any local market (locale).
golden master	The final version of software for manufacturing, which has been virus checked, time stamped, and, if needed, compressed.
hard triage	See lockdown.
hotfix	A single cumulative package composed of one or more files used to address a defect in a product. Hotfixes address a specific customer situation and may not be distributed outside the customer organization without written legal consent from Microsoft. A broadly released fix for a specific product addressing a security vulnerability.
Individual Contributor	An engineer who has responsibilities at the individual level, does not formally manage other people.
launch	The activities leading up to and through a product's release into the marketplace.
localizability	The ability of a product and/or content (including text and non-text elements) to be adapted for any local market (locale).
localization	The process of adapting a product and/or content (including text and non-text elements) to meet the language, cultural, and political expectations and/or requirements of a specific local market (locale).
lockdown	A development process for tightly controlling code changes in an effort to reduce bug regressions. (Also known as hard triage).
marketing plan	A document that includes the details of positioning, a situation analysis, marketing objectives, marketing strategies, analysis of competition, description of target audience, pricing, estimated cost of goods, and profitability.
marketization	The process of modifying the user experience through changes, additions or deletions of functionality and/or content to better suit different markets (not limited to the localizable portion of the product).
milestone	1) A specific, measurable event that sharply defines the product development stage; 2) The current phase in the product cycle.  Binary in nature, either 100% complete or 100% not complete.
milestone 0 (M0)	The planning and designs phase of a product in which functional specifications, designs, and schedules are completed before implementation begins.
milestone 1 (M1)	The first full coding milestone in the implementation phase, in which all developers are coding against the functional specification.
milestone 2 - n	Additional implementation milestones.
milestone criteria	See exit criteria.
point release	See Dot Release
postmortem	A review at the end of a project to discuss what went well and what went poorly so that effective processes are reinforced and improvements are identified.
private build	See buddy build.
production beta	A beta release that is intended for a set of customers to put into a production environment.  Effectively, a mini-RTM, with support from the product team, QFE and hotfix support.  Implies that the production beta is upgradeable to RTM bits.
quick fix engineering	See hotfix
real-time mode	See lockdown.
release	A particular version of a piece of software, most commonly associated with the most recent version (as in "the latest release").
release candidate	A build of the product produced with no known issues that the product team believes should prevent it from being released to manufacturing or to the Web.
release candidate 0	The first build of the product produced after code complete that has no known issues and no new active bugs accepted by the triage committee for a certain number of days. (Also known as zero bug release).
release criteria	See exit criteria.
release to manufacturing	The point at which the final disks and full sets of documentation are sent to manufacturing for product build and subsequent release.
release to Web	The point at which the final code is declared ready to be propagated to the data center.
rolling build	a system that allows for incremental code to be compiled into a build.  Instead of compiling a bunch of code at once, rolling builds focus on building a single changelist from SD to isolate build breaks by checkin.
security patch	See hotfix
service level agreement	An agreement between two organizations detailing the level and nature of support that one team agrees to provide, and to which the other team agrees to reciprocal commitments.
service pack	A cumulative set of all hotfixes, security patches, critical updates, and updates created and fixes for defects found internally since the release of the product. Service packs may also contain a limited number of customer requested design changes or features.
signoff	The point at which program management, development, test, user assistance, localization, and Product Support Services agree that a release is official before manufacturing will start reproducing it.
silver master	The release disk set that the localization vendor sends to Microsoft, which contains all of the final-tested software files that comprise the product.
sim-ship	The simultaneous release to manufacturing of localized versions with the source product.
testability	Testability is the degree to which systems are designed and implemented to make it easier for test automation to achieve complete code path coverage and simulate all usage situations in a cost efficient manner.   Testability is also defined as visibility and control.  Visibility is our ability to observe the states, outputs, resource usage and other side effects of the software under test.  Control is our ability to apply inputs to the software under test or place it in specified states
test design specification	A document that defines the testing requirements for an area of the product. (Also known as test requirements document.)
test release document	A document that the development team writes that defines which parts of the product are testable and which are not.
test requirements document	See test design specification.
triage	The process of deciding which bugs to fix, which to postpone to a future release, and which not to fix.
triage committee	See War Team
unit test	A test written and run by a developer to test specific modules and behaviors of his code in depth. Often a subset of unit tests are also used as check-in test.
user assistance functional specification	A technical document that describes the user problems, requirements, and functionality details of a user assistance feature or set of features, such as an online Help or content-tracking system.
user assistance plan	A non-technical document that contains vision, business case, and customer focus for each type of user assistance content; lists user assistance features, documents, deliverables, and other content that will ship with the product or service.
user experience	A team of designers who perform usability studies with customers, as well as design user interface
vision document	A document that describes the strategic goals and direction for the product, service, or feature.
vision statement	A one or two sentence summary of the principle objectives for the current release, which can be used by any team member to help prioritize work and make project decisions.
visual freeze	A point after which the user interface cannot change without approval from the triage committee.
war team	A committee that represents the entire product group that meets to decide which bugs to fix, which not to fix, and which to postpone.  Triage teams roll up into War Team and usually have one representative attending.  (also known as Ship Room, Ship Team)
zero bug bounce	The first point after code complete that there are no active bugs accepted by the triage committee that are older than a certain number of hours.
zero bug release	See release candidate 0.

Read more