Software Test Life Cycle

Software testing life cycle identifies what test activities to carry out to accomplish quality assurance process in a software development project.

There are different kinds of software development life cycle such as Waterfall, Spiral, Agile, and many others. Software testing has its own life cycle that intersects with every stage of the SDLC either it is Waterfall, Spiral or Agile. However, SDLC varies from one to another based on size of project, test team, test in Scope/out of scope, and code release date (how frequently). So, knowledge about some of the major phase in STLC, quality assurance activities during phases and role of a tester, makes you as a tester always ready to accomplish your task with a mark. This picture describes one of widely used STLC phases.

Generally STLC for a single test cycle consists of phases:

1) Planning, 2) Analysis, 3) Design, 4) Initial Testing 5) Testing Cycles, 6) Final Testing and Implementation and 7) Post release

Planning:

•      High level test plan

•      Identify review process, Metrics

•      Bug reporting procedures

•      Acceptance criteria for QA

•      schedule

Analysis Phase:

•      Develop Test Case format , Validation Matrix

•      Develop, and plan Test Cycles matrices and time lines

•      Begin writing Test Cases based on Functional Validation matrix

•      Map baseline data to test cases to business requirements

•      Identify Automation, Manual and Types of testing ,

•      Test environment, automation system setup.

Design:

•      Test -plan(ning) review and verify.

•      Review matrix (coverage).

•      Continue working on Test Cases.(update, new )

•      Finalize test case selection for each cycle for manual run and automation.

Initial Testing:

•      Complete all plans, Test Case, scripting

•      Unit test (Automated?)

Test Cycle:

•      Test Cycle 1, run first set of test

•      Report bugs - Triage(bug verification)- Bug fixes - Regression

•      Add test cases as required

•      Test Cycle 2, 3 ...

Final Testing and Implementation:

•      Code Freeze

•      Run Test cases for including performance level .

•      Communicate defect tracking metrics.

•      Regression

•      Documents.

Post Release:

•      Evaluation meeting - lesson learned

•      Prepare final Defect Report and metrics. Develop strategies to prevent similar problems in future project.

•      Milestones for improvements

•      Environment clean-up, clean (tag and archive tests and data for that release) restore test machines to baseline for next test cycle.

Final summary:

What is testing?

Testing is the process of showing the presence of defects. Testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements, or to identify differences between expected and actual results

Process of testing:

Testing = Verification + Validation

•      Verification: building the product right.

•      Validation: building the right product.

•      A broad and continuous activity throughout the software life cycle.

•      An information gathering activity to enable the evaluation of our work, e.g.

•      Does it meet the users requirements?

•      What are the limitations?

•      What are the risks of releasing it.

Software Testing Life Cycle

Phase	Activities	Outcome
Planning	Create high level test plan	Test plan, Refined Specification
Analysis	Create detailed test plan, Functional Validation Matrix, test cases	Revised Test Plan, Functional validation matrix, test cases
Design	test cases are revised; select which test cases to automate	revised test cases, test data sets, sets, risk assessment sheet
Construction	scripting of test cases to automate,	test procedures/Scripts, Drivers, test results, Bugreports.
Testing ycles	complete testing cycles	Test results, Bug Reports
Functional Testing	execute remaining stress and performance tests, complete documentation	Test results and different metrics on test efforts
Post Implementation	Evaluate testing processes	Plan for improvement of testing process.

If you have any queries/feed back catch me on - knowthetesting@gmail.com 

Thank you 

Ram

Software testing questions and answers

This article is the part software testing question and answer series. If you have queries on software testing, quality assurance or career in testing then you can ask me these questions in comment section below.

With reference - www.softwaretestinghelp.com

Naresh A. asks:

“My past experience was related to “Test Engineer”. Recently I am appointed as Test Lead in a product based company. Currently there is no Pre-established testing process. As a TL am meant to define a standard process for the entire testing flow and I will maintain certain documents for each product.

Can you help me out in establishing a process for testing, and make me know the entire responsibilities of TL and what documents I am supposed to prepare and maintain?”

As a team leader you are responsible for project planning, scheduling, and communicating your project status to your manager and most important task of assigning and monitoring the project work. Your main responsibility is to build a team to achieve your project goals. You need to focus on handling the challenges in your project so that your team and project will grow and perform well.

As far as the standard testing process is considered, it’s depends on you - what procedure you want to establish. Yes some people might blame me for this point but I prefer to establish my own processes that work for me. I don’t stick to those old process definitions that are written and managed in some 90’s and most of which might not applicable nowadays.

Test lead is responsible for ensuring project plan changes are incorporated in test plan. You might write a test plan and test strategy (In some cases it might be written by senior test team member or even by project test manager) Ensure the work is going according to this test plan. Identify the risks and try to mitigate them. At the end of project testing life cycle ensure that all test objectives are accomplished and acceptance criteria is met.

More TL responsibilities includes: Test Case Review, Requirements Validation, Monitoring the execution of manual and automated test cases, Prepare test summary report and Communicate test status to seniors and prepare corresponding documents.

To know more on SQA processes read this article “SQA Processes- How to Test complete application“. Hope from this answer you will get good idea of testing processes and TL responsibilities.

Pavan Ankus asks:

“I am appearing for the QA positions in US. I would kindly request you to mail me the suitable challenging situations in manual testing and also since I don’t have domain knowledge in Insurance, finance and other financial domain experience I am finding hard to explain to the interviewer as an experienced person. In this regard I need your suitable answer as to how to face the interviewer?”

In every testing interview you will get this question: “Tell me any challenging situation you faced in your previous projects or Tell me any bug that you feel proud to find it?”

I think answers to these questions depend on your testing career. I know every one of you might have faced many challenging situations where exceptional thinking is required to solve such problems.

I will suggest to pick any such situation from you career and explain it in better way. At least it should sound challenging This will help you to face further questions from interviewer depending on your answer.

The broad challenges in manual testing are: How to ensure complete test coverage? Testing without an automation tool is itself a big challenge. You can also explain non-technical challenges in manual testing like managing the testing work in critical time (Llink to testing under time limit) i.e. completing testing before deadline and even worst case if the deadline itself is not feasible.

Explaining a challenging bug you found in your career can be also a good answer for this question. For example the bug that was difficult to find or reprove or having big impact on customer revenue etc.

Pavan you mentioned that you don’t have knowledge in banking and finance domain then how you expect from yourself to give answer on that? If you don’t have experience in banking and finance domain then do not put this as a skill in your resume just for the sake of matching your profile with employer requirements. If you really want to get into testing of BFSI (Banking, Financial services and Insurance) domain then first study this domain. Know the basic concepts in BFSI domain. See the resources I have listed on BFSI domain on our resource page. Keep in mind you can answer in detail about any question if you have worked on that.

Mitch asks:

“What is the best way to go about getting a pay rise? Is reporting and graphing bugs found compared to other team member a good idea?

Comparing the bug count with other team or team member is very bad idea to ask for pay rise. If you are working for the organization for long time then your employer know your value and importance in organization. There is no need to show how your bug count graph is higher than your counterparts.

So what is the best way to ask for good salary rise?

At the time of your performance appraisal you should be able to convince to your reviewer that how you worked hard for your organization, How you succeeded in managing difficult tasks and how you enhanced your skills to better match your current work profile. If you succeed in this negotiation then you will definitely get good pay rise.

Other factors considered while giving you pay rise:

Your relevant skills, Complexity of application you are working on, problem solving skill, total and relevant experience, education and certifications.

If you have any quarries/feed back send me on - rampeddireddy2006@gmail.com, ram@examsinfo.in.

Thank you

Ram

Software Testing Advice for Novice(beginners) Testers

Novice testers have many questions about software testing and the actual work that they are going to perform. As novice testers, you should be aware of certain facts in the software testing profession. The tips below will certainly help to advance you in your software-testing career. These ‘testing truths’ are applicable to and helpful for experienced testing professionals as well. Apply each and every testing truth mentioned below in your career and you will never regret what you do.

Know Your Application
Don’t start testing without understanding the requirements. If you test without knowledge of the requirements, you will not be able to determine if a program is functioning as designed and you will not be able to tell if required functionality is missing. Clear knowledge of requirements, before starting testing, is a must for any tester.

Know Your Domain
As I have said many times, you should acquire a thorough knowledge of the domain on which you are working. Knowing the domain will help you suggest good bug solutions. Your test manager will appreciate your suggestions, if you have valid points to make. Don’t stop by only logging the bug. Provide solutions as well. Good domain knowledge will also help you to design better test cases with maximum test coverage. For more guidance on acquiring domain knowledge, read this post.

No Assumptions In Testing
Don’t start testing with the assumption that there will be no errors. As a tester, you should always be looking for errors.

Learn New Technologies
No doubt, old testing techniques still play a vital role in day-to-day testing, but try to introduce new testing procedures that work for you. Don’t rely on book knowledge. Be practical. Your new testing ideas may work amazingly for you.

You Can’t Guarantee a Bug Free Application
No matter how much testing you perform, you can’t guarantee a 100% bug free application. There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions. Put your best efforts doing good work.

Think Like An End User
This is my top piece of advice. Don’t think only like a technical guy. Think like customers or end users. Also, always think beyond your end users. Test your application as an end user. Think how an end user will be using your application. Technical plus end user thinking will assure that your application is user friendly and will pass acceptance tests easily. This was the first advice to me from my test manager when I was a novice tester.

100% Test Coverage Is Not Possible
Don’t obsess about 100% test coverage. There are millions of inputs and test combinations that are simply impossible to cover. Use techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes.

Build Good Relations With Developers
As a tester, you communicate with many other team members, especially developers. There are many situations where tester and developer may not agree on certain points. It will take your skill to handle such situations without harming a good relationship with the developer. If you are wrong, admit it. If you are right, be diplomatic. Don’t take it personally. After all, it is a profession, and you both want a good product.

Learn From Mistakes
As a novice, you will make mistakes. If you don’t make mistakes, you are not testing hard enough! You will learn things as you get experience. Use these mistakes as your learning experience. Try not to repeat the same mistakes. It hurts when the client files any bug in an application tested by you. It is definitely an embracing situation for you and cannot be avoided. However, don’t beat yourself up. Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future. If required, change some testing procedures you are following.

Don’t Underestimate Yourself if Some of Your bugs Are Not Fixed
Some testers have assumptions that all bugs logged by them should get fixed. It is a good point to a certain level but you must be flexible according to the situation. All bugs may or may not be fixed. Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix. Over time you will also learn which bugs can be deferred until the next release.