Software Testing QA Process Flow-Learn Practical|Software Testing Training Course

PRACTICAL SOFTWARE TESTING QA PROCESS FLOW LEARN WITH SLA CONSULTANTS INDIA

A Complete Overview Of End-to-end QA Software Testing Process Flow:

The job of a software testing professional is not an easy one. It is filled with challenges, which is equally demanding as well. Testers are supposed to be alert and enthusiastic in each and every phases of the application Though there are challenges, there are several tremendous opportunities as well to learn and explore the various aspects of testing methodologies, processes and of course the software in detail.

The role of a test engineer begins very early. And right from the conceptualization of the project, testers are involved in discussions with the product owner, project manager and various stakeholders.

This tutorial on “Software Testing Process flow� gives you a complete overview of the various phases in STLC along with the challenges involved and the best practices to overcome those challenges in an easily understandable manner.

A Complete Overview

Requirement A project cannot take off without having a clear requirement. This is the most crucial phase where ideas need to get written in a well understandable and formatted document. If you are a part of the project where you are participating in the requirement gathering phase, then consider yourself lucky.

Challenges One cannot imagine all the requirements to gather in a single sitting. Be patient enough.

A lot of discussions will happen, some of which may be simply irrelevant to your project but even then they may contain some vital information for your project. Sometimes the speed of discussions may exceed your grasping capabilities or you would simply not pay attention to the product owner.

Highlights the crucial steps involved in requirement gathering:

Best Practices Practice 1

• Keep your mind open and pay attention to every word of the product owner.

Practice 2

• Don’t just listen, clear your doubt however small it seems to be.

Practice 3

• Always use notebooks for fast note keeping. You should use a laptop, only if you can really type at a fair speed.

Practice 4

• Repeat the sentences and get them clarified from the PO which you think is what you understood.

Practice 5

• Draw block diagrams, link text etc. to make requirements more clear at a later period of time.

Practice 6

• If the teams are in different locations, try hard making it a WebEx or similar recording. It will always help when you have a doubt after the discussions are over.

Test Strategy Testers are supposed to come out with a test strategy which is not just sufficient to test the software better

Challenges

The most crucial aspect of this phase is to create a strategy which when worked upon should deliver a software product that is error free, sustainable and accepted by its end users.

Test strategies are something you will not change every other day. In some cases, you need to discuss your test strategies with the customers also. So this part should be dealt with high importance.

Best Practices Practice Practice Practice Practice

1 2 3 4

Practice 5 Practice 6 Practice 7

• Here are some of the best practices, which when followed can provide you a great relief and result in a smooth testing.

• Go through the requirement document once again. Highlight the import points with respect to the environment of the target software.

• Make a list of environments where the software will actually be deployed.

• Environments can be understood as a type of Operating Systems or Mobile Devices.

• If Windows is the operating system, list down all the versions of the window where you will be testing your software. If the versions viz. Windows 7, Windows 10 or Windows Server(s) are still not defined in the requirement document, then it is the high time when these should be discussed.

• On a similar note, get the target browsers with the versions discussed and documented if the AUT is a web-based system.

• Make a list of all the third party software’s that the application will need (If required/supported).

These may include Adobe Acrobat, Microsoft Office, any add-ons etc.

Test Strategy Understand the outline of test strategy if you are working on an agile project:

Test Planning After the testers are armed with all the information regarding AUT, the planning phase is where the Strategy is implemented.

Like test strategy, test planning is also a crucial phase.

Challenges Since the success (or failure) of the AUT depends largely on how the tests were carried out, this phase becomes an important aspect of the entire test life cycle. Why? Because a part of testing is defined in this phase.

In order to overcome some challenges, these best practices can really be helpful.

Best Practices Practice 1 Practice 2 Practice 3 Practice 4 Practice 5

• Always keep in mind, not to leave any stone unturned when it comes to testing your application.

• It’s time to formulate test strategy.

• Create a matrix of the environment so that the software is tested on all platforms.

• Like, Windows 10+Internet Explorer 11+ Windows Office 2010+ …

• Like Android 4.2.2+ Chrome browser.

Practice 6

• If your application works with multiple databases (If documented), keep the databases (MySQL, Oracle, SQLServer) in the test matrix in such a way that they are too integrated with some test.

Practice 8

• Configure test machines accordingly and name them as SetUp1, SetUp2, etc.

Practice 9 Practice 10 Practice 11 Practice 12

• SetUp1 will have Windows 7+ IE 10+ Office 2007+.

• SetUp2 may have Windows 10+ IE Edge+ Office 2013+.

• SetUp3 may have an Android phone with your .apk file installed.

• Congratulations! Your test setup is ready and you have also included every possible combination of platforms that your application will work upon.

Testing Finally, your application build is out and you are ready to find bugs! Now it’s’ time to work on test planning and find as many bugs as possible. There will be some phases in between if you work in an agile environment, then simply follow those scrum methods.

Challenges Testing is a cumbersome process which itself is error prone! One finds many challenges while testing an application. Given below are some best practices to rescue.

Below diagram depicts the categorization of various testing types:

Best Practices Practice 1 Practice 2 Practice 3 Practice 4 Practice 5 Practice 6 Practice 8 Practice 9 Practice 10 Practice 11

• It’s always advisable to look at the application with a fresh look, WITHOUT GOING THROUGH TEST CASES. • Follow the navigation path of your software (AUT).

• Get yourself familiar with the AUT. • Now read the test cases (All) of any particular module (Maybe of your choice).

• Now go to the AUT and match the findings with those mentioned in the expected section of the test cases.

• Idea behind is to test every mentioned feature on every supported platform.

• Make a note of every deviation however trivial it seems to be.

• Write down the steps how you reach any deviation, take screenshots, capture error logs, server logs, and any other supporting documentation which can prove the existence of defects.

• Don’t hesitate to ask. Though you have the requirement document, there will be times when you will be in doubt.

• Reach out to the developers (if they sit next to you or they are reachable) in doubt before you reach to the Product Owner. Understand the developer’s perspective on the working of the software. Understand them. If you feel this implementation is not according to the requirement, then inform the test manager.

Before Release Before we release any product to the market, the quality of the product has to be ensured. Software’s are developed once but they are actually been tested until they are replaced or removed.

Challenges A software has to be tested rigorously for many of its parameters.

The parameters may not be limited to:

•

Functionality /Behavioral.

•

Performance.

•

Scalability.

•

Compatible with the said platforms.

Challenge is also to predict the success rate of an application which depends on many iterations of the testing performed.

Best Practices Practice 1 Practice 2 Practice 3 Practice 4 Practice 5 Practice 6 Practice 8 Practice 9 Practice 10 Practice 11 Practice 12

• Make sure that all the features on all the platforms are tested.

• Highlight the areas which are not tested or the one which needs more testing efforts.

• Keep a matrix of all the test results before release. The test matrix will give an overall picture of the stability of the product. It will also help the management to a take a call on the release dates.

• Now read the test cases (All) of any particular module (Maybe of your choice).

• Provide your input/suggestions to the team about your experiences while testing the product.

• Your input considering yourself as the end user will benefit the software by large.

• Due to time crunch or any other such situation, we either miss out some testing or do not go deep into this. Don’t hesitate to tell the testing status to your manager.

• Present the application health card to the stakeholders. Health card should have a number of all the logged, open, closed, intermittent defects with their severity and priority.

• Draft a release document and share this across the team.

• Work on the release document prepared.

• Improve on the areas which are been suggested by the management/team.

The below picture shows the software release lifecycle map:

Release Finally, the time comes when we have to deliver the product to its intended users. We all as a team have worked hard to sign off the product and let the software help its users.

Challenges Software test engineers are primarily responsible for the release of any software. This activity requires process-oriented workflow. Here are some of the best practices that are involved in this phase.

Best Practices Practice 1 Practice 2 Practice 3 Practice 4 Practice 9 Practice 10 Practice 11 Practice 12

• Always remember, you are not working on the release document on the date of ACTUAL RELEASE. • Always plan the release activity prior to the actual release date.

• Standardize the document as per the company policies.

• Your release document should try to establish the positive expectations from the software.

• Mention all the software and hardware requirements with specific to their versions clearly in the document.

• Include all the open defects and their severity.

• Do not hide major impacted areas due to open defects. Give them a place in the Release document.

• Get the document reviewed and digitally signed [may differ as per company policy].

QA Testing Process on a Real Project – Waterfall Method I got an interesting question from a reader, How is testing carried out in a company i.e in a practical environment?

Those who just pass out from college and start searching for jobs have this curiosity – how would be the actual working environment in a company?

Here I have focused on the actual working process of Software Testing in the companies.

Whenever we get any new project there is an initial project familiarity meeting. In this meeting, we basically discuss on who is the client? what is the project duration and when is its delivery?

Who are all involved in the project i.e manager, Tech leads, QA leads, developers, testers etc.?

From the SRS (software requirement specification) project plan is developed. The responsibility of testers is to create a software test plan from this SRS and project plan. Developers start coding from the design. The project work is divided into different modules and these project modules are distributed among the developers.

In the meantime, the responsibility of a tester is to create test scenario and write test cases according to the assigned modules. We try to cover almost all the functional test cases from SRS. The data can be maintained manually in some excel test case templates or bug tracking tools.

When developers finish the individual modules, those modules are assigned to the testers. Smoke testing is performed on these modules and if they fail this test, modules are reassigned to the respective developers for a fix.

For passed modules, manual testing is carried out from the written test cases. If any bug is found that gets assigned to the module developer and get logged in bug tracking tool. On bug fix, a tester does bug verification and regression testing of all related modules. If bug passes the verification it is marked as verified and marked as closed. Otherwise, above-mentioned bug cycle gets repeated.(I will cover the bug life cycle in another post) Different tests are performed on individual modules and integration testing on module integration. These tests include Compatibility testing i.e testing application on different hardware, OS versions, software platform, different browsers etc.

Load and stress testing is also carried out according to SRS. Finally, system testing is performed by creating virtual client environment. Once all the test cases are executed, a test report is prepared and the decision is taken to release the product!

Steps in Requirements to Release Given below are the details of each testing step that is carried out in each software quality and testing life cycle specified

by IEEE and ISO standards:

1.

SRS Review: Review of the software requirement specifications

2.

Objectives are set for Major releases

3.

Target Date planned for the Releases

4.

Detailed Project Plan is built. This includes the decision on Design Specifications

5.

Develop Test Plan based on Design Specifications

6.

Test Plan: This includes objectives, the methodology adopted while testing, features to be tested and not to be tested, risk criteria, testing schedule, multi-platform support and the resource allocation for testing.

7.

Test Specifications

8.

Writing of Test Cases

1.

2.

3.

4.

9.

Smoke (BVT) test cases Regression Test Cases Negative Test Cases Extended Test Cases

Development – Modules are developed one by one

Steps in Requirements to Release 10. Installers Binding: Installers are built around the individual product.

11. Build procedure : A build includes Installers of the available products – multiple platforms.

12. Testing Smoke Test (BVT): Basic application test to take decision on further testing Testing of new features Crossbrowser and cross-platform testing Stress testing and memory leakage testing.

13. Test Summary Report Bug report and other reports are created 14. Code freezing No more new features are added at this point.

15. Testing Build and regression testing.

16. Decision to release the product 17. Post-release scenario for further objectives.

WANT TO LEARN SOFTWARE TESTING??

You can enroll Software Testing Training Course at SLA Consultants India

• Customized Course • Practical Session • Real Life & Live Projects • Job Assistance After Training (Assuredly)

WANT CONTACT DETAILS? Head Office

Gurgaon Branch Office

Noida Branch Office

• 82-83, 3rd Floor, Vijay Block, Above Titan Eye Shop, Metro Pillar No 52 Laxmi Nagar, New Delhi, 110092

• 3rd Floor, Gourav Plaza, DLF Phase – 2 Sikanderpur, Metro Pillar No 50 Gurgaon, Haryana, 122002

• E-49, First Floor, Sector 3, Near Sector 16 Metro Station Noida, Uttar Pradesh, 201301 • +91- 9310803536

• +91- 9999491895

• hr@slaconsultantsindia.com

• +91- 9999340200 •

kahkshan@slaconsultantsin dia.com

•

hr@slaconsultantsindia.co m

THANKS FOR WATCHING ANY QUERY? COMMENT BELOW CONTACT - +91- 9999491895/+91- 9999340200 EMAIL-HR@SLACONSULTANTSINDIA.COM