>> Agile/Scrum methodology

Agile/Scrum methodology

It is a software development methodology in which the different phases of software development life cycle happen in parallel ,  producing a product better and faster.

Sprint :

It a time span for one cycle of software development. It is in general 1 week to 4 weeks long. A project consists of 1 or more than one sprints.  A sprint has selected or prioritized user stories from product backlog . A project backlog is divided into several sprints and each sprint goes through the same cycle of software development , producing a potentially shippable product at the end.

Roles in Scrum:

Product Owner: He is the person to come up with the idea of the product and he defines the features of the product based on the feedback from stakeholders and end users(clients).  The clients/stakeholders come up with the user stories( user stories are the client's expected features those they want to include into the product.) and the product owner decides which user stories to be included into the product backlog.

Scrum Master: He is the leader of the scrum team. He is responsible for maintaining the software development process. He conducts meetings , monitors the progress and  manages the team.

Team :  It is the group of people with different roles (such as developers, testers) who contribute to develop the product.

Documents  or  Artifacts :

User Stories:  User stories are the list of user/client expectations ie what features the client want to include in the product or what features the client expect from the product. The scrum team works on the user stories included in the sprint. Based on the priority , the user stories are selected for any particular sprint.

Product backlog: This is a document created by product owner . This document is  the list of all the user stories. As per the priority the user stories are implemented in the particular sprints ie goes into the particular sprint backlog. Project backlog is the master document , sprint backlog is the document for the particular sprint.

Burndown chart: It is a chart showing the progress in the sprint, remaining works(Hours) vs time(Days). It shows the daily work progress.  At the end of a well managed/operated sprint, the work remaining should be zero.  The straight line representing the slope of the graph is called Burndown velocity which shows the daily progress or the overall progress of the sprint or team's velocity . This graph helps to monitor  if the progress is happening at the expected speed or not. If the progress is slower than expected,  then we can take the appropriate action to complete the sprint in time.

Meetings:

Sprint planning meeting: In sprint planning meeting the Product owner, scrum master and the team meet and discuss on the user stories . From this meeting they estimates the size of the user stories ie the amount of work to be done in terms of hours. Based on the size, they decide which  user stories are to be added into the particular sprint , ie, into the particular sprint backlog.

Daily Scrum or Daily Standup meeting: This is a daily meeting for about 15 minutes , everybody standing to discuss what they have done since the last scrum meeting, what they are working on right now and if there is any difficulties, issues or blockades.

Sprint Review: This meeting happens at the end of the sprint. In this , the team , the product owner , stakeholders discuss about the product of the sprint. They discuss about what is achieved or developed. 

Retrospective : This meeting also happens at the end of the sprint. In this , the team discuss what went right or wrong , what lesson is learnt , what can be done to improve the process or what can be improved.

Potentially shippable Product : This is the outcome or end product of any sprint.

Advantages of Agile Methodology:

1. There is constant communication  of developers, testers and the customer throughout the software development lifecycle. So customer can review the product and suggest anything anytime.

2.Team can reach out to the customer whenever required as there is extensive involvement of the customer.

3. The software is developed fast and customers are happy as they are reviewing the development process constantly.

4. The feedback from the customer is quick.

5. There is freedom for the team and the stakeholders to make decision or apply any changes . They can wait and apply the changes in later sprints/releases if they need to wait for the availability of right environment, data , software etc.

6. Customer can get fast and frequent delivery , so that customer can add or customize or change the scope of the project or the requirement as required and when required.

7. Regular communication and daily progress updating/meeting help understand each member's status in his work and the difficulties if any .

8. The Sprint review meeting and the retrospective  at the end  of the sprint help understand the achievement , challenges  and the experience from the previous sprint helps to improve the in the next sprints.

 Disadvantages of Agile Methodology:

1. There is a fast-paced work environment. The team members have to act fast , understand the requirements and the changes in the requirements.

2. Developers, Testers and customers must be communicating with each other, so it needs more time and efforts.

3. Team members have to work on task on short notice which adds probability of the project getting off the track or misunderstanding in the development.

3.  There is loss of time , effort and resources which impact the deadline in below situations:

Customer is not sure about the requirement or  

Customer's feedback is  not understood  or

The communication is not in time or

Requirement is not understood or misunderstood .

4.  It is easy to maintain the progress with experienced team , adjusting new team member  might be difficult.

5. Documents might not be in detail and might be frequently changing , so it is difficult for the new team members to pick up.

6. There is possibility of frequent changes in requirements , team should be prepared and able to manage the changes.

7. This does not need detail planning or understanding of the full scope of the project  to start unlike waterfall methodology . So the progress depends on the  frequent feedback and continuous communication. The team and the customers should maintain good communication all the time.

8. Sometimes  there might not be enough documentation or the required amount of details.   And the team has to depend on the verbal communications .

>> SDLC ( Software Development Life Cycle ) & Waterfall Methodology

SDLC - Software Development Life Cycle

SDLC is graphical representation of different stages/phases of a software development process.  The different stages are : Planning , Analysis , Design, Development , Testing, Implementation, Maintenance

Depending upon the nature of projects , the a SDLC might go through different phases . However, these are the main phases that almost all the software development projects go through.

Planning: It is the first step. Client first gets the idea and starts making plan for it.  Planning involves the feasibility analysis of the project including the cost, time, resources etc based on the inputs from the different departments , survey, past experiences. Highly skilled members are involved in this phase. Basically, they determine what they want at this phase. How they achieve is discussed later phases.

Analysis :  In this phase, the plan is further analyzed with the subject matter experts(SME) . They come up with a detail documentation and business logic  for the project.

Design:  In this phase , product architect are involved in proposing  different approaches. Based on the selection criteria, the best design is  picked. They come up with the technical approach about implementing the design.

Development : Developers are involved in this phase in which the design is converted to the codes.  The development is done selecting a suitable programming language, hardware, software. The end result is defect free product as expected by the client.

Testing : It is the most important phase. In this the developed product is testing using different testing approaches. If defects are found then they are reported and are fixed. In this phase all the issues that might be existing in the product are captured and reported which are fixed to make the defect free product , meeting the expected standard.

Deployment:  The product at this phase is deployed to the real market(called going live). At first the deployment might be limited only however, based on the feedback and adjustment, they are fully released to the market.

Maintenance and Support: This  is maintaining and monitoring of the software performance and customer feed back . If any issue or defects are noticed, they should be rapidly and properly addressed. This phase is also to know if any improvements in the product is required. They maintain and support the application to keep it functional.


Waterfall Methodology:

In software development, two most common methodologies are : Waterfall and Agile. Agile methodology has been discussed in different chapter (click here to go to Agile Methodology).

In waterfall methodology, above mentioned software development phases(SDLC phases) occurs phasewise ie second phase starts after first phase is completed and third phase starts after completion of second phase and so on.

>> Test Plan , Test Cases, RTM (Requirement Traceability Matrix)

Test Plan


To watch in YouTube , click here : Test Plan in Software Testing

Test Plan is a detailed document about the testing process to be carried out. It includes the detail information about estimation , activities, resources and schedule etc. The various information included in a test plan are discussed below. Test Plan is prepared by Test Lead or Test Manager or Testers.

Types of Test plan :

1. Master Test Plan -- This is a top level test plan document for the testing process. Other individual test plans(supporting test plans) are part of this major test plan.

2. Supporting Test Plan -- To carry out complete software testing, the process goes through different level or types of testing  such as Unit Testing , Integration Testing, Regression Testing,  User Acceptance Testing etc. Supporting test plans are created for these individual testing processes. These test plans are part of the Master Test Plan.

A Test Plan includes below information:

1. Objectives
2. Approach
3. Resources
4. Software
5. Hardware
6. Environments
7. Test Schedule
8. Deliverables
9. Responsibilities
10. Features to be tested
11. Features not to be tested
12. Entry and Exit criteria
13. Risks and contingencies
14. Pass Fail criteria
15. Estimation of time / cost
16. Assumptions and Dependencies
17. Approval Criteria

Objectives:
This talks about the objectives , the goal of the testing.

Approach:
It defines the testing steps, methods, types, testing process or techniques.

Resources:
This talks about the resources required in terms of technical skills, number of resources , team structure, size etc.

Software:
This talks about the software or application , database , web services, network configurations , operating systems etc required for testing.

Hardware:
This talks about the required hardware , machines , Virtual machines etc.

Environments:
This talks about the number of testing environments required for the testing. Because we might require more than one testing environments based on functionalities purposes and properties.

Test Schedule:
This talks about the test schedule,  how much time we have, when we  will start and complete the testing.

Deliverables:
These are test documents or reports or other testing artifacts which testing team gives to the stakeholders. The artifacts are given before the testing , during the testing and after the testing.

Responsibilities:
It defines the roles and responsibilities of the team members.

Features to be Tested:
It is the scope of testing. It defines the list of the features, of the software or the  product,  which are in scope. They will be be tested.

Features not to be Tested;
This also talks about the scope of the testing. It defines the list of features of the software or product which are out of scope of the testing. They will not be tested.

Entry and Exit Criteria:
Entry Criteria defines the conditions or requirements to be fulfilled before starting the testing. Such as availability of all software , access , test data, test environment being up and running etc.
Exit Criteria defines the conditions or requirements to be fulfilled before declaring the test as completed. Such as deadlines, coverage of requirements and functionalities , no defects left etc.

Risks and contingencies:
Every project is associated with some risks, you should be ready for possible risks and should have proper solution plan for them. The common risks are: lack of resources, lack of software or hardware , lack of skill , late delivery of the code, change in the requirement, risk of budge/cost or time etc.
When the risk takes place, then you should come up with the appropriate solution. Some common actions for the risks are : shifting the delivery date(this is not recommended though) , changing(usually reducing the functionalities for testing ) the scope of testing, adding resources etc. For the kind of risk, if appears, whichever step is most appropriate , that step will be taken.

Pass Fail criteria:
It is a minimum standard or criteria for completing the test. To mark the test as PASSED, the criteria should be fulfilled. Such as , the product should be defect free or sometimes it will be acceptable with minor defects. This does not talk about individual test result, it talks about the testing of the overall product or software under test.

Estimation of time / cost:
Time : It talks about the time required to complete the testing , in other word, the deadline to complete testing.
Cost : It is the budget for the testing.

Assumptions and Dependencies:
It is part of risk management. The risks are future unexpected events which might occur. So, you make proper assumptions based on your experience and information.
The testing activities might be dependent to each other and other factors. You have to prioritize and carryout  the testing activities accordingly.

Approval Criteria:
You will need approval of the test plan and other deliverables at different stages of testing(before testing, during testing, after completing the testing). The client or stakeholders can approve the test plan or the deliverables. You take the approvers' name , role, signature and approval date.

Test case:

A test case is a set of steps to carry out a specific scenario or case or condition. A test case mainly has test case ID, Description about the Test case, Test steps , Expected result, Actual result, Testing status.  Depending upon a tester , a test case can be long or short, and Test case number also varies. If you include more functionalities in a single Test case then the Test case will have more steps and the number of test cases will be few. If you write separate test cases for each functionality , then each test case will have few steps and the number of test cases will be many. So it depends upon the tester how he wants to write test case. In what ever way you write the test case , the requirement (or functionalities to be tested) should be fully covered.  If the test case is dependent on other test case or something else, then that condition should be mentioned as "Pre Condition" in the test case.

A test case is considered pass when all the steps in it pass. If any step or steps fail then the test case is considered as fail.  If the test case fails, then we need to log/create defect for the failure and the defect can be associated/linked with the test case. The status of a test case can be PASS, FAIL, ON HOLD, BLOCKED, UNTESTED etc.

Sample Test case format:
Depending upon the project type and project needs , the format might be slightly different. However, below format includes the most common test case components. As per your project need, the admin of  your test management tool , will add or remove the fields or customize them .

Requirement Traceability Matrix:

It is a job of a tester to acquire the business requirements( or design document or FDD or mapping document or user stories) . After getting the business requirement document , a tester needs to convert the requirement to test cases which is later tested whenever the code/software is ready for testing. While converting the requirements to test cases, we need to make sure that everything in the requirements have been covered. To make sure that all the requirements have been covered , a matrix is created for the requirements vs test cases.  This gives clarity that all the requirements have been covered ( which will be tested ). This matrix is called Requirement Traceability Matrix or RTM . If any piece of requirement is not covered , it becomes easily visible in the RTM.

>> Software Testing

Software Testing:

Software testing is the process to make sure that the software or application under test is working as per the design/expectation.  The purpose of any kind of testing is to make it defect free.

The software or application is developed as per the design or requirement . In IT  projects, in most of the situations ,  the design or requirement is provided to testing team by Business Analyst . The design is called Business Requirement Document or BRD. Another forms of design document could be functional design document (FDD) or mapping document or User Stories. Based on these document/s , a tester has to write Test cases and/or conduct the testing activities.

Types of Testings:

1. Functional Testing

2. Non-Functional Testing

1. Functional Testings

1.1 Smoke Testing:

This is the first testing after any build or release is ready to be tested. This covers the overall basic functionalities. It does not cover the deep testing of any particular functionality or scenario. It is to make sure that the basic things are working in that  build or release. It is generally one or two Test cases covering basic functionalities.

1.2 Integration Testing:

In this all the components to be tested are combined as a group and testing is conducted. This testing covers the testing of overall components/modules of the software. There are two approaches  in integration Testing.

Top Down and Button Up

1.2.1 Top Down

In this testing , the top  level modules or components are tested first . The testing moves from the higher  level components to the lower level components.  If any lower level component is not present then temporary module called STUB  is created and the testing is carried out. The STUB should give the same output as expected from the actual module.

1.2.2 Buttom Up

In this testing , the lowest level modules or components are tested first . The testing moves from the lower level components to the higher level components.  If any upper level component is not present then temporary module called DRIVERS is created and the testing is carried out.

1.3 Regression Testing

It is a testing to make sure that after fixing issues/bugs or adding new functionality in the product , the product/program/software is working as expected, ie, the change has not impacted other healthy components. Suppose , a product is having four components A, B, C, D . Suppose there is error in 'C ' Then after fixing 'C' , you need to make sure that other remaining components A, B and D  should work properly like before 'C' was failed and fixed. So in this scenario, the testing carried out to make sure that the old components A, B, D working as expected is regression Testing. OR in the product all components A, B, C, D are working fine and a new component/functionality 'E' is added. Now, you need to make sure that the old components A, B, C, D should work fine like before  'E' was added. In this situation, the testing carried out to make sure that the  old components A, B, C, D are working as expected is regression Testing.

1.4 End to End Testing

It is a testing of the application from the start to finish. This testing includes all the system dependencies, data integrity , data communication between the systems or system components or external interfaces, database etc.

1.5 User Acceptance Testing (UAT)

This is the last phase of testing by the clients/user before the software goes live.  This is done after functional , integration , regression testings are done. This testing is done to make sure that the product can handle the actual challenges  when it goes to the market.

1.6 Unit Testing

This testing is done by developer . After a developer creates or fixes a component or product, he carries out the testing of that component or unit.

1.7 Performance Testing

It is testing of the software performance under the particular workload. Such as response time, speed, reliability, stability, resource usage, scalability etc.  The purpose of the performance testing is not to find bug or defects but to make sure that the software performance is meeting the given standard or not ie the software performs the given task with given resources in the given time limit.

Types of Performance Testings:

Load Testing

Stress Testing

1.7.1 Load Testing

This testing is carried out to test the software response with given load condition. In real time situation, the concurrent users using the software are the actual load. So, the tester carrying out this testing can find out how many concurrent users  can be handled meeting the given time constraint.

1.7.2 Stress Testing

Stress Testing is also called fatigue testing.  In this testing , the work load is increased beyond its normal limit to determine its breaking point ie to determine at what point it fails. So that a safe usage limit can  be determined. This testing is done to test the reliability  ,  stability and recovery  of the system under heavy load/traffic conditions.

1.8 White box Testing

This includes the testing of the internal code, components , structure or design of a software. A tester should have the knowledge of the internal code/components/structure/design  to conduct this testing.

1.9 Black box Testing

This is a testing of the functionality only with out touching the internal code, components, structure or design. A tester does not need to have the knowledge of the internal structure of the software to carry out this testing.