My Journey as a Software Tester: Beginners Guide To Software Testing
- December 11, 2023
- Posted by: MainInstructor
- Category: Architectural Design BASIC C Go JavaScript React Software Engineering Software Testing
![](https://i0.wp.com/allprowebdesigns.com/wp-content/uploads/2023/12/1702253527_maxresdefault.jpg?resize=840%2C430&ssl=1)
Video Title: My Journey as a Software Tester: Beginners Guide To Software Testing
Good evening or good morning depending on where you are in the world would would like to introduce you to the next uh lecture as it relates to my journey in becoming a software tester we’re going to talk about today is the beginner’s guide to software testing by pad
MEC and before I do it would like to let you know this is for educational informational and review purposes it’s time to take the credit for the intellectual property of this ebook all to the intellectual property this ebook goes to pad mini C uh c as pad mini C And okay so this is beginners guide the software testing we’re going to talk about in this lecture we’re going to talk about going to give an overview of what it is big picture what is software why should it be tested what is quality how important is it what
Exactly does a software tester do what makes a good software tester guidelines for new testers our overview for introduction we’re going to talk about the software life cycle various life cycle models software testing life cycle what is a bug and why do bugs occur bug life cycle cost of fixing bugs and when
Can fixing be stopped or red used we’re going to talk about the software tester levels types terms and definitions in terms of it’s testing levels and types testing terms most common software errors and top types of errors with examples then we’re going to go on to talk about the test planning process
That is what is a test strategy and what are its components then we’re going to talk about the test planning and Sample structure and major test planning tests then we’re going to talk about test case development in terms of General guidelines then the test case sample structure test case design
Techniques and what is a use case then we’re going to talk about defect tracking what is a defect what are the defect categories how is the defect reported and how descriptive should your bug defect report B what does a tester do when the defect is fixed
Then we’re going to talk about types of test reports then we’re going to talk about software test Automation in terms of the approaches to automation choosing the right Tool top 10 challenges of software test Automation and we’re going to talk about the introduction to software standards in terms of sex Sigma and
ISO uh then software testing certifications and then facts about software engineering so we’ll finish with facts about software engineering all right with that said let’s start with it let’s talk about an art overview here this is in regards to beginner’s guide to software testing we need to First consider is the
Big picture and let me see if I can get that text now all software problems can be termed as bugs a software bug usually occurs when the software does not do what it’s intended to do or does something that is not intended to do Claws and specifications design code or other
Reasons can cause these bugs identifying fixing bugs in the early stages of the software is very important as the cost of fixing bugs grows over time so the goal of a software tester is to find bugs and find them as early as possible make sure that they are fixed
Testing is context B and risk driven and requires methodical and disciplined approach to finding bugs a good software tester needs to build credibility and process to attitude to be explor tative troubleshooting Relentless creative diplomatic and persuasive as against the perception that testing starts only after the completion of the code phase or the
Coding phase and begins before the first line of code is written in the life cycle the conventional software product testing begins in the stage where the specifications that are written for example for uh from testing the product specification or the product spec which is specification finding bugs at this stage
Can save huge amounts of time and money once the specifications are well understood you’re required to design and execute test cases selecting the appropriate technique reduces the number of tests that can cover a feature in one of the most important things that you need to take into a consideration while
Designing the these test cases test case need to be designed to cover all aspects of this software for example security database functionality in terms of critical in general and the user interface bugs originate when the test cases are executed as a test you might have to perform testing under different
Circumstances for example the application could be in the initial stages of undergoing rapid changes you have less than enough time to test the product might be developed uh using life cycle model that does not support much of the formal testing or retesting furthermore testing uses different operating systems browsers and
Configurations that need to be taken care of reporting a bug may be the most important and sometimes the most difficult task that your software tester will perform by using various tools and clearly communicating to the developer you can ensure that the bugs you find or fix and that’s why we were talking about
The gyro software that’s that tracking software for both the software tester and the screen Master using automated tools to execute task run scripts and tracking bugs improves efficiency and effectiveness of your task also keeping Pace with the latest developments of the field will augment your career offw test
Engineer now you might ask the question a fundamental question what is software and why should it be tested well software is a series of instructions for the computer to perform a particular task called the program the two major uh categories of software are system software and application software that part system software is
Made up of control programs application software is any program that process sted for for the user spreadsheet and word processor payroll Etc software product should be only released after it has gone through a proper process of development testing and Bug fixing you can probably imagine because
You need to make sure that the software works properly thises thing looks at areas such as performance stability error handling and setting up test scenarios Under controlled conditions in which you’re accessing the results this is exactly why any software has to be tested is important to know the software is mainly tested to see if it meets the customer’s needs and conforms to the standards it is usually uh it is a usual Norm that software is consider
Good quality if it meets the user requirements okay so here’s another question what is quality and how important is it well quality can be briefly defined as a degree of Excellence high quality software usually conforms to the user requirements a customer’s idea of quality May cover breadth of features such as performance
Excuse me conformance this specifications good performance on platforms and configurations and completely meets operational requirements even if not specified so this is our measuring stick also compatibility to all other end user equipment no negative impact on existing end user based at introduction time quality software saves good time of
Uh amount of time and money because software will have fewer defects this saving during uh this saves time during testing and maintenance phases greater reliability contributes to an immeasurable uh increase in customer satisfaction as well as lower maintenance costs because maintenance represents a large portion of all software cost
Overall cost of the project will most likely be lower than the similar projects following are two cases to demonstrate the importance of software quality here’s one scenario where you had Aron five crash June 4 1996 we have the specification here it’s just an example this is crash so they’re doing
This literally Li in app playing Crash crash in terms of software means just stops it just closes and stops working okay now having software run wrong wrongly on an airplane can cause can cause a uh loss of about half a billion dollars explosure as result of the software error uncaught exception
Due to floating Point error conversion from 64-bit integer to 16bit sign integer applied to larger than expected number module was reused without proper testing from Aron 4 error was not supported to happen with Aron 4 and no exception handling we also have an example here of a Mars climate Orbiter September 23
1999 the Mars climate Orbiter disappeared as it began to orbit Mars cost was about 50 $125 million failure due to air error in the transfer of information between a team in Colorado and a team in California one team used English units for example inches feet pounds while the
Other ones use metric units as a key a spacecraft operation which is very important that you get the same standard you have a standardization that is very strictly adhered to otherwise you will have software errors uh which can have catastrophic um both physically and financially so what exactly does a software tester
Do apart from exposing faults or bugs in a software product confirming that the program needs uh meets the Suess um uh program specification as a test engineer you need to create test cases procedures scripts and generate data you execute test procedures scripts analyze standards and evaluate results of system integration and regression
Testing okay so you also need to speed up development process by identifying bugs at early stage like we just already said about that for example specification stage in the specification stage reduce organization’s risk of legal liability maximize the value of the software ures uh successful launch of the product save money time and
Reputation of the company by discovering bugs and design flaws at early stage before failures occur in production or in the field and remote continual Improvement excuse me promote continual Improvement now here’s the all important question what makes a good tester as a software as software engineering is now considered as as
Technical engineering profession which is kind of a technicality is important that the software Engineers possess certain traits with Relentless attitude to make them stand out and here are a few you first of all you need to know the technology knowledge of the technology in which the application develop is an
Added advantage to any tester it helps design better and Powerful test cases basing on the weakness or flaws of the technology good testers know what it supports and what it doesn’t so concentrating on these lines help them break the application quickly excuse me okay so we’re gonna make an emphasis
On the first line here knowledge of the technology in which the application is developed is an added advantage to any tester perfectionist and a realist inner perfectionist will help tester spot the problem and being a realist helps you know at the end of the day which problems are really important problems
You will know which ones require fix and which ones don’t tactful diplomatic and persuasive good software testers are tactful and know how to break to the the news to developers they are diplomatic while convincing developers or for the bugs and persuade them when necessary and have their bugs fixed it
Is important to be critical of the issue and not let the person who developed the application be t uh taken back on the findings also an Explorer a bit of creativity and attitude to taking risk helps testers Venture into unknown situations and helps and find bugs that otherwise would be looked
Over also trouble troubleshooting and figuring out why something doesn’t work helps testers be confident and clear and communicating the defects to the possess people skills and tenacity tests excuse me testers can face a lot of resistance from programmers being socially smart and diplomatic doesn’t mean being indecisive
The best test of both socially adep and tenacious where matters organized best testers are well realized that they can make mistakes and didn’t take any chances and don’t take chances they’re very well organized and have checklists files facts and figures to support their findings and uh that can be used as evidence and
Double check their findings objective and accurate they’re very objective to know what they report so they can convey impartial and meaningful information that keeps politics and emotions out of the message reporting inaccurate information is losing a little credibility good testers make sure the findings are accurate and reproducible defects are valuable good
Testers learn from them each defect is an opportunity to learn Improvement defect found early substantially cost less when compared to the one that’s found at a later stage the effects can cause serious problems if not managed properly learn from the defect helps prevent excuse me uh helps prevention of
Future problems track improvements and improve predictions and estimation so here are some guidelines for new testers number one testing can’t show that bugs don’t exist the important reason for testing is to prevent defects you can perform War your tests find and Report bugs but at no point can you guarantee there are no
Bugs okay is impossible to test the program completely at least at this stage unfortunately this is not possible with the simple program because the number of inputs is very large and number of outputs is very large a number of passed through the software is very large and the specification is subject
To frequent changes so this is the reason you can’t guarantee quality as a software testers you cannot test everything and are not responsible for the quality of the product the main way to be a tester can fail is to excuse me the main way a tester can fail is to
Fail to report accurately a defect that you’ve observed it’s important to remember that we seldom have limited little control over quality then we have Target environment intended end user anticipating and testing the application in the environment user is expected to use is one of the major factors that should be
Considered also considering if the application is a single user system or multi- user system is important in demonstrating the ability for immediate Readiness when necessary the aase of Disney’s Lion King illustrate this Disney Company released its first multimedia CD ROM for children Lion King animated story book is highly
Promoted and the sales were huge soon there were reports that the buyers were unable to get the software to work they worked on a few systems likely the ones that Disney programs used to create the pro uh game but not on on the most common systems that the general public
Used and we have no application is 100% of free is more reasonable to recognize that there are priorities that leave some critical programs unsolved or unidentified simple cases is the Intel Pentium book enter the following equation into your PC’s calculator you have this number divided by the next number parenthesis
Times this number minus another number answer is zero uh your computer is just working fine if you get any else you have an an old Intel CPU with a floating Point division book either customer try to use the system as a l user to get a glimpse of this get a um
Get a person who has no idea about the application and use it for a while to see for a while and you’ll be amazed to see the number of problems the person seem to come across as you can see there is no procedure involved doing this could
Actually cause a system to encounter an array of unexpected tests repetition stress load rise Etc and build your credibility credibility is like quity that includes reliability knowledge consistency and reputation trust attitude and attention to detail is not instant but you should built should be built over time and
Gives voice of testers in the organization your keys to build building credibility that is to identify your strengths and weaknesses build good relations demonstrate competency be willing to admit mistakes and reassess and adjust this What You observe is very important that you test What You observe you have access to writing creative test
Cases can only help you when you have the opportunity to observe the results so assume nothing which is an important not all bugs you find will be fixed deciding which bugs will be fixed and which won’t be risk won is a risk-based decision several reasons why your bug
Might not be fixed is that there is not uh there is no there not no enough time there’s not enough time the bug is dismissed for uh new feature fixing it might be risky or might might not be worth it because it occur occurs infrequently or has a
Workaround where the user can prevent avoid to prevent or avoid the bug making a wrong decision can be disastrous then we want to review the competitive products gaining a good insight into various products of the same kind and getting to know the functionality and general Behavior will help you design
Different test cases and understand the strengths and weaknesses of your application this will also enable you to add value and to suggest new features and enhancements to your products that’s more of a marketing type consideration follow standards and processes as a tester you need to conform to the standards and guidelines
Set by the organization these standards pertain to the reporting hierarchy coding documentation testing reporting bugs and using automation tools how immed tools let’s talk about the introduction of our software life cycle now the software life cycle typically includes the following requirement analysis design coding testing insulation and maintenance so these are Our aspects in between there is a requirement to provide operations and support activities for the products so what we have is we have the requirement analysis which is software organizations provide solutions to customer requirements by developing appropriate software that best suits their specifications thus the life of the
Software starts with the origin of requirements very often these requirements are vague and emergent and always subject to change now now performed to conduct an in-depth analysis the proposed project to evaluate the technical feasibility to discover how to partition the system and to identify which areas of requirements need to be
Elaborated from the customer to identify the impacts of changes with two requirements should be allocated with the components then we have the designning specifications for a software leite that is the outcome of requirements analysis is requirement specification using the overall design for the intended software that is
Developed and and for that we have activities in the phase which is to perform architectural design to the software design that is for the design database if applicable and design user interfaces select or develop algorithms if applicable and perform detailed design and for the coding this is the
Development process that tends to run iteratively through the process rather than linearly because it can go in different directions like a mesh type topology where several models spiral waterfall Etc have been proposed to describe the process and for the coding you have activities in the face such as create test
Data create Source generate object code create operating documentation find integration and perform integration then we have the testing that is the process of using develop systems with the intent to find errors so we’re trying to find errors uh defects or flaws or bugs at the stage it will be set back for the
Development to uh for the developer to fix and have to be retested the phase is iterative as long as the bugs are fixed to meet the requirements and the activities in the phase are your plan verification and validation execute validation and validation tasks collect and analyze metric data plan testing develop test
Requirements and execute tests that’s fre testing terms of the installation this is developed in tested software can needs to be installed at a client Place careful planning is to be done to avoid problems to the user after insulation next done the activities for the phase of the fallowing when installation distribution of
Software installation of software except software an operational environment operation in support support activities are usually performed by the organization that develops software both parties usually decide on the activities before the system is develop terms of activities in the phase that is to operate the system provide technical assistance Consulting and
Maintain report excuse me maintain support and finally we have maintenance now with maintenance this is the process does not stop until it’s completely implemented and installed at a user place this place undertakes the development of new features and enhancements activities in the phases reapplying the software life
Cycle we have different life cycles to understand and consider I talked about this in the previous lecture but basically let’s let’s revisit them before I mention them I would like to let you know that the way that you approach a particular application for testing greatly depends on the life
Cycle that it follows so keep that in mind this is because each life cycle model places emphasis on different aspects of the software for example certain models provide good scope and time for testing whereas some others don’t so the number of test cases developed features covered
Time spent on each on each issue depends on the software life cycle model the application follows no matter what life cycle model is every application underg goes the same phases described as the life cycle which you just talked about previously so our three life cycle models are we have the waterfall model which
Has emphasis completion of one phase before moving on which makes sense and emphasizes earlier planning and customer input in design and emphasizes testing as integral part of the then we have the prototyping model these are strengths by the way that I’m listing uh for the prototyping model
Requirements can be set earlier and more reliably requirements can be computed can be communicated more clearly and completely between developers and clients and requirements design options can be investigated quickly with low cost and for our spiral model because this one actually is cut off is this oh okay there’s more here okay
Sorry this continues on the next one uh more requirements and design Faults Are caught early for our Spyro model in terms of strengths it promotes the ReUse of existing software in early stages development allows quality objectives to be formulated during development and provides preparation for eventual evolution of the software
Product eliminates errors and unattractive Alternatives early and it balances resource expenditure doesn’t involve separate approaches for software development and software maintenance provides a viable framework for integrated hardware and Software System development which is huge let’s talk about the their corresponding weaknesses for the waterfall model or weaknesses depends on
Capturing and freezing requirements for the life cycle depends on separating requirements from design and feedback is only testing phase for any previous stage not feasible in some organizations and emphasizes products rather than processes and for the prototyping model or weaknesses as that it requires a prototyping tool and expertise in using
It the cost for the development organization and the Prototype may become the production system in terms of real weakness for the spiral model process needs are usually associated with rapid application development which is very difficult practically and the process is more difficult to manage need and it’s
Uh needs a very different approach as opposed to the waterfall model remember that the waterfall model has a management techniques like G and NT or the Gant charts to assess now in terms of the software testing life cycle remember that the software testing life cycle consists of six those are that is generic
Phases remember we talked about that the first one is planning analysis then design then construction then testing and then final testing that is uh sorry final testing and implementation and then also post implementation which comprises of each phase of the life cycle that’s described in the respective activities so I’ve
Talked about this before but I’ll I’ll just reiterate this just as a review as part of the life cycle for each one of the phases as relates to excuse me let’s start up with the planning stage planning high level test plan QA plan which is the quality goals identify reporting procedures problem
Classifications acceptance criteria and database for testing measurement criteria for defect quantities severity level and defect origin project metrics and finally begun uh begin the schedule for project testing also plan to maintain all test cases manual or automated in a database and that would be in terms of your
Software like Gyra terms of analysis remember our first phase is planning second phase is analysis now inv analys involves activities that develop functional validation based on business requirements that are writing test case basis on these details and develop test case format terms of time estimates and priority assessments
Also we develop test Cycles in terms of matricies and timelines we identify test cases to be automated if applicable Define area of stress and performance testing app to test Cycles required for the project and regression testing and Define procedures for data maintenance in terms of backup restore and validation and review
Documentation our third stage is design now activities in the design design phase Revis test plan based on changes Revis test cycle matrices timelines verify test plan and cases that are databased or requisite continue to write test cases and add new ones based on the changes develop risk assessment criteria
And formalize details for stress and performance testing then we finalize test Cycles in terms of a number of test cases per cycle based on the estimate per test case and priority and then we finalize the test plan for estimate resources to support documentation in the unit testing then we need to do the
Constructure of the making of the software itself as per the unit test phase we do in the construction is we complete all plans we complete all the plans complete test cycle matrices and timelines complete all test cases uh that is that are manual begin stress and performance testing
Test the automated testing system F bugs in terms of we be fixing bugs that would be in terms of support development and unit testing and run QA uh acceptance test we to verify software is ready to turn over to QA now in terms of our test cycles and
Bug fixes this is for retesting and system testing phase run the test cases that is for the front and back front end and back end we do bug reporting verification and revisor Ed test cases as required for the test cyes and the bug faes for a final testing
Implementation that is for code freeze phase you need to execute all the front-end test cases for manual and automated execution backend of all backend test cases manual and automated execute all stressed and performance test provide ongoing defect uh tracking Matrix provide ongoing complexity and design Matrix and update estimates on
Test cases and test plans document test Cycles regression testing and update then we have post implementation which is our last stage post implementation evaluation meeting can be conducted to review the entire project now the activities in this phase are to Pro prepare final defect report and Associated metrics and to identify
Stages to prevent similar problems in a future project and also the regression testing oh sorry uh project an automation team review test case to evaluate and other cases they automated for regression testing and we need to clean up the automated test cases and variables and then finally we need to
Review process and uh integrating results and automated testings with results from manual testing you might ask yourself what is a bug why do bugs occur well a software bug may be defined as a coding error that causes an unexpected defect fault flaw or imperfection in the computer program
In other words it’s not doing what it’s meant to do or it’s doing something that it’s not meant to do so does not perform as intended therefore is likely a bug there are bugs in the software due to uncleared and constantly changing requirements software complexity programming errors timelines errors and
Bug tracking communication gap documentation errors and deviation from standards here here are some big things deviation from standards unclear or changing requirements software complexity and programming errors mean mean okay so that’s what a bug is in terms of cing now here’s some classifications so oh so here’s here’s elaboration on
These reasons number one we we ALS we want to talk about unclear software requirements this is due to miscommunication as to what the software should or shouldn’t do in many occasions the customer name may not be completely clear as how the product should initially or ultimately function this is especially true when
The software developed a completely new is developed for a completely new product such cases usually lead to a lot of misinterpretations from any both sides this is where you got to get your the scrum Master the owner those people be very clear on what it should do and what should
It so what are what are its Operational wouldn’t say guidelines but what is our operational parameters and means it should be able to do between A to B but not B to C not C to D and so and the other reason is constantly changing software requirements it causes a lot of confusion and pressure both on the
Development and testing teams often a new feature adding added or existing feature removed can be linked to other modules or components in the software overlooking such issues can cause bugs also fixing a bug in one part or SL component of the software might arise in another different or same
Component lack of foresight anticipating such issues can cause serious problems and increase in bug count this is one of the major issues because which bugs occur since developers are very often subject to pressure related to timelines frequently changing requirements increasing number of BS Etc other reason for this is that you’re designing or
Redesigning now in this process that relates the user the UI or user interface inter kind of UI interfaces this just UI user interfaces integration of modules database management and these add to the complexity of the software the system as a whole we also have fundamental problems with the software design and
Architecture can cause problems in programming develop softwares develop software is proner as programmers can make mistakes too as a tester you can check for uh data reference SL declaration errors control full errors parameter errors and input output errors those are things you can reference next uh reason can be rescheduling of
Resources or redoing or discarding uh already completed uh that is for already completed work this causes changes in hardware and software requirements that can affect the software too assigning um new developer to the project in Midway can cause bugs this is possible if Pro uh proper coding standards have not been followed
Improper code documentation in ineffective knowledge transfer Etc discarding a portion of the existing code might might just leave its trail behind in other parts of the software overlooking or not eliminating such code can cause bugs serious bugs can especially occur with larger prodcts as it gets tougher to identify the problem
Area because you have to eliminate what part of the software is causing um our other reason for this errors is programmers usually tend to rush to the deadline or Rush as the deadline approaches closer it’s the old phrase Hast makes waste this is the time when most of the
Bugs occur it is possible you’ll be able to spot bugs of all types and severity that’s a that’s a management issue because what they should do is they should on on they should always have a certain amount of work done per day and not try to do it all in in one
Week one month should have a steady amount of work being done we also have complexity in keeping track of all the bugs that can cause bugs by itself this gets harder when a bug has very complex life cycle for example the number of times it has been closed reopened not accepted
Ignored or goes on increasing let’s talk about the bug life cycle bug life cycle starts with the unintentional software bug behavior and ends when the assigned developer fixes the bug that’s from beginning to end a bug when found should be communicated and assigned to a developer
That can fix it once fixed the problem should be retested also confirmation should be made to verify if the fix did not cause problems elsewhere in most cases the life cycle gets very complicated and difficult to track making imperative to have the bug defect tracking system in
Place for more information talk we can talk will defect tracking at another time now here are some statuses in terms of this so following our different phases of of a bug life cycle remember when we have open a bug is an open State when the tester identifies a problem area next one is
Accepted the bug is then assigned to a developer to fix the developer then accepts if valid not accepted or won’t fix if the developer considers the bug as low level or does not accept it as a bug thus pushing it to not accepted it won’t fix
State such bugs will be assigned to a project manager who will decide if the bug needs a fix not if it needs it’ll be assigned to developer if it doesn’t it assigns back to the tester who may have to close the bug you also have a pending St ST which
Is a bug accepted by developer may not be fixed immediately in such cases it may be put under the pending State programmer will fix the bug as and resolves it as fixed we also have the Clos status which the fixed bug will be assigned to a tester will put it in the close
State then we also have reopened fixed bugs can be reopened by by testers to case in case the fix produces problems elsewhere here’s a graphic representation of the cycle now the image below clearly shows the bug life cycle and how the bug can be tracked during the bug bug tracking
Tools so BT bug tracking tools if we start at the beginning we talk about developer obviously the developer accepts and fix the bug bug is fixed and it goes to the Tester the tester verifies to close the bug then it goes to the um then the tester posts the bug to the
BTT then he closes the bug now from that phe BTT manages all bugs from BTT goes to developer in this case developer does not accept it as a bug and we have conflicts this happens here bug is now considered as a conflict that should be resolved by the application
Manager application manager then views the bug and decides if is fixed or closed those are your stages then from the application manager go back to the testing bug should be closed now at this point and tester verifies if it closes the bug then of course you can go back to
BT also the developer of course from BTT also can developer views the bugs description and it will go go to the developer right developer accepts for the bug bug is fix and goes back to this tester which goes back to the BT to close the bug and so on and so cycle
Like a infinite Loop cycle as we talked about there’s a cost of fixing bugs cost s logiic they increase in size tfold as time increases a bug founded and fixed during the early stages of of the those of the require ments bug spec stage can be fixed by a
Brief interaction with the concerned and might not cost might cost next to nothing during coding a swiftly spotted mistake may take only a very less effort to fix it to fix during integration testing cost the paperwork and bug report as formally documented fix as as well as delay and response to the
Retests during system testing it cost even more time as at mday May deliver delivery delay delivery failing during operations may cause anything from a nuisance to a system failure possibly with catastrophic consequences of a safety crucial system such as aircraft or emergency service what can testing be when can
Testing be stopped or reduced it is difficult to determine what exactly uh when exactly the stop testing here are a few common factors that help you decide when you can stop or reduce testing number one are the deadlines that is the release deadline the testing deadlines Etc then we have
The test cases completed the certain percentage passed test budget depleted coverage of code functionality requirements reaches at a specified Point bug rate Falls between below a certain level beta or Alpha Testing period ends so third major uh categorization is a software testing levels types terms and definitions terms of our uh testing
Levels and types remember that there are basically three levels of testing for example unit testing integration testing and system Tes various types of testing come lines are these three levels so first of all we have our unit testing to verify a single program or a section under the single program then we
Have the integration testing to verify interaction between system components for prerequisite unit testing com uh complete on all components that com compose a system then we have system testing to verify and validate behaviors on the entire system against the original system objectives software testing is a process that identifies the correctness completeness
And quality of software following is a list of various types of software testing and their definitions in random order first one is the formal Testo this is performed by the test Engineers informal testing informal testing is performed by the developers programmers and manual testing is part of the software testing
Requires human input analysis and evaluation also we have the automated testing now automated testing involves software testing that utilizes a variety of tools to automate the testing process automated testing still requires a skill quality assurance professional with knowledge of automation tools and software being tested to set up the test
Cases then we have blackbox testing which we talked about in previous lectures blackbox testing is a testing software without any knowledge of the back end of the system structure or language of the model that is being tested blackbox testing uh te excuse me blackbox test cases are written from a definitive
Source document such as a specification or requirements document then we have white box testing which we also talked about before which is testing in which a software tester has a knowledge of the backend structure in language of the software or at least excuse me or at least its
Purpose then we have the unit testing unit testing it’s a process of testing a particular compiled program for example a window a report a interface Etc independently as a standalone component program types and degrees of unit test can vary among modified and newly created programs unit testing mostly is
Performed by the programmers who are responsible for the creation of necessary unit test data incremental testing incremental testing is a partial testing of an incomplete product the goal of incremental testing is provide an early feedback of soft to software developers and we have the system testing system testing is a form of
Blackbox testing the purpose of system testing is to validate an applications accuracy and completeness in performing functions as designed then we have the integration testing testing two or more modules or functions together with the intent of finding interfaced effects between modules and functions then we have the system integration test testing of software
Components that have been distributed across multiple platforms for example client web server application server and database server could produce failures caused by the system integration defects that is defects involving distribution in the back then we of course have the functional testing which is verifying the the module functions as stated in
The specification and establishing confidence that the program does what it’s supposed to do and we have end to end testing which is similar to system testing which is testing as simple or excuse me testing a complete application in a situation that mimics real world use such as interacting with a database
Using network communication interacting with other Hardware application or system then we have a sanity testing and Sanity testing is performed whenever cursory testing is sufficient to pursue the application is functioning according to specification this level testing is a subset of regression testing is normally includes testing GUI functionality to demonstrate
Connectivity to the data application servers printers Etc we talked about before regression testing now let’s testing with the intent of determining if bug fixes have been successful and have not created any new problems terms of acceptance testing as testing with a system with the intent of confirming
Readiness of the life excuse me of the product and customer acceptance also known as the user AC uh acceptance testing or uat and then we have ad hoc testing testing with a formal test plan or outside of for formal test or outside of a test some project the type of testing
Carried out is an addition carried out in addition to the formal testing sometimes if a testing occurs very late in development cycle this will only this will be the only kind of testing that can be performed usually done by skilled testers sometimes ad hoc testing is referred to exploratory
Testing we have the configuration testing testing to determine how well the product works with a broad range of Hardware peripheral equipment and configurations as well as different operating system systems and software which is quite F then we have the load testing which we’ve talked about before as well which
Is testing with the addent of determining how well the product handles competition for system resources the completion may come in the form of network traffic CPU utilization or memory location stress testing testing done to evaluate the behavior when the system is pushed beyond the breaking point the
Goal is to expose the weak Lings and determine if this system manages to recover gracefully we also have performance testing performance testing is testing with the intent of determining how how efficiently a product handles a variety of EV events automated test tools geared specifically to test and to fine-tune Performance are used most
Often in this type of testing then we have the usability testing usability testing is a test for user friendliness a way to evaluate and measure how users interact with a software with a product software product or site test are given to users and observations are made do have installation testing that’s testing with
The intent of determining if the product is compatible with a variety of platforms and how easily it installs then we have the recovering error test this is testing how well all system recovers from crashes Hardware failures and other catastrophic problems then we have the security testing it’s testing a database and network of
Software in order to keep company data and resources secure from mistaken SL accidental users hackers and other malevolent attackers penet penetration testing uh penetration testing is is how well the system how well the system is protected against unauthorized internal external access or willful damage this type of damage ALS usually require sophisticated testing
Techniques notability testing is testing used to determine how excuse me this used to determine whether other system software components such as browsers utilities and competing software will conflict with a software being tested now we talked about exploratory testing from from the last lecture just as a reminder exploratory testing is any
Testing which a tester dynamically changes what they’re doing for the test execution that is based on the information they learn as they’re executing test it’s kind of sort of like figuring out as you’re going along in comparison uh in comparison testing that is the testing that compares software weaknesses and
Strengths to the those of the competitors products and then we have the Alpha Testing which is towards at the end the testers after code is mostly complete or contains most of the functionality prior to reaching customers sometimes a select a group of users are involved more often the testing is performed
Inhouse or by an outside testing firm in close cooperation with the software engineering department we have the beta testing testing after product code is complete B are often wildly uh distributed or even distributed the public at large and that’s basically like they get a a a initial or sneak peek at what the
Program would look like before it’s before they’ve uh it’s sort of like um yeah it’s a sneak peek or initial look at the software before it’s distributed to everybody but only to a small um oh be oh excuse me testing after the product code uh product code is complete
There often they distributed okay yeah um yeah but sometimes they they use that as in only a certain amount of them but not all of them gamma gamma testing is a testing of software that has all the required features but did not go through the all the inhouse quality
Tricks mutation testing is a method to determine uh to test thorness by measuring the extent in which the test case can be discriminate the program from slight variance of the program independent certification and validation IV andv the process of exercising software intent of ensuring that the Software System meets its requirements
And its user expectations don’t fall in the unacceptable manner the individual or group doing this work is not part of the group organization that develop the software and and finally we have the P we have a few more test testing ones which is pilot testing that is involves the users
Testing that involves the users just before the actual release to ensure that the users become familiar with the release contents Al and ultimately accepted typically involves many users conducted over a short time period of time and tightly controlled which is similar to the beta testing and parallel on audit testing
Testing where the user reconciles the output of the new system to the output of the current system so making that comparison verify whether this the new system performs the operations correctly glass box and open box testing for the glass box testing it’s the same as white box testing which means that
You can see back end his testing approach examines all the application and program structure and deres uh test cases from the applications programs logic then we have the close box testing close box testing is the same as blackbox testing type of testing that consists only uh cons considers only the
Functionality of the application does not know the back end and we have the bottom up testing and it is a technique for integration testing remember it’s a technique integration testing the test engineer creates and uses the test drivers for components that have not been developed and is because the bottomup
Testing lowlevel components are tested first the objective of bottomup testing is to call low-level components first for testing purposes basically like you would do first and then finally you have the smoke testing smoke testing is a random test conducted before the delivery and after that you complete this so sort of
Like in uh production terms is pretty pretty much like a random random sampling now our terms we should remember is bug which we talked about before what a bug is remember that’s a coding error that causes unexpected defect flaw alter flaw in other words a program does not perform as intended
Remember error is a mismatch between the program and specification okay that’s an error in the program terms of a defect defects is a variance from the desire product attribute it can be wrong missing or extra data it can be two types defect from the product from variance from the
Customer user expectations it is a fall from the uh Software System and has no impact until it affects the user SL customer operation system 90% of all that defects can be caused by process problems failure is a defect that causes an error in operation or negatively impacts user custom while the Assurance
Is oriented towards preventing defects quality assurance ensures all parties concerned with the project adhere to the process and procedures standards and templates and test Readiness reviews quality control as you can imagine from the Title Here quality control otherwise known as quality engineering a set of measures taken to ensure that defective products and
Service are not produced that the design means performance requirements also you have your verification under testing terms now remember that verification ensures the product is designed to deliver all the functionality to the customer typically re reviews and and and meetings to evaluate documents excuse me typically involves reviews and
Meetings to evaluate documents plans codes requirements and specifications this can be done with checklists issues list walkthroughs inspection meetings and validation and validation ensures the function as defined by arms it is the intended behavior of the product validation typically involves testing takes place after verifications let’s talk about the most common software
Errors following are the most common software errors that you that Aid you in software testing this helps you identify what errors systematically and increases the efficiency and productivity of software testing now the types of eror um the types of errors with examples first we have the user interface errors
Missing wrong uh Missing or wrong functions that don’t do what the user expects which is pretty straightforward it can be missing information misleading confusing information wrong content and help texts inappropriate error messages performance issues or responsiveness can’t redirect output inap appropriate use of the keyboard okay the other one is error handling so
We first one is user interface errors this one is error handling this is inadequate protection against corrupted data test of user input Version Control ignores overflow data comparison error recovery AB boarding errors recovered from Hardware problems you have boundary related errors boundaries are loot space time memory mishandling of cases outside of
The tell me of the calcul errors that is logic add arithmetic out data can constants calculation errors incorrect conversions from one data represent to another wrong formula incorrect approximation initial and later stages failure two set data item to zero initialize the loop control variable it is a failure to initialize Loop
Control this is where initial and later States or reinitialize the pointer to clear a string or flag incorrect initialization for control flow errors we have wrong returning State assumed exception handling based exist stack underflow or overflow which is Big failure to block or unblock interrupts comparison sometimes yields
Wrong results and missing a wrong default or data type of erors erors in handling or misinterpreting thata unterminated n strings overwriting a file after an error exit or user then we have race conditions assumption that one event or task is finished before another one begins as for resource raises task
Started before prits are m message Cross or doesn’t arrive in the order sent load conditions required resources are not available no available large memory area low priority test not put off don’t erase old files or mass storage and doesn’t return unus memory in terms of our Hardware have the wrong device device unavailable
Underutilizing device intelligence misunderstood uh status or return code wrong operation or instruction codes The Source version and ID control that’s no title or version ID fail to update multiple copies of data or program files and then finally we have we have the testing errors the testing errors
Failure to notice or report a problem failure to use the most promising test case corrupt the data files misinterpreted specifications or documentation failure to make a clear how to re reproduce a problem failure to check of the unresolved problems just before release and failure to verify fixes the
Failure um to provide a summary report now let’s talk about our fifth aspect that is the the planning process so for each step it has its own process so in each step what happens in each step so in the planning so the the test planning process that is what is a test
Strategy and where its components well we have the following here first one we have is the test policy a document characterizing organization’s philosophy towards software testing we have test strategy high level document defining test spases and to be performed in testing within those phases of the program defines the process that can be
Followed in each project this set is the standard is standard for processes documents activities that should be followed by each project for example if the project is given for testing you should be able to decide if it’s better to use black box testing or white box testing and if
You decide to use both when will you apply each one when you when will you apply to you to apply each and to what part of the software all these details need to be specified in the test strategy for test uh for project test plan that is a
Document defining the test phases to be performed and the testing Within the phases of for the particular project test strategy should cover more than one project and should address the following issues an approach to testing high-risk areas first planning for tests how to improve the process based on previous testing environment SL dat
Used we have test management configuration management problem management what metries are used what test will be automated if if which tools are used oh sorry will the test be automated and if so what tools will be used what are the testing stages and testing methods post testing uh to post testing
Review process in templat is almost accom test planning needs to start as soon as as the project requirements are known the first document that needs to be produced is the test strategy testing approach that sets high level approach and testing covers all elements mentioned above for the test planning and sampa
Structure once the approach is understood a detail test plan can be written usually this test plan can can be written in different styles test plans uh can completely differ from Project to project in the same organization i e software test documentation s uh STD or standard
82999 test plan and it’s purpose this is a sample structure for test planning purpose to describe the the scope Approach Resources uh and schedule test planning activities to identify the items being tested the features to be tested and the and the testing task to be performed Personnel responsible for
Each task there is associated the plan terms of its outline that is a test plan should have the following structure that is the test plan identifier the unique identifier assigned to the test plan introduction which is summarize software items and features to be tested
In the name uh and the need for them to be included terms of our test items we identify the test items that that uh are trans midal media which impact their fe uh impact the features to be tested features not to be tested the approach items pass fail criteria suspension criteria and resumption
Requirements and test deliverables you have testing tasks environmental needs responsibility Staffing and training needs schedule risk contingencies and approvals and for the major test planning tasks like any other process of the software testing major tasking the planning uh test planning are to develop use strategies critical success spelles
Define test objectives identify need uh test resources find test environment and Define test procedures identify functions to be tested identify interfaces with other systems of components and write test scripts Define test cases design test data build test M Matrix determine test schedule assemble information and finalize the plan in that
Order then we have the test case development now a test remember that a test case is a detailed procedure that fully test feature or aspect of a feature while the test plan describes that what to test a test case describes how to perform a particular test you
Need to develop test cases for each listed in the test plan in terms of the general guidelines as a tester the best way to determine the compliance of the software to requirements is by designing effective test cases that provide a thorough test of a unit various test cases design
Techniques enable the tester to develop effective test cases besides implementing the the design techniques every tester needs to keep in mind General guidelines that will Aid the test case design uh the first one is the purpose of each test case is to run uh run the test in the simplest way possible
Uh so you need to consider the suitable techniques specification derive tests and equivalence partition then we have the concrete oh excuse me we need to concentrate initially on positive testing for example the test case should show that the software does what is intended to do in terms of suitable techniques specification derived tests
Equivalence partitioning and state transition testing also we have that the existing test cases should be enhanced and further test cases should be designed that is to show that the software does not do anything it’s not specified to do for example negative testing terms of its suitable techniques air guessing boundary value analysis internal
Boundary value testing and state transition history also where appropriate test case should be designed to address issues such as performance safety requirements security requirements in terms of the suitable techniques and specification derived test further test cases can be added to the unit test specification to achieve specific test coverage
Objectives once coverage tests have been designed the test procedure can be developed and the test executed that is for the suitable techniques the branch test T in condition testing data definition use testing and state transition let’s talk about the test case in terms of its sample structure
Remember that the manner in which test cases depicted varies between organizations so it’s not going to always be the same for every organization many test uh case templates are in the form of a table okay that’s the form you look at for example a five column table with Fields
Here is an example we have the test case ID test case description test dependency setup user uh data input steps expected results and pass and fail the test case design techniques well the test case design techniques are broadly grouped into two categories which is the Black Box techniques and the white box
Techniques we talked about well we got black box and uh and white box te and other techniques that don’t fall into either one of the category remember with a black box which is functional versus white box which is structural for Black Box this a specification derived on test equivalence partitioning B value
Analysis and state transition in contrast the white box struct uh is structural which indicates the Branch Testing condition testing and data definition for the use testing internal boundary the data definition in terms of its use testing and also its internal boundary value for other you have error gessing now remember that for
Specification derived tests as a name suggest the test cases are designed walking through that is what walking through the relevant specifications is a positive test case designed at for equivalence partitioning it’s a process of taking all of the possible test values and placing them into classes remember we talking about
Partitions and groups test case should be designed to test U one value for each class thereby using the fewest test cases to the maximum input requirements for example if a program accepts inur values only from 1 to 10 the possible test case each program would range
It would would be the range of all its integers in such a program all the integers of up to zero and above 10 would cause an error so it’s re so it’s reasonable to assume that 11 would fail all the values would fail in vice versa
An input condition is a range of values let the one valid equivalence class in the range 0 to 10 for let the values below and above ranges be two respective invalid equivalency values such as not minus one and 11 because that’s either below or above therefore the above partition
Values can be used as test cases excuse me the above three partition values can be used as test cases then we have Bounder value analysis uh this is a selection technique where the test data is chosen to along the boundaries of the input domain of the output
Range this technique is also called a stress testing and it incorporates a degree of negative testing in the test design by anticipating errors that occur in or around the Partition boundaries um so basically we have um a field required to accept amounts of monies for example you can have one
Example program that accepts amounts of monies we have a range between Z and 10 as a tester you’ll need to check if it uh means up up to up to including 10 and 9.99 and if 10 is acceptable so the boundary values are 0 0.01 9.99 and 10 which is right
Before and at the boundary so that’s the end of it and right after the end of it sorry sorry at the beginning and right after the beginning and right before the end of it and the end here the state transition testing test case is designed to test the transition between the states
Creting the events that cause the transition we have the Branch Testing and Branch Testing test cases are designed to exercise control FL branches or decision points in a unit this is usually aimed at achieving a Target level of the decision coverage Branch coverage and need to test U both branches of if El
LS all branches are in compound conditions for example loops and array handling which the branch should be exercised at least once we have the condition testing an object of condition testing is designed test cases to show the individual components of logical conditions and combinations of the event of individual components that they are
Correct test cases are designed to test individual elements of logical Expressions both with the branch conditions and within the expressions in a unit then we have data defining definition for the unit testing and data definition of the unit testing test cases uh it purpose is to test pairs of the data definitions and
Uses test def test definitions and anywhere of the value of the data item is set data use is anywhere that a datam item is read or used objective is to create test cases that will drive execution through the pass of specific definitions and uses then we have in internal boundary
Value testing in many cases partitions and boundaries are identified from the functional and specifications of unit as described under the equivalence partitioning or boundary value analysis above however a unit may have internal boundary values can only be defined as a structural specification then we have error guing
Is a test case that design technique where testers use their experience to guess possible errors that might occur when the designed test cases are Ur and design test ACC uh cases accordingly and cover them using any combination of the above described as test case design techniques you can
Develop effective test cases and we want to talk about a unit case excuse me use case the use case describes systems Behavior under various conditions and how it responds to requests from one of the users a user initiates the interaction with the system to accomplish the same goal difference sequences or behavior
Scenarios can unfold depending on the particular requests made and the conditions surrounding the requests used cases collects together those different scenarios use cases are particularly large because they have they tell Coran stories about the system how they will behave in use users of the system go to
See just what the new system will be and react early and we have defect tracking so you might ask yourself what is the defect well it’s pretty straight for as discussed earlier defect is a variance of a desired product or Ed attribute that can be wrong or missing
From the or extra data it can be of two types defect from the product or variance when the customer uses expectation is a flaw in the software system that has no impact until it affects the user customer’s operational system so you might ask yourself what are the categories for the
These with the knowledge of testing um so far gained you can now be able to categorize the defs that you found defects can be categorized in different types basing on the core on issues to be addressed or they that they can address some defects address security or
Database issues While others may have uh functional UI issues for security defects application security defects generally involve improper handling or data sent from user to the application these defects are the most severe and highest priority for fix some examples are authentication accepting invalid username password or authorization accessibility Pages without permission
Given then also we have data quality in database defects deals with improper handling of data in the database for examp here are two examples values not deleted or insert in the database properly or improper wrong or null values inserted in the place of actual values then we have critical functional
Defects the occurrence of these bugs hampers The crucial functionality of the application for example we have exceptions we have functionality defects these defects affect the functionality of the application pretty straightforward highlight it anyway for example JavaScript eror all JavaScript errors buttons like save delete cancel not performing their intended functions
A missing functionality or featured not functioning the way intended or continuous execution in terms of our user interface effects as a name suggest deals with problems related to the UI that’re usually are considered less ofe for examples improper erroring UI messages spelling mistakes and alignment of Errors so you might ask yourself well
How how you going to report or how are defects reported once test case is developed using the appropriate techniques there are executed which the bugs occur very it is very important that these bugs be reported as soon as possible because the early report a bug the more time remains
For the schedule to get it fix fix as we been talking about before or as we talked about before simple examples that report of wrong functionality talking in heal file few months before the product release the chance will be fixed are very high if you report the same bug few
Hours before the release odds are won’t be fixed the bug is still the same as you reported a few months or a few hours before the release but what matters is the time so it’s when you report error and the time to of course fix the
Error it is not just enough to find the bugs there should be reported communicated clearly and efficient efficiently not to mention the number of people will be repeating or excuse me reading then we want to consider that defect tracking tool that we’re going to be using also known as bug tracking
Tools um issue tracking tools or problem trackers is pretty much referring to the same thing greatly Aid the testers in reporting and tracking the bugs found software applications they provide means of consolidating a key element of project information and one place project managers can see which bugs have
Been fixed which arees understand how long it’s taking to fix effects Senior Management can use reports to understand the state of development process you might ask yourself how descriptive should your bug or defect report be you should provide enough detail while reporting the bug by keeping in mind the people who will use
It in terms of a test lead development project manager or other testers new testers assigned Etc that means that your report will write should be concise straight to the history and clear here these are the details that it should contain bug title the bug identifier in terms of the ID number
Etc the application name identify in version the function module feature object screen were occurred environment OS browser inversion bug type category severity and priority and for that we have three sub categories three sub considerations one for this bug category which is security data security database functionality for functional critical or general and eui
Also for bug severity that is the severity which with the bug will have effects application very high high medium low or very low and then ter and then we have the bug priority which is recommended priority was given to fix the bug p 0 P1 2 P3 P4 P5 and and P zero
Is highest and P5 is lowest then we have the bug status open pending fix closed or reopen this case number uh number and identifier bug description steps to reproduce actual result and tester comments now what does the tester do when the defect is fixed once the reported defect is fixed the
Tester will need to retest to confirm the fix itself this is usually done by executing the possible scenarios in which the bug can occurred once testing uh retesting is complete the fix can be firm and the bug can be closed this marks the end of the bug
Life now in terms of types of test uh test reports the document outlin in I standards of software for test documentation covers test planning test specification test reports here are some of the criteria that they have um test reporting covers four document types as number one is the test item
Transmittal report identifies test items being transmitted for testing from the document to the testing group in the event of a formal beginning of test is executed details to be included report are the purpose outline transmitt report identifier transmitted items location status and approval the second one is test
Log used by the test team to record what’s occurred during the test execution details include records purpose outline test log identifier description activity event entries execution description and procedure results reonal information anomalous events incident V offs third one is a test incident report describes any event that occurs during the test
Execution that of course requires further investigation uh details to be included in the report is purpose outline test incident report in identifier summary in in and then we have the test the fourth one is the test summary report summarizes all the test activities associated with one or more of the test design
Specifications these ELD to be including reports purpose outline test summary report identifier summary variances comprehensive assessment summary of results summary of activities and improvs and for software test automation nearing the end of this automation Tes is different from program uh from programmer using coding language to write programs to automate manual
Process oh it’s no different yeah so it’s the same idea you’re just writing a program to automate the process one of the problems with testing large systems that goes beyond the scope of the small test teams because only a small number of tests available uh are available the
Coverage and depth testing providers are inadequate for the test they hand expanding the test team Beyond a certain size also becomes problematic the increase of work overhead feasible way to avoid this without introducing a loss of quality is through appropriate use of tools that can expand individual’s capacity enormously while maintaining
The focus and depth of testing upon the critical elements kind of talked about this before but in more detail here considering the following factors that help determine the use of automine testing tools well here are some purposes to examine your current testing process and determine if it needs to be
Adjusted for automated test tools be prepared to make changes in current ways to perform testing involve people need to use the tool to develop the automated testing process create a set of evaluation criteria for functions that will you want to consider use automating test tool some criterias for are for the
Following we have the test repeatability criticality risk applications operational Simplicity ease of automation level documentation of function requirement Etc also we have you also need to remember to examine your existing set of test cases and test script to see what which ones are most applicable for test
Automation and of course you need to train people for basic test finding skills we have some approach approaches the test automation we have the full manual partial Automation and full automation full manual we have Reliance on manual testing responsiv and INF flexible inconsistent low implementation costs High rep repetitive
Costs required for Automation and lows scale requirements for partial automation we didn’t see possible but requires duplication of uh effort flexible consistent automates repetitive tasks and high return tests full automation Reliance on automated testing relatively inflexible very consistent High implementation cost economies a scal as repetition regression Etc and has high skill requirements
And here we have the same thing same thing as what we just said that here all right now for choosing the right tool we need to take the time to Define tool requirements in terms of technology process applications people’s School skills and organization during tool valuation prioritize what test types are
Critical to your success in judge the candidate tools on those criteria understand the tools and their tradeoffs you may need to use multi-tool solution to get higher levels of test type coverage for example you’ll need to combine the capture playback tool with a loud excuse me with a low test to cover
Your performance test cases will involve potential users in the definition of tool requirements and evaluation criteria and building an evaluation scorecard to compare each Tool’s performance against a common set of criteria then you rank them in criteria excuse me then you rank the criteria in terms of the relevant
Importance of the organization so it’s basically like by priority and the importance our top 10 challenges is software test automation buying the wrong tool inadequate test team organization lack of management support incomplete coverage of test types in this selected tool inadequate tool training difficulty using the tool lack of basic test
Process understanding what to test lack of configuration and management process lack of tool compatibility interruptibility and lack of tool availability number 10 introduction of software standards so we have compatibility mature maturity model developed by the software community in 1986 with the leadership of SEI the CMM uh contributes or in this case describes
It the principle in uh practice is underlying the software processes maturity it is intended to help software organizations improve the maturity of their software process in terms of The evolutionary path from ad hoc chaotic processes to mature disciplined software um processes that focus is on identifying key process areas and Exemplar process
That comprise a discipline software process so you may ask yourself what makes up the CMM the CMM is organized in five maturity levs one is initial repeatable so it has to be initial repeatable defined manable and un except for level one each maturity level de uh decomposes into several key process
Areas that indicate the areas of organizations that should focus on to improve its software process so for level one that’s the initial discipline process that is for the standard consistent process predictable process and continually improving process in level two we have repeatable which is the Key Practice areas environments management software
Project planning software project tracking and oversight so software subcontract management software quality assurance software configuration Man level three Define is a key practice areas organization practice uh process Focus organization process definition training program integ created software management software product engineering Intergroup coordination and peer reviews level four you have a manageable
Which is the Key Practice series we have quantitative practice uh Process Management and software quality management level five that’s optimizing and for its Key Practice areas we have defect per vention technology change management and process change management then we have two two last things which is Six
Sigma now Six Sigma is a quality management program to achieve the Six Sigma quot levels of quality it was pineur by Motorola in the mid 1980s and has spread to many other manufacturing companies notably General Electric or GE Six Sigma is a rigorous and disciplined methodology that uses data
And statistical analysis that you measure and improve a company’s operational performance by identifying and eliminating defects that is from manufacturing to transactional from product to service commonly defined as 3.4 defects per million opportunities which is pretty standard it’s usually two to three same thing in uh manufacturing Six Sigma can be defined
And understood with three distinct levels that is matric methodology and philosophy in terms of its training Six Sigma process of executed by Six Sigma Green belts Six Sigma Black belts and overseen by Six Sigma masses or black belts it’s kind of a cute way of putting it and for the iso now ISO
Stands for inter International Organization for standardization is a network of national standards and Institutes of 150 countries on the basis of one member per country the central secretary at Geneva holds and coordinates in the system ISO is a non-governmental organization ISO has developed over 13,000 organizational standards or excuse me 13,000
International standards on a variety of subjects that will do it oh say sorry we have one more left over sorry too early um our last one sh I didn’t one we have two left two quick ones we have our certifications certifications for software QA and test uh Engineers let’s
See csq and asq which is American Society for Quality program and CS csq is certified software quality engineer here and this is the information on requirements outline required by body of knowledge listing and for references and more that csq qa/ cs- QA qai which is quality insurance institutes program
For certified software quality analyst and the certified System test engineer certifications we have the ISB S software certifications this the British computer Society maintains a program of two levels of certification that is the ISB Foundation certificate and practitioners then for the istqb certified tester that’s International software tester qualifications
Board and that is the part of the European organizations for quality and software group based in Germany certifications are based on experience training course test and two Lev Foundation and finally we let’s talk about the facts about software engineering um remember that the best programmers are about 28 times better than the worst
Programmers new tools techniques can cause initial loss of product quality the answer to a feasibility study is almost almost always a yes may of 2002 reportar for the National Institute of Standards and uh Technologies are nist one estimates the annual cost of software defects in the United States as 59.5 billion reusable
Components are three times as hard to build every 25% increase in program complexity there’s 100% increase in solution complexity 80% of software work is intellectual fair amount is creative and little is clerical requirement errors are the most expensive to fix during prodution missing requirements are the hardest requirements erors to
Correct air removal is the most timec consuming phase of the life cycle software is usually tested at best at the 55 to 60% Branch coverage level and 100% coverage is still far from enough still far 100% still far okay sure that’s okay rigorous and inspections can remove about 90% of the
Errors before the test case is run maintenance typically consumes about 40 to 80% of the software cost is probably the most important life cycle phase of the software um phe enhancement um represents 60% of the uh maintenance costs and there’s no single best approach for software error removal and
The author says happy speed testing so that itself will conclude our lecture on our beginner’s guide to software testing remember we talked about our the overview of it the introduction we talked about software testing levels types terms and definitions talk about we’re missing the fourth one um
The test planning process the test case development defect tracking types of test reports and software test automation as well as other little tidbit facts at the end all right I’d like to thank you for taking the time to watch this video as I know it’s valuable to you especially if you
Want to a software tester or just get some more insight into software Tes what I’d like you to do is please CLI the thumbs up or like button on the the video that way I’ll be pushing the algorithm more people be able to view and benefit from
It if you haven’t already please click the Subscribe button that way you have access to all the content on my channel as I do have a variety of content on this channel and then I will have this uploaded to both YouTube and Rumble also if you haven’t already
Please click the Bell button that way you’ll be notified of all my future videos would like to sincerely thank you for taking the time and the patience to go go through and watch this video I wish you a great day wherever you are in the world take care
Video Keywords: Software Testing, [vid_tags]
-
Sale!
Wireless WIFI Repeater Extender Amplifier Booster 300Mbps
$29.99$14.99 Add to cartWireless WIFI Repeater Extender Amplifier Booster 300Mbps
Categories: Electronics, Wi-Fi Router, Wireless Wi-Fi Extender Tags: 300Mbps, 802.11N, Amplifier, Booster, Extender, mobile wi-fi booster, Remote, WIFI, Wireless, Wireless WIFI, Wireless WIFI Repeater, Wireless WIFI Repeater Extender, Wireless WIFI Repeater Extender Amplifier, Wireless WIFI Repeater Extender Amplifier Booster, Wireless WIFI Repeater Extender Amplifier Booster 300Mbps$29.99$14.99 -
Sale!
Full RGB Light Design Gaming Headset Headphones with Mic
$24.99$14.99 Add to cartFull RGB Light Design Gaming Headset Headphones with Mic
Categories: Electronics, Gaming, Gaming Headsets Tags: Design, Full, Full RGB Light Design Gaming Headset, Full RGB Light Design Gaming Headset Headphones, Full RGB Light Design Gaming Headset Headphones with Mic, Gamer, Gaming, Gaming Headset Headphones, gaming headset wireless, Headphone, Headphones, Headset, Light, Mic, Package, RGB$24.99$14.99 -
Sale!
Wireless BlueTooth Multi-Device Keyboard Mouse Combo
$39.99$19.99 Add to cartWireless BlueTooth Multi-Device Keyboard Mouse Combo
Categories: Electronics, Gaming, Gaming Keyboards, Keyboard Mouse Combos Tags: Combo, Keyboard, keyboard mouse combos, Mouse, MultiDevice, Set, WireKeyboard Mouse Combo, Wireless, Wireless BlueTooth Keyboard Mouse Combo, Wireless BlueTooth Keyboard Mouse Combos, Wireless BlueTooth Multi-Device Keyboard Mouse Combo, Wireless BlueTooth Multi-Device Keyboard Mouse Combos$39.99$19.99 -
Sale!
High Back Leather Executive Adjustable Swivel Gaming Chair with Headrest and Lumbar
$199.99$139.99 Add to cartHigh Back Leather Executive Adjustable Swivel Gaming Chair with Headrest and Lumbar
Categories: Gaming, Gaming Chairs Tags: Adjustable, Chair, computer chairs, Desk, Executive, Gaming, Girl, Headrest, High, High Back Leather Executive Adjustable Swivel Gaming Chair, High Back Leather Executive Adjustable Swivel Gaming Chair with Headrest, High Back Leather Executive Adjustable Swivel Gaming Chair with Headrest and Lumbar, High Back Leather Executive Adjustable Swivel Gaming Chairs, Leather, Lumbar, Office, Racing, Swivel$199.99$139.99 -
Sale!
Professional LED Light Wired Gaming Headphones with Noise Cancelling Microphone
$29.99$19.99 Select optionsProfessional LED Light Wired Gaming Headphones with Noise Cancelling Microphone
SKU: N/A Categories: Electronics, Gaming, Gaming Headsets Tags: Cancelling, Gaming, Gaming Headphones with Noise Cancelling Microphone, gaming headset, Headphones, Headset, LED, Light, Mic, Microphone, Noise, Professional, Professional LED Light Wired Gaming Headphones, Professional LED Light Wired Gaming Headphones with Noise Cancelling Microphone, Wired, Wired Gaming Headphones, Wired Gaming Headphones with Noise Cancelling Microphone$29.99$19.99 -
Sale!
Gaming Desk with LED Lights USB Power Outlets and Charging Ports
$349.99$249.99 Select optionsGaming Desk with LED Lights USB Power Outlets and Charging Ports
SKU: N/A Categories: Computer Desk, Gaming, Gaming Desk Tags: and Charging Ports, Charging, Desk, Desks, Gaming, gaming desk with led lights, Gaming Desks with LED Lights, Home, LED, Lights, Monitor, Office, Outlets, Port, Power, Room, Stand, USB, USB Power Outlets, White, Workstation$349.99$249.99 -
Sale!
Wired Mixed Backlit Anti-Ghosting Gaming Keyboard
$99.99$79.99 Add to cartWired Mixed Backlit Anti-Ghosting Gaming Keyboard
Categories: Electronics, Gaming, Gaming Keyboards Tags: Antighosting, Backlit, Blue, brown, Gaming, Gaming Keyboard, gaming keyboards, gaming keyboards and mouse, Keyboard, Laptop, Switch, Wired, Wired Mixed Backlit Anti-Ghosting Gaming Keyboard, Wired Mixed Backlit Anti-Ghosting Gaming Keyboards, Wired Mixed Backlit Gaming Keyboard$99.99$79.99 -
Sale!
Wireless Bluetooth 5.3 ANC Noise Cancellation Hi-Res Over the Ear Headphones Headset
$119.99$59.99 Add to cartWireless Bluetooth 5.3 ANC Noise Cancellation Hi-Res Over the Ear Headphones Headset
Categories: Electronics, Gaming, Gaming Headsets Tags: 5.3 ANC Noise Cancellation Hi-Res Over the Ear Headphones Headset, ANC, Audio, Bluetooth, Cancellation, Ear, Earphone, gaming headset, Headphones, Headset, Hi-Res Over the Ear Headphones Headset, HiRes, Noise, Wireless, Wireless Bluetooth 5.3 ANC Noise Cancellation Hi-Res Headphones, Wireless Bluetooth 5.3 ANC Noise Cancellation Hi-Res Over the Ear Headphones Headset, Wireless Bluetooth 5.3 ANC Noise Cancellation Hi-Res Over the Ear Headphones Headsets$119.99$59.99 -
Sale!
Wired Sports Gaming Headset Earbuds with Microphone
$19.99$9.99 Select optionsWired Sports Gaming Headset Earbuds with Microphone
SKU: N/A Categories: Gaming, Gaming Headsets Tags: Accessories, Earbud, Earphone, Earphones, Gaming, gaming headset with microphone, Headphones, Headset, IOS, Microphone, Sports, Wired, Wired Sports Gaming Headset Earbuds, Wired Sports Gaming Headset Earbuds with Microphone, Wired Sports Headset Earbuds$19.99$9.99 -
Sale!
150W Universal Multi USB Fast Charger 16 Port MAX Charging Station
$49.99$29.99 Add to cart150W Universal Multi USB Fast Charger 16 Port MAX Charging Station
Categories: Charging Stations, Electronics Tags: 150W, 150W Charging Station, 150W Universal Multi USB Charging Station, 150W Universal Multi USB Fast Charger 16 Port MAX Charging Station, 150W Universal Multi USB Fast Charger 16 Port MAX Charging Stations, 150W Universal Multi USB MAX Charging Station, 16 Port MAX Charging Station, 3.5A, Charger, Charging, Fast, laptop charging stations, Max, Multi, Port, Stand, Station, Universal, USB$49.99$29.99