Software Development Life Cycle (SDLC) – Testing

Software Development Life Cycle – SDLC

What is software development life cycle?

SDLC or the Software Development Life Cycle is a process that produces software with the highest quality and lowest cost in the shortest time possible. SDLC provides a well-structured flow of phases that help an organization to quickly produce high-quality software which is well-tested and ready for production use.

Stage of Software Development Life Cycle (SDLC)

  1. Requirement analysis 
  2. Planning 
  3. Architectural design
  4.  Software development
  5. Testing
  6. Software deployment

Purpose of SDLC model

  • Lead to good software 
  • Reduce risk
  • Enable visibility and measurement
  • Enable teaming
  1. Requirement analysis
    In software engineering,requirements analysis focuses on the tasks that determine the needs for conditions to meet the new or altered product or project,taking account of the possibly conflicting requirements of the various stakeholders,analyzing, documenting,validating and managing software or system requirements.

Requirement analysis is critical to the success or failure of a system or software project.The requirements should be documented,actionable,measurable,testable,traceable,related to identified business needs or opportunities,and defined to a level of detail sufficient for system design.

2. Planning
Software manager is responsible for planning and scheduling project development. They manage the work to ensure that it is completed to the required standard. They monitor the progress to check that the event is on time and within budget. The project planning must incorporate the major issues like size and cost estimation scheduling, project monitoring, personnel selection evaluation and risk management. To plan a successful software project, we must understand.

  1. Scope of work to be completed
    2. Risk analysis
    3. The resources mandatory
    4. The project to be accomplished
    5. Record of being followed

Software project planning starts before technical work start.The various steps of planning activities are

3. Architectural Designing

 The design phase starts after requirement analysis and planning of the product. The main purpose of this phase is to design a suitable structure based on the SRS (Software requirement specification) the software architecture is derived from the SRS document. The architecture engineers design the software based on the SRS documentation.

4) Software development

 This phase is the actual implementation phase. After the completion of designing then developers write the code as per the requirements. Developers must follow the coding guidelines of their organization. Different high level languages are there for coding like java, python, c, c++ etc. Selection of language depends on the type of the software.

5)Testing

 After successful completion of coding it is checked whether the software is working as per the requirements or not.It make sure that the product is working as per the requirements.The testers expect to find any bugs are present in software before delivery to the client.This phase goes through different levels of functional and non-functional testing. 

6) Maintenance

After the final handover of the software, some up-gradation or changes are required from time to time to make it work flawlessly. If users face any issues with the software, it is resolved by the maintenance team.

How the SDLC Works

SDLC works by lowering the cost of software development while simultaneously improving quality and shortening production time. SDLC achieves these apparently divergent goals by following a plan that removes the typical pitfalls of software development projects. That plan starts by evaluating existing systems for deficiencies.

Next, it defines the requirements of the new system. It then creates the software through the stages of analysis, planning, design, development, testing, and deployment. By anticipating costly mistakes like failing to ask the end-user or client for feedback, SLDC can eliminate redundant rework and after-the-fact fixes.

It’s also important to know that there is a strong focus on the testing phase. As the SDLC is a repetitive methodology, you have to ensure code quality at every cycle. Many organizations tend to spend little effort on testing while a stronger focus on testing can save them a lot of rework, time, and money. Be smart and write the right types of tests.

How can DevSecOps be integrated into SDLC?

By following some best practices, DevSecOps can be integrated into SDLC in various ways.

  • Planning and Requirement Analysis: Here, security requirements and appropriate security choices that can mitigate potential threats and vulnerabilities are identified in this stage. What security design principles and best practices to be used are also thought about here.
  • Architectural Design: The development team uses the security design principle and architecture to consider potential risks. This stage involves threat modeling, access control, encryption mechanism, and architecture risk analysis.
  • Software Development and Testing: The code reviews are done to ensure software follows code standards and security controls are implemented. Security vulnerability tests like penetration testing are also done to identify potential issues.
  • Deployment: Automated DevSecOps tools are used to improve application security. To ensure the software is deployed securely, firewalls, access controls, and security settings are configured.
  • Maintenance: Security continues after deployment. The team must continuously monitor the software for security vulnerabilities. The team would also update the software with security patches and updates as necessary.

Posted by

Akshay Baratagi

Test Engineer

Writing Efficient Test Case: A Test Case Template Example

A Test Case Template Example

Test case template: A template is a structural document and a test case template contains all information required for a test case. Every test engineer will write test cases in test case template, there is nothing called standard test case template. It may vary from company to company and project to project.

It mainly contains the following XLS sheets

  1. HLS Revision History – For High Level Scenario
    HLS- Test Scenario Revision
     HLS- Test Scenario Revision
  2. HLS Scenarios
    HLS-High Level Test Scenario
      HLS-High Level Test Scenario
  3. HLS Review Comments
    HLS Review_Comments_Test_Case
     HLS Review_Comments_Test_Case
  4. LLS
    HLS-High Level Test Scenario_test_case
    HLS-High Level Test Scenario_test_case

 

Test case parameters

Header

Test case name:It is a unique name written by test engineer.For every individual test engineer individual  test case name should be written in the below mentioned format.

ProjectName_ModuleName_Scenario

Release name: It is mandatory to mention release name because it helps to identify in which build the issue has been raised.

Requirement number: When BA(Business Analyst) write the requirement number for every individual requirement and  unique number will be given to each requirement, so test engineer should copy the requirement number and should write the test case template.

Module name: When BA(Business Analyst) write the requirement, he will also write list of all the module names so test engineer should copy the module name from the requirement and should write the test cases.

Precondition: It is the settings or actions that should be done before executing test cases or step no 1.

Test dataIt is a data created by test engineer before executing test case or step no 1.

       Example for test data : It is required to create an user account before testing file upload feature.

Test data can be created manually or we can also create test data by executing automation scripts.

Post condition:It is an expected result that we get from the application or when we give the input to the application what ever output we get from the application that is called as post condition.

We mainly use post data when one of the test case is depending on the output of previous test case.

Severity:Test engineer should give severity for each and every individual test cases based on complexity of the feature and importance of feature and importance of feature to the customer business, based on severity test engineer will decide which test cases should be executed first and which test cases executed next.

3 types of severity

1)  Critical

2)  Major

3)  Minor

Test case type: Test engineer should mention which type of testing he is writing in the test case type.

Functional testing

Integration testing

System testing

Smoke testing

Brief description:This field describe the complete information about  the test case

Test execution hours:Test engineer should mention how much time he has taken to write and execute the test case ,the value for this field should be enter once of after test execution.

Body

Step no:This field is mainly use to identify each and every step uniquely.

Action or description:It consists of all the navigation steps.

Input:This field consist of the values entered by test engineer while testing the application (URL,Username,password and all  +ve  and  -ve value you entered for every field)

Expected Result:Test engineer will write Expected result by looking in to the requirement the value for this field is entered before test execution.

Actual Result:Test engineer will write actual result while executing the test cases execution. Test engineer will get the actual result from the application.

Status:Test engineer will enter the status of test case as pass or fail after test execution. if expected result is not matching with actual result than test case status  is fail else it is pass.

Comments:If the test case is fail then test engineer should enter the reason in the comments stating why the test case is failed.

Footer

Author:Test engineer one who write the test case is called as author.

Reviewer or reviewed by:Test engineer one who reviews the test case which is written by other test engineer is called as reviewer.

Approved by:Test engineer one who approves the test case is called as approved by or approver.

Approval date:The date on which test case is approved is called date.

Download Test Case Template XLS file

Important : Learn  to use JIRA bug tracking tool

Posted By

Vinayak Mudiyappanavar,

Trainee Test Engineer

                                                                                                                                                                       

What are test cases, test scenario and Advantages of writing test cases

What is test case:

Test case is a document which gives all possible scenarios for one particular requirement. Ideally a test case document contains set of test data like preconditions,post conditions, actual results and expected results.

Test Scenario : Is a any functionality or a test condition or a test possibility.

Software Testing Life cycle:

Software Testing Life Cycle

Why to write test case: 

Test Coverage : Test coverage is a measure of testing and to have better test coverage it is required to write all the tested cases for identified scenario. Ideally the following process will be in action.

  1. Customer will give requirement to developer.
  2. Test engineer has to spend enough time to understand the requirement 
  3. Test engineer has to identify all possible scenarios
  4. Test engineer has to write test cases for all identified scenarios.

What are benefits of writing test cases:

  1. Better Consistency :  When test cases are written for a test execution, the test engineer work will be organised better and simplified. Let us consider a scenario as an example.

When a release1.0 is being tested using existing test cases, the same test cases can be quickly executed for the next release 1.0.1, having test cases helps to identify issues which impacting the old release, this way we can achieve better consistency in test execution.

2. Avoid training : To avoid training every new test engineer on the product or requirement. Consider the following situation.

  • Test Engineer write test cases.
  • Test engineer quits the job
  • New test engineer joins

It takes lot of effort to explain every module and it takes lot of time for new tester to understand the complete requirement.

  • But if we write test cases in the beginning, then the newly joined test engineer can test application by looking in to test cases on his own.
  • Here its not necessary to train him on requirement because, if he execute test cases for couple of release on test cycles he can understand the product.

3. No dependency : To depend on process rather than person. Every company will set their own process

EX: when we get the requirement test engineer should do follow the process.

Understand requirement

identify all scenarios and document.

Prepare a test cases for each scenarios and document.

This process of documenting each and everything will remove the dependency on a person

4. Writing test cases will keep track of all the steps for a particular scenario, this is very important because complicated steps to test a scenario might be difficult to remember always.

    Let us consider an example :

          Assume that an UI distortion issue will be produced by following steps in a particular scenario

Step1 : Login into Chrome browser ( Hard to remember the platform some times, issue is only in Chrome)

Step 2: Navigate to Home page 

Step 3: Select profile from menu in the header

Step 4: Edit First name and Last Name details by giving big string

Step 5: Go back to Home page

Step 6: Navigate to Events page ( only navigating to events page will reproduce the issue)

Step 7: Go back to Home page, the header will shift 100px down leaving black pack at the top

Assuming these steps were not recorded in test cases, when build release 1.0 is given, it is hard to reproduce the same issue again quickly. 

If test cases have written, test engineer can easily follow the steps to reproduce and test the issue.

5. Test cases will ensure that complete functional and non functional testing will be done and hence test cases will give complete list of all scenarios to meet the software product quality expectations.

6. The main objective of test case is to exercise every flow in application.

7. To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications.

8. Test cases will ensure that every functionality working as expected in every possible scenario.

9. Test cases will ensure that all the requirements have been met as per the customer requirement document.

Check an example for Test Case Template

IMPORTANT : LEARN  TO USE JIRA BUG TRACKING 

Posted By

Vinayak Mudiyappanavar,

Trainee Test Engineer