Introduction to QA Manual Software Test Training Module
Table of Contents
Welcome to this training module. This module is a section of a course entitled QA Manual Testing. This course module is divided into two written sections to optimize the size of the document. The written sections are accompanied by course videos to enhance your experience with the training. You can choose to read through the documentation or go directly to the videos. Once you are done you have both the written text and the videos to use as referential resources in the future.
Section 1 of this module incorporates general information regarding manual software testing. And section 2 of this module provides an overview of software topics that will be presented in more detail by the additional modules available for this course.
|See All||Module 1 Playlist (slides 1-7)|
|QAMT1-1||Module Introduction (slides 1-7)|
|QAMT1-2||The What Questions 1 (slides 8-9)|
|QAMT1-2a||The What Questions 2 (slides 10-11)|
|QAMT1-3||SDLC and STLC (slides 12-12)|
|QAMT1-3a||SDLC and STLC 2 (slides 13-16)|
|QAMT1-4||SDLC Models with Examples (slides 17-21)|
|QAMT1-5||SDLC Stages with Impacts (slides 22-28)|
|QAMT1-6||Planning and Design (slides 29-31)|
|QAMT1-7||Design (slides 32-34)|
|QAMT1-8||Test Objectives (slides 35-38)|
|QAMT1-9||Test Plan (slides 39-44)|
|QAMT1-10||Test Cases (slides 45-49)|
|QAMT1-11||Test Data Prep (slides 50-52)|
|QAMT1-12||Defects (slides 53-58)|
|QAMT1-13||Lab Session Instructions (slides 60)|
The objective of this training segment is to provide an overview of software testing and its importance to the software development life cycle (SDLC). Software testing is one of the phases of SDLC. An SDLC is comprised of seven stages of activity which are:
- Requirements & Analysis.
- Project Planning.
- Coding & Implementation.
By the end of this training, every student should have a clear understanding of the software testing process and its role in ensuring the quality of software products. It is not expected that you can put all that is covered into practice. It is only our expectation that you are familiarized with the concepts of manual testing. Armed with this information you can probably sit in with a test team and not be totally lost. Another benefit of this introduction is for test analysts that have not done manual testing for an extended period and want a refresher.
Read about SDLC. We will provide you with a link.
Half a day (2-3 hours of lecture time)
Thank you for joining us for this training session, which is the introduction training for our Manual Software Testing Course. The course will be conducted in a manner that will promote thought and understanding of what is shared. The course will include lectures, lab sessions, quizzes, and homework assignments. It is expected you will find benefit from all methods that we use to disseminate training information. I just mentioned how we will provide you with information on the front-end. We won’t stop at that. At the back end when you have completed this training, you will be provided with access to training videos that will continue to support you with ever-green knowledge about the topics of this course.
The objective of this training segment is to provide an overview of software testing and its importance to software development life cycle (SDLC) projects. Software testing is one of the stages of SDLC. An SDLC is comprised of seven stages of activity. This course will include Agile SDLC training. But for now, you will be hearing me reference SDLC, the oldest of the two well-known methodologies.
By the end of this training, every student should have a clear understanding of the software testing process and its role in ensuring the quality of software applications.
For this course segment we will cover manual testing basics. We will proceed from here with these software testing topics:
- What is software testing?
- Importance of software testing
- Types of software testing
- Role of a software tester in the software development life cycle (SDLC)
- Overview of the SDLC models and testing in each phase
- Test planning and design process
- Test case execution and defect management
- Overview of testing techniques
- Career opportunities in software testing
Let’s define “Software testing” as the process of evaluating a software system, business application, or its components with the objective to discover whether it meets the specified requirements and does what is expected.
Bear with me as I attempt to dig in a little more on the definition. You may be hearing words that don’t quite paint a good picture for you. Software testing has a life cycle just like software development. So, it is a process. It is an evaluation process focused on software products and business applications sold on the market or developed internally at a company.
Software testing is comprised of several process cycles. These cycles become skills for a tester. They are:
- Requirement gathering and analysis.
- Test planning.
- Test case design and development.
- Test environment setup.
- Test execution and results reporting.
- Test cycle closure.
At this time, you should begin to know that if you want to test software you will need to build certain skills. I just exposed you to a list of skills you will need to develop. We will talk in detail about them.
The final part of breaking down the definition of “Software Testing” is the test target. The target is some software whether developed in your company or by software companies for purchase. The purpose is to discover if the targeted software meets expectations. If it does meet expectations, you as a tester come out of the cycle loop. You are done with the testing project, but maybe not the software development project. So, either you prepare for another round of testing, or you close out. Closing out might be as simple as a document to summarize your findings, and detail analysis of unresolved issues. More on this to come.
Software testing is critical to the software development process or project because it helps identify defects and supports the process of defect resolution regarding the software before it is released to the end-users or the public. Manual and automated software testing helps ensure that the targeted software is of high quality and meets the customer’s needs. The focus of this course is on manual testing. So, we will talk more about manual testing.
Manual Testing is about helping detect defects early in the development process. The primary reason is to reduce the cost of fixing the defects. The later defects or issues are detected in the development process, the more it may cost to repair. It isn’t obvious but because requirements and design specifications may require review and analysis before repairs can be made to the code. Then the amount of re-testing can be costly too. Then there is the possibility of what is known as regression issues. This is where unexpected code changes were made to resolve the issue. The result is more issues arise and more fix-time along with test time is required. The sooner a defect is detected and resolved, the better the chances of other issues are minimized.
Manual Testing helps increase customer satisfaction. This is done by ensuring that the software is responding reliably and ensuring that it meets their needs. The users or customers can be the real users of the software, or a combination of business analysts and selected businesspeople committed to being involved in the development and testing processes. These users dedicate some time and are crucial to asserting or affirming software satisfaction. So, the testing should achieve customer satisfaction, not disappointment.
The types of software testing that exist are another opportunity for skill building as a tester. Let’s start getting familiar with these opportunities for new skills. Allow me to expose you to a division of software testing that might affect your career path. The most well-known type of testing is functional testing.
Is the activity of testing the functional requirements of the software or application to ensure that they work as expected. It is mostly what we have been talking about. It is the most common type of testing in Software testing.
But then there is testing of non-functional requirements. Software or applications often require testing to determine how reliable, responsive, secure, user friendly, and portable it is. Some of the testing types here are known as performance, security, usability, and other testing.
Performance Testing activities are focused on the performance of the software under various load conditions. The tester is conducting tests that are designed to look beyond the software functions. Instead, it seeks to determine the reliability, scalability, and responsiveness of the target test application. I hope you notice that I tend to use application and software interchangeably. I might also say business application. Please do not be confused by the references.
Some applications more than others are concerned with the possibility of internet hackers penetrating the software and extracting sensitive information or disabling the software from operating normally. The type of Testing needed is called security testing. The testing of the software to identify and address security vulnerabilities is called security testing. This testing is usually required for applications that allow public internet access.
Let’s turn our attention to the tester doing the testing. As much as possible I want to either use the term tester, or test analyst as general references to those who conduct software testing. My referencing tester is more general to anyone who might test software, such as business users. My reference to test analyst will be about those who test software as a career.
Now, a test analyst is normally assigned a role in a test project. In a moment I will focus on roles, but for now I want to inject some thoughts on the skills of a test analyst and what is skill building. You will hear me mention this often. So, allow me to elaborate on this a little more. Some of you will find you already have some of these skills. Let’s give some attention to them starting with documentation creation.
- Creating documentation
As a test analyst, you need to document what you are doing for audit and historical reasons. Proper documentation provides you with an organized, clearly defined explanation of your work. I find myself using MS Word, Excel and PowerPoint, and One Note for this purpose. Documenting test instructions, results, status. The list goes on.
- Planning tests
The plan determines what you’re testing, who is responsible for each step and the main objectives of the test. This documentation allows all stakeholders to see the testing plan. There is a training module in this course dedicated to this skill.
- Identify Test scenarios
Your test preparation also includes test scenarios, which outline exactly what you’re testing and the priority. In the System Requirements specifications you may find what is called Use Case documents or User stories as it is done in Agile. This documentation usually relate directly to test scenarios which are a grouping for test cases.
- Develop Test cases
Test cases detail the step-by-step process of software testing and the test results, usually documented as positive or negative. Many software testers input this information into spreadsheets, but others may enter them into a test management software tool. Developing both skills is important.
- Select test methods
Test Analysts must select the most appropriate testing for the project. Sometimes this is already done by a test lead, but you will do this at some point. More to come on this.
- Composing defect reports
Creating detailed defect reports, or bug reports, is crucial to getting defect resolution and improving application quality. I am mentioning these skills now and more is to come on many of these.
- Analytical and logical reasoning
Test Analysts must make deductions based on the information available. The testing reports may not state conclusions explicitly, but good testers should be able to determine what must follow reasonably given the status. Thinking logically or analytically does not come naturally for all of us. SO, it may need to be a learning experience.
- Automating software tests
As a test analyst, you should be proficient in running manual tests, but you should also recognize when and how to incorporate automated testing processes.
- Understanding DevOps and Agile methods
DevOps and Agile methods promote collaboration and flexibility in software testing. These newer approaches encourage test analysts to exercise teamwork as a skill.
- Understand programming languages
Test Analysts should be familiar with the most common programming languages so they can better communicate with developers. Familiarity is key not proficiency.
- Learning current technology trends
As technology continues to move forward, test analysts must understand how current tech trends may affect their organization and its systems. More on this to come.
- Incorporating testing tools
Test Analysts should be familiar with a variety of testing tools that can speed up testing and enhance accuracy provided the management approves. These tools include: Bug tracking, automation tools, GUI testing, API testing, Security testing, Mobile testing, and CSS validators.
- Networking with other professionals
Test Analysts can use social networking to connect with other IT professionals, learn about upcoming events and classes, collaborate with other testers and promote their services.
Every tester has a role to play in software testing. We were just exposed to the idea that testers don’t all have the same role. The role is dependent on the skillset and what you were hired to do. Because testing is a creative task, you as a test analyst may have a preference in the type of testing that is appealing. The more you are doing what is appealing, the better your outcome. In other words, if you are going to have testing as a career you should understand the different test types and roles. So, we have talked a little about the test types. Now let’s talk about the roles.
Test Analysts are responsible for evaluating the software and ensuring that it meets the specified requirements and works as expected. They usually work closely with the development team to understand the requirements and then design the test cases. They may have a software tool that supports test case development, or its typical to use MS Word or MS Excel for this purpose. We will get into more detail later in this course.
Upon completion of test case development test analysts execute the test cases and report defects or issues to the development team. This reporting today is usually a software tool that everyone on the development team has access to for review and status purposes. Test analysts meet collectively and with the other members of the development team to discuss their findings and issues. Sometimes through this meeting of the minds, issues are clarified and resolved in the meeting. Other times more detail surfaces regarding issues or defects and either a developer or test analyst can go back and do further research toward problem resolution. Test analysts must possess a mindset that the ultimate user requirements are essential to achieve. Users are thinking business case more than functional.
I am going to be talking about several cycles. One is the big scope of software development. The other two are regarding software testing for the development project. I just mentioned SDLC which is the acronym for Software Development Life Cycle. The next is Software Test Life Cycle or STLC. And the third is Bug Life Cycle or BLC. Because they are iterative processes, Life Cycle is used in their titles.
I am using this slide to relate roles and cycles. Instead of referring to roles here I am using the term expectations. I am not intending to go deep right now on this. Just know that when you join a development project, you area part of the SDLC, but your main responsibilities are involved with STLC and BLC. This course will provide more training on these concepts.
Before diving into the development and test cycles, I want to stay at around 35,000 feet and give you a proper introduction. This is especially for those of you that are not familiar at all with these concepts.
The SDLC methodology has been around a long time. It defines the principles that have been used to develop software. I think it began just after we left the chisel and stone age. It has been around a long time and is very mature. Several versions or models of its implementation have been used on software development projects over these past years. I have more to share with you on this subject and hope to take you through it a little at a time.
The development project team manages the processes of SDLC. The cycle itself can start with the Maintenance phase or the Requirements phase. The dependence here is whether the project is a new development effort, replacement, or a major upgrade. Testing is one of the phases in SDLC. And depending on the version of SDLC in use, the way testing is accomplished will differ.
For an application already in production, maintenance is a cycle too. Requirements gathering and Design phases are usually minimal for application software maintenance. I’m going to introduce to you later in this module a case study that will show you that SDLC can change and adapt depending on how different the requirements are for a development project. This is part of the reason behind the varying models of SDLC.
This methodology is a series of phases (like a wheel within the wheel of SDLC) that provide a model to develop and manage low-cost test assets to deliver high-quality software in a reasonable timeframe. If you can follow me on the wheel within a wheel gyroscope concept. STLC functions inside SDLC without hindering. The objective of STLC is to enhance the development of software that exceeds the customer demands and expectations.
Now for STLC the test team manages it. It is a cycle that can begin at the maintenance stage or the Requirements stage. Where the cycle begins is dependent on whether the SDLC is a maintenance project or new development. It can also start at the maintenance stage if the test cycle is for a major regression effort due to significant development changes.
I hope this does not inject confusion, but the maintenance stage can also be a cycle. It affects the requirements gathering to the environment setup stages. They are minimalized in scope usually. In case you are wondering about this. Let me say that when a project is in high maintenance mode you should already have been through requirements, planning, development, and environment setup.
As one who is familiar with software development life cycle (SDLC) models, I can offer some insights into the most popular SDLC models that are currently being used in the software development industry.
The Waterfall Model is a sequential, linear approach to software development that involves a rigid sequence of phases, including requirements gathering, design, implementation, testing, and maintenance. I would emphasize that the Waterfall Model is best suited for projects that have well-defined requirements where changes to requirements are unlikely. Also, it is suitable for a technology not known for instability. A desktop business application or software tool might qualify.
Agile is a flexible and iterative approach to software development that focuses on delivering working software in short iterations. It emphasizes collaboration, customer feedback, and continuous improvement. As a teacher, I would highlight the importance of the Agile Model in the current software development landscape, where changes in customer requirements, business needs, and technology are common. I would also stress that Agile requires a highly skilled team, excellent communication, and a flexible mindset.
The V-Model is a hybrid approach that combines elements of the Waterfall Model and the Agile Model. The V-Model emphasizes testing throughout the software development life cycle and places a strong emphasis on verification and validation. As a teacher, I would highlight the importance of the V-Model in situations where high levels of quality and testing are required.
The Spiral Model is a risk-driven approach to software development that involves iterations and prototyping. It emphasizes early risk identification and mitigation. As a teacher, I would emphasize that the Spiral Model is best suited for complex projects with significant risks, where requirements are not well-defined, and the technology is untested.
As a teacher of SDLC models, I would emphasize that no single model is perfect for all situations. Each SDLC model has its strengths and weaknesses, and the choice of which model to use depends on the project’s specific requirements, constraints, and goals. I would also stress the importance of selecting the right model and adapting it to the project’s needs to achieve the best results.
I mentioned before that testing is critical to software development, and it is important to perform testing at each stage of development to ensure the quality of the software product does not diminish during the development project. Let’s take a closer look at testing in each stage of the SDLC, as well as some comparisons of different SDLC models.
The requirement gathering stage is the first stage of the SDLC, where the requirements for the software product are defined. During this stage, it is important to perform requirements testing to ensure that the requirements are complete, correct, and unambiguous. Requirements testing can be done using techniques such as reviewing requirements documents, performing walkthroughs and inspections, and creating prototypes.
Be Aware: The Developers may see their work as “proprietary property”. That means that you as a test analyst may be viewed dimly being involved in the first two stages of development. You may find yourself as if you are walking on eggshells. The more experience you have the more valuable you are during these stages of development. So, be confident and considerate if you are invited to participate in these stages as a test analyst.
During the design stage, the architecture and design of the software product are defined. During this stage, it is important to perform design testing to ensure that the design is complete, consistent, and meets the requirements. Design testing can be done using techniques such as peer reviews, code inspections, and testing design models.
During the implementation stage, the software product is developed according to the design. During this stage, it is important to perform unit testing to ensure that each unit of code is working correctly. Unit testing can be done using techniques such as white-box testing, black-box testing, and code reviews.
During the testing stage, the software product is tested to ensure that it meets the requirements and is free of defects. Testing can be done using techniques such as functional testing, integration testing, system testing, and acceptance testing. It is important to perform testing at each level of testing to ensure that the software product is thoroughly tested and meets the requirements.
During the deployment stage, the software product is released and deployed to the production environment. During this stage, it is important to perform release testing to ensure that the software product works correctly in the production environment. Release testing can be done using techniques such as smoke testing and regression testing.
During the maintenance stage, the software product is maintained and updated as necessary. During this stage, it is important to perform maintenance testing to ensure that the updates or changes do not introduce new defects or impact the existing functionality. Maintenance testing can be done using techniques such as regression testing and exploratory testing.
This is not the end of the introductory training. There is another segment – Segment 2. All the videos are shown here in Segment 1. But the videos will not be available on the Segment 2 web page. Click here to navigate to the second part of this training narrative.