Softforce Apps

Freshers/Exp Walk-in For PHP Developer/Software Engineer @ "Softforce Apps" in Hyderabad

Company Name: Softforce Apps
 

Job Details:

Education: Any Graduate

Experience: 0 - 3 years

Job Location: Hyderabad

Walk-in on 14th Nov to 10th Dec 2015 from 9:00 AM @ Hyderabad

Job Description:
PHP DeveloperCandidate should possess a Graduates in any discipline

1 – 3Yrs Hands on experience on PHP/MySQL/Yii/Joomla

Web application development using LAMP (Linux/Apache/ MySQL/PHP/Perl)  &

WAMP (Windows/Apache/ MySQL/PHP/Perl)

Must have experience on any one of the MVC Frameworks like Yii/Zend/

Codeignitor/CakePHP/ Joomla

Must have Experience with Javascript and Javascript Frameworks like JQuery

Must have Knowledge of AJAX / XML/JSON

Web Services experience is a plus

Must have excellent written and oral communication skillsPHP Developer
Candidate should possess a Graduates in any discipline0-2 Yrs Experience

Good knowledge on Must have strong problem-solving /analytical skills

Good communication skills

Able to multi-task and work with several different projects at the same time

Walk-in Address:

Softforce Apps

Hyderabad,

Email-Id: jobs@softforceapps.com

Read More

Xerox Business Services India Private Limited

Freshers/Exp Walk-in For Associate @ "Xerox" in Noida

Company Name: Xerox Business Services India Private Limited
 

Job Details:

Education: BBA/B.Sc/B.Com/MBA

Experience: 0 - 1 years

Job Location: Noida

Walk-in on 13th Nov 2015 from 11:30 AM - 2:00 PM @ Noida

Job Description:
AssociateCandidate Must be a graduate-BBA / BSc /B.Com/MBA (correspondence)

Flexible to work in Shifts.

Should have good communication skills.

Should have good hold on mathematics or must be good in calculation.

NOT ELIGIBLE - BTech, MTech, BE, MCA, MBA (Regular course)
Walk-in Address:

Xerox Business Services of India Pvt. Ltd,

1st Floor Tower A&B , Knowledge Boulevard,

Plot 8 , Block-A , Sector 62 , Noida ,

Contact Name: Renu Arora

Read More

What is SDLC

SDLC - Software Development Life Cycle

Software products, which don’t happen to be user friendly just, don’t find any place in a highly competitive market of this modern era, although they might have been developed with the help of the best available technology. The ease of use of the product is of paramount importance compared to its internal technology, which the customer is not going to see.

Thus for the creation of Innovative Software products, the Development Life Cycle undergoes six phases like:

1) Initial Phase
2) Analysis Phase
3) Design phase
4) Coding Phase
5) Testing Phase
6) Delivery and Maintenance phase
Phase – 1: Initial Phase: Involves Interaction with the customer and capturing all the requirements.
Personnel Involved: 1) Business Annalist – BA & 2) Engagement Manager - EM
Process Involved: This phase begins with a technical meeting between the Business Analyst & the customer. The Business Analyst (BM) understands all the requirements from the customer & prepares comprehensive requirements document with the help of standard templates & check sheets used by the company. The requirements document forms the basis for further study & action by the Engagement Manager (EM).

The Engagement Manager tries to hunt for extra requirements if any, which might not be apparent immediately but might involve extra cost. To resolve ambiguous requirements if any, the Engagement Manager organizes demonstration of a prototype if necessary. Such action of quick demonstration of a prototype, which is nothing but a rapidly developed model for the customer is found extremely helpful to remove ambiguities from the requirements on one hand & help winning the confidence of the customer on the other.

Ultimate objective of this phase is to prepare a most comprehensive customer requirements document. Many companies call it with different names like:
# BRS: Business Requirement Specification.
# FRS: Functional Requirement Specification.
# URS: User Requirement Specification.
# CRS: Client / Customer Requirement Specification.
# BDD: Business Design Document.
# BD  : Business Document.
Depending upon the system followed by various companies, sometimes a single document is maintained, while some companies may go in for two documents. In this case, Broad / outlining information is recorded in the BRS (Business Requirement Specification), while detailed information is recorded in FRS (Functional Requirement Specification).
                                   
Phase – 2: Analysis Phase: Involves Feasibility Study, Broad Planning, Technology selection, Requirement analysis etc.
Personnel Involved: 1) System Annalist – SA, 2) Project Manager – PM & 3) Team Manager -TM

Process Involved: To understand the nature of the program to be developed, the System Annalist focuses on understanding the information domain of the software, its necessary functions, behaviors, performance and necessary interfaces etc. The major objective of the analysis phase is to find out the need and to define the problem, which needs to be solved.
The process covers four distinct analytical operations like:
1) Feasibility Study: Involves detailed study of all the requirements to ascertain as to whether it is possible to meet all the requirements or not. There may be a need for the development team to visit the customer place for study of their system. They development team may investigate the need for possible software automation within the boundaries of the given system.
2) Broad Planning: Involves an outline document on planning of all resource and time wise planning.
3) Technology Selection: Involves identification, analysis & compilation of various tools & technologies, which would be needed to accomplish the project successfully.
4) Requirement analysis: Involves identification & compilation of various requirements of human resources, hardware & software, which would be needed to accomplish the project successfully.
Ultimate objective of this phase is to prepare a most comprehensive document called SRC or Software Requirement Specification.

Phase – 3: Design Phase: Involves hard core design activities like 1) HLD - High Level Designing & 2) LLD - Low Level Designing
Personnel Involved: 1) Chief Architect – CA is responsible for High Level Designing, 2) Technical Lead – TL is responsible for Low Level Designing

Process Involved: The Chief Architect – CA, starts The entire designing process. This involves subdivision of the entire project into various modules & the process is adequately explained with the help of flow charts & diagrams. Thereafter, the Technical Lead – TL further subdivides these main Modules into sub modules with the help of Unified Modeling Language - UML. The technical lead is responsible for creating the Pseudo Code which is a comprehensive set of instructions written in English language & are meant for guiding the actual code developers.

Ultimate objective of this phase is to prepare a Technical Design Document - TDD.

Phase – 4: Coding Phase: Involves actual Programming or Coding.

Personnel Involved: Code Developers or Programmers

Process Involved: The design needs to be translated into a machine-readable form. There comes the process of code generation. With the help of Pseudo Code written by the Technical Lead – TL during the Design Phase, Developers carry out the development of the actual source code. The entire coding process is bound by stipulated coding standards defined by the company.

Ultimate objective of this phase is to prepare a Source Code Document - SCD.

Phase – 5: Testing Phase: Involves rigorous testing of the application developed by the programmers.

Personnel Involved: Testing Engineers.

Process Involved: Different testing methodologies are practiced to detect the software bugs, which happen to take birth during the previous phases. Various testing tools and methodologies are available these days. Some companies create their own testing tools, which are custom made to suit their own development functions.

# In fact the testing process begins right from the customer requirement document. A good test engineer starts his work by thorough study of the requirement document. In case of any doubt arising during understanding of customer requirements, the test engineer raises a Review Report –RR, which contains details of all the doubts.

# Having clarified all the doubts & ambiguities, and after having a thorough understanding of the requirements, the test engineer shall write the test cases with the help of company specific test case templates.
# Execution of the test cases upon the release of the first build by the developers. This follows recording of defects in a defect profile document.
# The defect profile document is transferred to the developers for improvements / eradication of defects found by them. The testing process halts here till next build with improvements is released by the developers.
# The entire testing process involving execution of test cases is repeated on the new build. This process of code improvement, subsequent testing on new builds & finding of defects continues again and again till the product is free from defects.
# The testing process is decided to be stopped after gaining reasonable confidence of product being defect free
Ultimate objective of this phase is to produce a Quality Product.

Phase – 6: Delivery and Maintenance phase: Involves Installing the newly developed application under the client environment.

Personnel Involved: Senior Testing Engineers who are entrusted the task of Deployment Engineers.
Process Involved:
# Delivery: After the code is appropriately tested, it is approved for release, it is deployed into a production environment. The deployment of application is done with the help of guidelines provided in the application deployment document.

# Maintenance: After the deployment of the application, client may encounter many task-based problems.

Maintaining and enhancing the software to cope up with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add some code, which does not fit the original design to correct an unforeseen problem. It may be that the customer is requesting more functionality, and some code can be added to take care of his requests. 

Read More

What is STLC

STLC - Software Testing Life Cycle

There is a systematic cycle to software testing, although it varies from organization to organization
Software Testing Life Cycle:
Software testing life cycle or STLC refers to a comprehensive group of testing related actions specifying details of every action along with the specification of the best time to perform such actions. There can not be a standardized testing process across various organizations, however every organization involved in software development business, defines & follows some sort of testing life cycle.
STLC by & large comprises of following Six Sequential Phases:
1) Planning of Tests
2) Analysis of Tests
3) Designing of Tests
4) Creation & Verification of Tests
5) Execution of Testing Cycles
6) Performance Testing, Documentation
7) Actions after Implementation
Every company follows its own software testing life cycle to suit its own requirements, culture & available resources. The software testing life cycle can’t be viewed in isolation, rather it interacts with the every phase of Software Development Life Cycle (SDLC). Prime focus of the software testing life cycle is on managing & controlling all activities of software testing. Testing might be manual testing or an automated testing using some tool.
1) Planning of Tests:
In this phase a senior person like the project manager plans & identifies all the areas where testing efforts need to be applied, while operating within the boundaries of constraints like resources & budget. Unless judicious planning is done in the beginning, the result can be catastrophic with emergence of a poor quality product, dissatisfying the ultimate customer. Planning is not limited just to the initial phase, rather it is a continuous exercise extending till the end.
During the planning stage, the team of senior level persons comes out with an outline of Testing Plan at High Level. The High Level Test Plan comprehensively describes the following:

• Scope of Testing : Defining the areas to be tested, identification of features to be covered during testing
• Identification of Approaches for Testing: Identification of approaches including types of testing
• Defining Risks: Identification of different types of risks involved with the decided plan
• Identification of resources : Identification of resources like man, materials & machines which need to be deployed during Testing
• Time schedule: For performing the decided testing is aimed to deliver the end product as per the commitment made to the customer.
  
  Involvement of software testers begins in the planning phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests will work.

2) Analysis of Tests:
Based upon the High Level Test Plan Document, further nitty-gritty’s covering the following are worked out.

• Identification of Types of Testing to be performed during various stages of Software Development Life Cycle.
• Identification of extent to which automation needs to be done.
• Identification of the time at which automation is to be carried out.
• Identification of documentation required for automated testing

The Software project can’t be successful unless there is frequent interaction among various teams involved in Coding & Testing with the active involvement of the Project Managers, Business Analysts or even the customer. Any deficiencies in the decided test plans come to the surface, during such meetings of cross-functional teams. This provides an opportunity to have a rethinking & refining the strategies decided for testing.

Based upon the customer requirements a detailed matrix for functional validation is prepared to cover the following areas:

• Ensure that each & every business requirement is getting covered through some test case or the other.
• Identification of the test cases best suited to the automated testing

• Identification of the areas to covered for performance testing and stress testing
• Carry out detailed review of documentation covering areas like Customer Requirements, Product Features & Specifications and Functional Design etc.

3) Designing of Tests:
This phase involves the following:

• Further polishing of various Test Cases, Test Plans
• Revision & finalization of Matrix for Functional Validation.
• Finalization of risk assessment methodologies.
• In case line of automation is to be adopted, identification of test cases suitable for automation.
• Creation of scripts for Test cases decided for automation.
• Preparation of test data.
• Establishing Unit testing Standards including defining acceptance criteria
• Revision & finalization of testing environment.

4) Construction and verification:
This phase involves the following:

• Finalization of test plans and test cases
• Completion of script creation for test cased decided for automation.
• Completion of test plans for Performance testing & Stress testing.
• Providing technical support to the code developers in their effort directed towards unit testing.
• Bug logging in bug repository & preparation of detailed bug report.
• Performing Integration testing followed by reporting of defects detected if any.

5) Execution of Testing Cycles:
This phase involves the following:

• Completion of test cycles by executing all the test cases till a predefined stage reaches or a stage of no detection of any more errors reach.
• This is an iterative process involving execution of Test Cases, Detection of Bugs, Bug Reporting, Modification of test cases if felt necessary, Fixing of bugs by the developers & finally repeating the testing cycles.

6) Performance Testing, Documentation & Actions after Implementation:
This phase involves the following:

• Execution of test cases pertaining to performance testing & stress testing.
• Revision & finalization of test documentation
• Performing Acceptance testing, load testing followed by recovery testing
• Verification of the software application by simulating conditions of actual usage.

7) Actions after Implementation:
This phase involves the following:

• Evaluation of the entire process of testing.
• Documentation of TGR (Things Gone Right) & TGW (Things Gone Wrong) reports. Identification of approaches to be followed in the event of occurrence of similar defects & problems in the future.
• Creation of comprehensive plans with a view to refine the process of Testing.
• Identification & fixing of newly cropped up errors on continuous basis.

Winding up of the test environment & restoration of all test equipment to the original base line conditions.

Life Cycle of Software Testing ( STLC )
Phase	Activities	Outcome
Planning of Tests	($) Creation of a Test Plan of High Level	Refined Test Plans & Specifications
Analysis of Tests	($) Creation of fully descriptive Test Plan ($) Creation of Matrix for Functional Validation ($) Creation of Test Cases	Refined Test Plans, Test Cases & Matrix for Functional Validation
Designing of Tests	($) Revision of Test Cases ($) Selection of Test Cases fit for automation	Refined Test Cases, Input Data Sets & Documents for Assessment of Risk
Creation & Verification of Tests	($) Creation of scripts suitable for Test Cases for automation	Detailed Procedures for Testing, Testing Scripts, Test Reports & Bug-Reports
Execution of Testing Cycles	($) Completion of Cycles of Testing	Detailed Test Reports & Bug-Reports.
Performance Testing, Documentation	($) Execution of Test Cases related to performance tests & Stress Testing ($) Detailed documentation	Test Reports, Documentation on various metrics used during testing
Actions after Implementation	($) Evaluation of all Processes of Testing	Detailed Plans for improving the process of testing

Read More

Difference between STLC & SDLC

Difference between STLC & SDLC

STLC means "Software Testing Life Cycle".

It involves following stages
1) Preparation of the test strategy
2) Preparation of the test plan
3) Creation of the test environment
4) Writing of the test cases
5) Creation of the test scripts
6) Execution of the test scripts
7) Analysis of the test results
8) Reporting of the bugs
9) Performing regression testing

SDLC means "Software or System Development Life Cycle".

It involves following stages
1) Initiation of the Project
2) Collection of Requirements and Documentation
3) Designing
4) Coding and unit testing
5) Integration testing
6) System testing
7) Installation and acceptance testing

8) Support or maintenance 

Read More

Bug or defect life cycle includes following steps or status:

Bug or defect life cycle includes following steps or status:

·          New:  When a defect is logged and posted for the first time. It’s state is given as new.

·          Assigned:  After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.

·          Open:  At  this state the developer has started analyzing and working on the defect fix.

·          Fixed:  When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

·          Pending retest:  After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.

·          Retest:  At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.

·          Verified:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.

·          Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.

·          Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.

·          Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.

·          Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.

·          Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 

·          Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.

Read More

Failure in software testing

If under certain environment and situation defects in the application or product get executed then the system will produce the wrong results causing a failure.

Not all defects result in failures, some may stay inactive in the code and we may never notice them. Example:  Defects in dead code will never result in failures.

It is not just defects that give rise to failure. Failures can also be caused because of the other reasons also like:

·          Because of the environmental conditions as well like a radiation burst, a strong magnetic field, electronic field or pollution could cause faults in hardware or firmware. Those faults might prevent or change the execution of software.

·          Failures may also arise because of human error in interacting with the software, perhaps a wrong input value being entered or an output being misinterpreted.

·          Finally failures may also be caused by someone deliberately trying to cause a failure in the system.

Read More

Factors which affect the test effort

The factors which affect the test effort are:

§  While good project documentation is a positive factor, it’s also true that having to produce detailed documentation, such as meticulously specified test cases, results in delays. During test execution, having to maintain such detailed documentation requires lots of effort, as does working with fragile test data that must be maintained or restored frequently during testing.

§  Increasing the size of the product leads to increases in the size of the project and the project team. Increases in the project and project team increases the difficulty of predicting and managing them. This leads to the disproportionate rate of collapse of large projects.

§  The life cycle itself is an influential process factor, as the V-model tends to be more fragile in the face of late change while incremental models tend to have high regression testing costs.

§  Process maturity, including test process maturity, is another factor, especially the implication that mature processes involve carefully managing change in the middle and end of the project, which reduces test execution cost.

§  Time pressure is another factor to be considered. Pressure should not be an excuse to take unwarranted risks. However, it is a reason to make careful, considered decisions and to plan and re-plan intelligently throughout the process.

§  People execute the process, and people factors are as important or more important than any other. Important people factors include the skills of the individuals and the team as a whole, and the alignment of those skills with the project’s needs. It is true that there are many troubling things about a project but an excellent team can often make good things happen on the project and in testing.

§  Since a project team is a team, solid relationships, reliable execution of agreed-upon commitments and responsibilities and a determination to work together towards a common goal are important. This is especially important for testing, where so much of what we test, use, and produce either comes from, relies upon or goes to people outside the testing group. Because of the importance of trusting relationships and the lengthy learning curves involved in software and system engineering, the stability of the project team is an important people factor, too.

§  The test results themselves are important in the total amount of test effort during test execution. The delivery of good-quality software at the start of test execution and quick, solid defect fixes during test execution prevents delays in the test execution process. A defect, once identified, should not have to go through multiple cycles of fix/retest/re-open, at least not if the initial estimate is going to be held to.

Read More