Project Definition based on project engagement model

Fix Bid Pricing
The fixed price model offers customers a low risk option and can be employed when the scope and specification of the project reasonably clear. This model guarantees on time,on budget delivery project.
Deliverables,Costs and Time lines are clearly defined in the Time/fixed price model.
This model works best for customers with well defined requirements and project schedules.
Advantage
1.You don't have to deal with the day to day hassle of project management and are free focus on business strategy
2.A detailed analysis of requirements is carried out.
3.A detailed project/functional specification drawn up.

Time & Materials Pricing

This business model is based on resource utilization during project time span. When scope,specification plans of a project not easy to define at the outset,Time and materials become attractive option. At times once the scope of the project frozen Time and Material also converted in to fixed price model.
This is usually monitored through weekly time sheets or on a reporting frequency suggested by the client
Advantage
1.Flexibility to balance team size and project workloads.
2.No hidden fees
3.Customers are not billed separately for requirements gathering the project management hours

Retainer Pricing
In this model a monthly retainer fee is agreed upon at the beginning of the contract. The retainer fee is paid at the beginning of the month and entities the client to the min hours programming support. Any additional hours will be charged at the agreed hourly rate.
Advantage
1.The client would provided with weekly time sheets for the utilization of the resource.
2.Extension of the retainer engagement if required based on mutual consent. Customer are not billed separately for the requirements gathering the project management hours.

Unix - The 15 Essential UNIX commands

man - show manual for a command, example: man ls hit q to exit the man page.
cd - change directory, example: cd /etc/
ls - list directory, similar to dir on windows. example: ls /etc, use ls -l /etc to see more detail
cp - copy a file or directory, example: cp source dest if you want to copy a directory use the -R option for recursive: cp -R /source /dest

mv - move a file, example: mv source dest
rm - remove a file, example: rm somefile to remove a directory you may need the -R option, you can also use the -f option which tells it not to confirm each file: rm -Rf /dir

cat - concatenate, or output a file cat /var/log/messages

more - outputs one page of a file and pauses. example: more /var/log/messages press q to exit before getting to the bottom. You can also pipe to more more from other commands, for example ls -l /etc more

scp - secure copy, copies a file over SSH to another server. example:scp /local/file user@host.com:/path/to/save/file

tar - tape archiver, tar takes a bunch of files, and munges them into one .tar file, the files are often compressed with the gzip algorithm, and use the .tar.gz extension. to create a tar tar -cf archive.tar /directory, then to extract the archive to the current directory runtar -xf archive.tar to use gzip, just add a z to the options, to create a tar.gz: tar -czf archive.tar.gz /dir to extract it tar -xzf archive.tar.gz

grep - pattern matcher, grep takes a regular expression, or to match a simple string you can use fast grep, fgrep failure /var/log/messages, I'm usually just looking for a simple pattern so I tend to use fgrep more than regular grep.
find - lists files and directories recursively on a single line, I usually pipe grep into the mix when I use find, eg: find / fgrep log

tail - prints the last few lines of a file, this is handy for checking log files tail /var/log/messages if you need see more lines, use the -noption, tail -n 50 /var/log/messages you can also use the -f option, which will continuously show you the end of the file as things are added to it (very handy for watching logs) tail -f /var/log/messages

head - same as tail, but shows the first few lines the file

vi - text editor, there are several text editors such as emacs, and nano, but vi is usually installed on any server so its a good one to learn. To edit a file type vi file to edit a line press Esc i then to save changes and exit use Esc wq, or to quit without saving use Esc q!. There are a million other commands, but that will enable you to edit files at a basic level

Agile Methodology and Agile Testing

Agile Methodology:-
It is a methodology to satisfy the customer through early and continuous delivery of valuable software. This is useful when we don't have a clear idea of the client's requirements. The development activities can be carried out using the iterative actions

It is very effective where Client frequently changes his requirement. Since it has more iteration so you can assure a solution that meets clients requirement. More than one build deployment for a project. It involves more client interaction and testing effort.

People believe that there is less documentation in Agile. But agile also includes documentation and it can be used either a small or a large projects. In agile Development, testing is also integrated throughout the life cycle. But for the testers, they will not have a good business requirement. So they have to get the details from the client or through the developer. The testers will do more of Quality Assurance work than testing.

Agile methodology helps us to increase productivity and reduce risks.

Agile Methodology- Characteristics:-
Ø Frequent Delivery
Ø More Iterations
Ø Test frequently
Ø Less defects

There are two methods by which this methodology can be implemented:-
1- Scrum
2- Extreme Programming
Scrum: Each iteration would called a scrum which can be a 1-2 Months. In Scrum Client priorities his requirements what he want first. If developer did not meets all the requirement which was being fixed for a particular scrum than rest of the development part would be transferred to the next scrum (would be delivered in the next build), means developer can't increase time decided for a scrum. Its fixed.
Extreme Programming (XP): here iteration period would be less then in scrum , which is being 2-4 weeks.
Here developer priorities what to do first on the basis of client requirement. This duration which was being fixed for a iteration, can be increase if the some development part is still pending. The build would deployed with having all the client needs. Thus iteration period is not fixed here it can be increase but iteration should meets all the client's requirement in this build. More attention is required for testing in XP.

What is Agile Testing?

“Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing

The Challenges in Agile Testing:-

Agile Testers face lot of challenges when they are working with Agile development team. A tester should be able to apply Root-Cause Analysis when finding severe bugs so that they unlikely to reoccur. While Agile has different flavors, Scrum is one process for implementing Agile.
Some of the challenging scrum rules to be followed by every individual are

Obtain Number of Hours Commitment Up Front
Gather Requirements / Estimates Up Front
Entering the actual hours and estimated hours daily.
Daily Builds
Keep the Daily Scrum meetings short
Code Inspections are Paramount

So, in order to meet the above challenges, an agile tester needs to be innovative

How Testers Can be More Innovative in the Age of Agile Testing?
Here are Important Keys to Innovation:
1. Creative
A good Agile Tester needs to be extremely creative when trying to cope up with speed of development/release. For a tester, being creative is more important than being critical.
2. Talented
He must be highly talented and strives for more learning and innovating new ideas. Talented Testers are never satisfied with what they have achieved and always strives to find unimaginable bugs of high value and priority.
3. Fearless
An Agile Tester should not be afraid to look at a developer’s code and if need be, hopefully in extreme cases, go in and correct it.
4. Visionary
He must have a comprehensive vision, which includes client’s expectations and delivery of the good product.
5. Empowered
He must be empowered to work in Pairs. He will be involving in Pair Programming to bring shorter scripts, better designs and finding more bugs.
6. Passionate
Passionate Testers always have something unique to contribute that may be in terms of their innovative ideas, the way they carry day-to-day work, their outputs and improve things around them tirelessly.
7. Multiple Disciplines
Agile Tester must have multiple skills like, Manual, Functional, Performance testing skills and soft skills like Leadership skills, Communication skills, EI, etc. so that agile testing will become a cake walk.

What is Verification and Validation

Verification:-

* Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walk throughs, and inspection meetings.
* To ensure that the s/w correctly implements the specific function.
* Are we building the product right or not?
*Verification is the process of doing reviews and walkthroughs and conducting interviews.This is doing before coding phase.
Verification is the static process. It performs each and every stage of SDLC.

What is the importance of the Verification Phase?
Verification process helps in detecting defects early, and preventing their leakage downstream. Thus, the higher cost of later detection and rework is eliminated.

What are the various types of reviews?
Types of reviews include Management Reviews, Technical Reviews, Requirement review, Design review, code review ,Inspections, Walkthroughs and Audits.

Walkthrough:-
A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.
we can discuss/raise the issue at peer level. Also walkthrough does not have minutes of the meet. can happen at any time and conclude just like that, no schedule as such.

Objective of Walkthorugh:-
Detect errors early.
Ensure (re)established standards are followed
Increase the quality of the project, thereby improving morale of the team members.

Inspection:-
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything. Attendees should prepare for this type of meeting by reading thru the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effective methods of ensuring quality
One will read through his work done / proposal for the upcoming task( code/testcase/design) what ever he has done in the time(depends on the frequency of Inspection company to company it may change)
writer will note down the issues discussed/ to be done.
Moderator(s) have to comment out his/her opinion.
That's how inspection happens.

Validation:-
*Validation typically involves actual testing and takes place after verifications are completed.
*To ensure that the s/w is satisfied the customer requirements.
*Validation is the process of doing actual testing in the source code. This is always starting after coding in SDLC.
*Are we building the right product
Validation is Dynamic process.

TEST METRICS

Test Metrics
---------------
‘Metric’ is a measure to quantify software, software development resources, and/or the software development process.
A Metric can quantify any of the following factors:
Schedule Variance
Work Effort
Product Size
Project Status
and Quality Performance

Few of Defect metrics
Defect Density:-
Defect Density=No of defects reports by QA+No of defects report by Peer or client /Actual size of the project
The Size can be in KLOC, SLOC, or Function Points. The method used in the Organization to measure the size of the Software Product.

KLOC = Thousand lines of code 1 K= 1000 lines SLOC = Source lines of code 1000 SLOC = 1KLOC this is used to compare the relative number of defects in various software components, to find out the defect prone areas of the application.

Test Effectiveness :-
Test Effectiveness=T/T+UAT
T= Total no of defects reported during testing
UAT=Total no of defects reported during user acceptance testing.

Overall Test Effectiveness (OTE)
This metric will indicate the effectiveness of the Testing process in identifying the defects for a given project during the testing stage

Overall Test Effectiveness: OTE = [(Number of defects found during testing) / (Total number of defects found during Testing + Number of defects found during post delivery)] * 100

Defect Removal Efficiency:-
DRE=(Total No Of Defects Removed or Resolved /Total No. Of Defects Injected)*100 at various stages of SDLC

Defect Leakage:-
Defect leakage is nothing but defect identified by the client

Defect Age:-
Duration between defect found and closed.

Schedule Variance (SV)
This metric gives the variation of actual schedule vs. the planned schedule. This is calculated for each project – stage wise
Percentage of time taken to complete the task
SV = [(Actual no. of days – Planned no. of days) / Planned no. of days] * 100

Effort Variance:-
This metric gives the variation of actual effort vs. the estimated effort. This is calculated for each project Stage wise.
EV = [(Actual person hours – Estimated person hours) / Estimated person hours] * 100

Cost Variance (CV)
This metric gives the variation of actual cost Vs the estimated cost. This is calculated for each project Stage wise
CV = [(Actual Cost – Estimated Cost) / Estimated Cost] * 100

Size Variance
This metric gives the variation of actual size Vs. the estimated size. This is calculated for each project stage wise
Size Variance = [(Actual Size – Estimated Size) / Estimated Size] * 100

Review Effectiveness
This metric will indicate the effectiveness of the Review process
Review Effectiveness = [(Number of defects found by Reviews) / ((Total number of defects found by reviews) + Testing)] * 100

How do you determine metrics for your application?

Objectives of Metrics are not only to measure but also understand the progress to the Organizational Goal.
The Parameters for determining the Metrics for an application:
Duration Complexity
Technology Constraints
Previous Experience in Same Technology
Business Domain Clarity of the scope of the project

Goal Question Metric methods for identifying metrics :-

Goal question metric methods for identifying metrics is an excellent technique for selecting appropriate metrics to meet your needs. The GQM works like this :Begin by selecting few projects or organization goals. State the goals in quantitative and measurable term as possible. Then find out what must be change to reach the goal, and identify ,define what is to measured to quantify progress made to achieve the goal.

• GQM is a systematic approach for integrating goals to the process
• The metrics relevant to process improvement can be effectively identified and tailored to the organization and its goals.
• Measurement provides the most appropriate information to ensure consistency and completeness in the quest for goal attainment

When do you determine Metrics?
When the requirements are understood in a high-level, at this stage, the team size, project size must be known to an extent, in which the project is at a "defined" stage

Diff between STLC & SDLC

STLC
1. Preparing the test plan
2. Creating the test environment
3. Writing the test cases
4. Creating test scripts
5. Executing the test scripts
6.Analysing the results and reporting the bugs
7. Doing regression testing
8. test exiting

SDLC

1.Project initiation
2.Requirement gathering and documenting
3.Designing
4.Coding and unit testing
5.Integration testing
6. system testing
7. installation and acceptance testing
8. support or maintenance

What is SDLC

SDLC
1)Requirement & analysis
2)Design
3)Coding
4)Testing
5)Release & Maintenance
Requirement & analysis:-
the main aim of requirement analysis phase is to produce a document that properly specifies all requirements of the customer. requirement specification document is the primary out put of this phase.
Proper requirements and analyses are critical for having successful project.
The need for executing this phase properly to produce an srs with the least defect should be evident.
Design:-
After analysis the development will prepare the design phase for the project the design is prepared as per requirement.
The design for fronted based on the HLD ,LLD,Data base design.
HLD means (High level design):
It explain main modules of the project
LLD means (Low level design):
It explain all the details of the operands etc
Coding :-
During the coding phase required programing language is used to produce the program. This phase produces source code, executables and database design.
Testing:-
After coding is done the application is tested to ensure it is working as per the requirement.
Testing is conducted by developers,testing team,users at different stages
Release & Maintenance:-
After testing is completed the s/w is released to the customer,After released maintenance is the for any issues in
the s/w.

Static and Dynamic Testing ?

Static Testing
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review's, Inspection's and Walkthrough's are static testing methodologies.

Dynamic Testing
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

Diffrence between End to End testing and System Testing

End to End testing involves validating the process / data flow from the Start point of the Application to the End point of the Application. We could consider Databases as well intermediate Servers involved in the Application.
Similar to system testing, but involves the testing of complete application environment such as interacting with database, using network communications, interacting with other hardware, application or systems if appropriate.


System testing differs in a manner that it involves testing the System as against the specified Requirements. But scope would be limited to only the system in question alone.

Block box testing techniques

The main difference between EP and BVA is that EP determines the number of test cases to be generated for a given scenario where as BVA will determine the effectiveness of those generated test cases.

Equivalence partitioning : Equivalence Partitioning determines the number of test cases for a given scenario.
Equivalence partitioning is a black box testing technique with the following goal:
1.To reduce the number of test cases to a necessary minimum.
2.To select the right test cases to cover all possible scenarios.

Here we are dividing input values to be given into valid and invalid values

It is a Black Box Testing Technique that divides the input domain into classes of data from which test cases can be derived.

BVA
This is also a Black Box Testing Technique which concentrates on the Corner cases or the boundaries of the input domain rather than its center

Exapmle
username: min length=4
max length=7
alphanumeric
for this if u where to write BVA and ECP
then it is in this manner
BVA
min+1 valid
min-1 invalid
max+1 invalid
max-1 valid
ECP
valid Invalid
0-9 special characters
a-z

Error Guessing:-
Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation: Either when reading the functional documents or when you are testing and find an error that you have not documented.

What is Test Strategy

Test Strategy

Test Strategy is a Document, developed by the Project manager, which contains what type of technique to follow and which module to test. Here technique means type of testing. As different testing techniques can be applied to test software based on our goals. For example stress and load testing is applied on web based applications. We have to decide which testing approach we will use to test a module as following testing approaches can be used.

1)Black Box Testing (2) White Box Testing (3) Ad-hoc testing (4) Acceptance Testing (5) Recovery testing (6) Sanity testing (7) Smoke testing (8) Regression testing (9) End to End Testing (10) System Testing (11) Functional Testing (12) Unit Testing (13) Alpha Testing
(14) Beta Testing (15) Exploratory Testing etc.

What is Test Plan

Test plan :-
-------------
Test plan is a Document,which describes the scope, approach and schedule of testing activities or we can say "What to Test","How to Test", "When to Test", "Who to Test".It is the responsibility of test lead to develop this document.
Scope of testing
Testing approach
Time frame
Objectives of testing
What will be the environment
Risk factors
1.Risk Identification[conducts risk identification meetings]
2.Risk Analysis [Categorizing Risk]
3.Risk Response planing [next plan mitigation activities, contingency activities, and review the risk action plans]
4.Risk Plan implementation [once these are established, monitor trigger events, execute the action plan, and update the Risk Log.]
5.Risk Tracking, Monitoring & Control [this stages concerns how the risk is progressing, as well as mitigation/contingency strategies that have been executed. When changes to the risk occur, repeat the cycle of identify, analyze, and plan]
Features to be tested
Features not to be tested.
Roles and Responsibilities
Entry and Exit Criteria
Entry
1.All requirements and design documentation is subjected to management and peer review, accepted and in final form, and placed under configuration management control
2.All test plans and test cases are complete, subjected to management and peer review, accepted and in final form, and placed under configuration management control
3.All defects identified during unit testing have been fixed prior to integration and system testing or should be detailed in release notes
4.All necessary test environment hardware, software and test tools are complete and the staging environment is configured to appropriately mirror the production environment
Exit
The following are the requirements, which must be satisfied prior to formal exit
from system testing:
1.All test cases were successfully completed
2.Regression testing is complete and successful
3.All critical or major-priority defects are resolved and closed and all remaining open defects are reviewed by project team for potential impact, and formally waived or deferred as deemed appropriate
4..All test deliverables completed
Suspension criteria
The test cases for each level must be run successfully before the next level of testing begin. If an error is discovered, testing will be halted until the developers fix the error. Mention other situations when the testing may need to be halted.
Server is down and not responding Server is down and not responding
Home page is in accessible or will not load in browser
Major component of the site will not execute
Any critical defect is identified that will impede the execution of test cases
Staffing and Training Needs
Test Deliverable
Test plan
Test case documentation
Test Execution Report
Defect reports
Traceability matrix

Error, Bug, Defects ?

Error : Deviation for actual, the expected/theoritical value and also the syntax

Bug : An Error found in the product itself after it is shipped to the customer or may be some new failure encounter with manipulation of data.

Defect : An Error found in the development environment before the product is shipped to the customer
-----------------------------------------------------------------------------
Bug : Any discrepancy found during testing of software product.

Defect: Any discrepancy found by the customer in the software product after the release in to production
Error: Any discrepancy in the coding

What is Incident Report

Test Incident Report: detailing for any test that failed the actual versus expected result and other information intended to throw light on why a test has failed. This document is deliberately named as an incident report and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These include the expected results being wrong the test being run wrongly or inconsistency in the requirements meaning that more than one interpretation could be made. The report consists of all details of the incident such as actual and expected results when it failed and any supporting evidence that will help in its resolution. The report will also include if possible an assessment of the impact upon testing of an incident.