how QA works

Assembly level languages are basic language model to communicate with computer/calculate
these are used to create Fortran , Cobol, etc..

Basic set of instructions for the computer to understand

Current scenrio, c#, python, java are considered general purpose lanaugaes to all domain

Compiler translates these languages to machine understandable language

Ten the language B was created, then C, which started the rise of general purpose languages, C#, Python, java are considered general purpose languages to all domain

Paradigm of languages came up during the times of 1980’s

procedural oriented programming was followed on Cobol (Business need) and Fortran (Formula Translations)

There were few challenges and complexities, to overcome those,

modular, functional, object oriented programming by the computer scientists and researchers.

C++ was created on top of C and Object oriented concepts was effective but there were few drawbacks,

Compile of C++ was effective but expensive, as for each OS new compilers/translators were to be creaed

Again, to overcome the challenges and drawbacks of C++ while supporting OOPs

One of the main challenge was the cost fr the compilation, Java came with the new approach of breaking down the message translation from the high level(programming) language to machine language.

one smartphone/laptop/Desktop has lets say intel/arm/amd processor, the processor converts the programming language to machine language 0,1 in the proces sit understands

but before that OS will stop in between to check whether the code is what/how it is executed and code quality is correct!

Java team created a approach called CORA, create once run anywhere which made Java Platform independent! – Platform means in the simple words a combo of windows+intel processor Mac+M1 processor etc…

Java program is not compiled directly to machine language (binary -0,1)

Java program is compiled to byte code(intermediate code (user could find it difficult to read and understand easily).

Once this is generated and the user wants it to process/run, this is passed on to JVM – based on the Platform the JVM converts to the binary (machine understandable language) – JVM has a system called a JIT (Just in Time Compiler- also known as Interpreter) .

Compiler – overall program translator (to be updated)

Interpreter– line by line translator- considered faster than the compilers.

Each OS has its own JVM – so the features and the responsibilities of the compiler was split across 2 units bringing down the compilation cost to less on considering to the cost incurred earlier.

SUN Microsystems –Java (James Gosling) and Microsoft- C# and Python

For Ex: Java had the syntaxes similar to C and C++ as the developers were familiar to those, considering java’s one of the feature is considered as SIMPLE, considering python is having easy syntax.

lets say for doing those currently JDK (java developer Kit) is available- The Kit of compiler,

For the OS to understand on checking whether the programming info written int he respective language the concept of SYSNTAX came into picture, COmpiler does this

References:

Dennis Ritchie wiki and master website info.

Let’s see about a sample requirement on an app related to a game tutorial

lets say the app has 2 level of age

2-5

5-10

For 2-5 we have 10 days of coaching and each day has a separate page if instructions and images

Age2-5

Balance

dribble

Slow- dribble

fast-dribble

goal score

pass to the team

play inside the ground

kick the cones

pass to the side of the cones

requiremebt 2

app to sdescribe a option yi

4 glasses of warm water (129 ml each)

1glass of warm water ecery hour except while taking meals your daily water intake must be min of 3000 ml (3litres)

reduce intake of sugar, milk

instead of rice use mullet for food

increase cegetable intake!

follow adiets chart

To be updated!

What is Oracle: RDMS owned by Oracle Corporation, which has different version for its respective customers and community.

1. Enterprise
2. Standard
3. Express
4. Oracle Lite
5. Personal Edition

Lets see few interesting ingo below:

TABLE CONSTRAINTS – use don Create table and alter table – there are 3 constraints – Primary Key, foreign Key, Check. The column constraints are

Create table –

CREATE TABLE schema_name.table_name (
column_1 data_type column_constraint,
column_2 data_type column_constraint,
…
table_constraint
);

Ex: kindly relate/compare the texts and see! below tb.userInfo is the table name and the Column names are id_no, Firstname and the Last name respectively

CREATE TABLE tb.userInfo (
id_no NUMBER GENERATED BY DEFAULT AS IDENTITY,
FirstName VARCHAR(50) NOT NULL,
LastName VARCHAR(50) NOT NULL,
PRIMARY KEY(id_no));

Alter Table:

ALTER TABLE table_name
ADD column_name type constraint;
Ex:
ALTER TABLE tb.userInfo(
ADD COLUMN Address VARCHAR(300) NOT NULL
);

to validate if the above code works, it lists all the column info of the specified table.

Desc tb.userInfo

Create Views

Oracle Clauses

Oracle Operators

Oracle Advance

Oracle Joins

Advanced Oracle

 

Find as many as defects possible after some changes or updates, upgrades, migration etc..

once te ptroject is released there are some timeline for theenext rls- so small updates are made in meanwhile- so maintenance tesitng is done during those mini- releases.

Lots of regression is made during these.

1. Planned Enhancements ex: 1.1, 1.2, 1.3 needs regression
2. COTS Software – Commercial of the shelf – third party software added as new feature integrated with the existing software
3. Migration- One platform to another-> windows to Linux
4. Retired- such as application reaches the end of its life ex: WinX- window sand linux embedded

In all the above cases regression is made!

IMPACT ANALYSIS

• Impact analysis is to check whether the change should be made or not, based ont he potential consequences in other areas of the system

Impact analysis is tough if

1. Specs ae missing
2. Test cases are out of date
3. Bi-directional traceability between tests are not updates
4. Tool support is weak (needs automation)
5. The people involved do not have domain or system knowledge
6. Insufficient attention has bee paid to the software’s maintainability during developers.

Classification of testing

1. Static Testing – non executable – work products test/Review- to find – omissions- missing info-loop holes are the flaws in the document – work product can be any doc in process to create the dynamic application- main purpose is to find defects in the very early stage so avoid defects in the dynamic testing stage.
   Informal- walkthrough- Technical Review- Inspection
2. Dynamic Testing – Executable -Applications under test- validate by running the application
   Functional levels of testing
   1. Unit testing – done mostly by the developers (manual-automation)
   2. Integration Testing
   3. System testing
   4. Acceptance Testing
3. Static testing- Reviews- Verification
4. Dynamic testing – diff levels of testing – Validation
5. Difference between Functional vs Non functional
   Functional – With out core features- application is not conceded as complete- user cannot work on the application – basically its what the system does- to meet the requirement
   Non-Functional – how the system works?
   Quality characteristics- enhance compatibility, portability, reliance, etc, any other than the 4 functional levels are non functional
   Ex: recovery, security, failover – to validate quality attribute.
   Unless client says we will have non functional- so functional testing is non-mandatory.

White BOX

Done by developer by executing the application
Also called as (See through- the code structure etc)
Structure Box,
Glass Box,
Open Box,
Clear Box
Transparent Box

Black BOX

Done by the tester with out knowlege of code and structure ont eh UI created for the customer use!

Also called as (could not see thru)
Skin Box,
Closed Box,
Opaque Box

Change related testing
Adding some maintenance testing with the regular process of the testing
In few companies- they rerun the test as after the fix that us called confirmation testing – to make sure the defect has been resolved- also known as re-testing.

Regression testing is followed after the Re-testing, to make sure the fix does not impact he existing ote modules which are working fine earlier, and not impacted but the new fix added
Regression- is the best candidate for Automation
Also conducted additional when we have environment changes-migration one plat form to other- or new functionality included like updates/upgrades.

Component testing

White box testing- unit test- done by the developer at the ocde level

Test Basis (what creates the component) and Test Objects (what we test)

Test Basis-
Component requirement
Code
Detailed Design

Test Objects –
Component
Programs
Data conversion/migration
Database Modules

Integration Tetsing

interaction between modules

Component Integration Testing – data shares/interacted of components with in module – Site selection- city selection- in address page.

System Integration Testing – a small unit of system- a small transaction in a big application SIT- Several SITs put together for System testing- in few cased SIT can be converted after System testing as well,
EX: Embedded Systems – S/w -H/w or Sw/SW etc..

3 Approaches

TDA – Top Down Appraoch

BUA- Bittom Up Approach

BBA – Big Bang Approach

Test Basis: References for deriving the test cases.
Software and Sytem design
Arctitecture And Workflows
Use Caes

Test Objects

What you are testing
Sub Systems
Dtaa implementatrion
Infrastructure
Iterfaxes
System Config and
Configuration Data

Sytem Testing(K2)

E2E testing of an applciation – to handle the e2e as everyhting works as per business/system requitrments of applciation. we hangle lots of roisk- as once the app is built we can cater teh critical things as part of hte execution.

Test Basis
System,/req specs
Fnc spec
Use case
Risk Analysis

Test Objects
System user operation manuls

System configuration
Config dat

ONce afte te syateme tetsig is done- non functional testing can be started

ACCEPTANCE TETSING

once all teh testinare done- it can be declared tha tclient can come anc collec the app

ISTQB- client comes to dev primises an conducts te acceptance testing int he applciation is called as acceptance testing

Typical

User Acceptance
Operational
Regulatory
Contractual
Business

Client genrally accepts the app- they specify what criteria is met and not met- so typical form of accptanc eis amade

Levels of Tetsing
Alpa Tetsing – tested by the client
Beta testing – to provide the peice ofd app to certain group and collect valuable feedback-must be conducted
(AB Testing)- cetain places- we cannot ask te endusers ex: fantasy park, amusemnt park, aerospace, safety critical- aerospace – so we ask professionals to behave like end users and collect feedback

Test Basis
User Software req spec
Business Process
Use cases
Risk analysis Repot

Test Objects
User Procedures
Business Process, operational ptrocess
Forms
Reports
Configuration data

21. Software Development models

2.2 Test Levels

2.3 Test Types

2.4 Maintenance Testing

2.1 Software Development models
V-Model –Sequential model with each development model having a corresponding testing model and each testing level has a testing objective.
Acceptance testing – while gathering – Business requirement – so loop holes can be found early
System Testing – System requirements- System tests Plan is created- Analysis and design of the test activity
Integration testing – ITP- Architectural design
Component testing – Detailed Design – of the application

Notes:
Should not wait for the testing phase – should not wait for the finalized docs- should start while the drafts – testing team is involved while Business is initiated.

Other methologies/Models

Sequential model – V- Model- once hte previous stage completrs- we move to the next stage

Incremental- Allow to design /analyze and build in features- in a small size and smoot way- no bigger things to be dealt- only small chunk of software

Iterative – On each single iteration- we have the previous set of requiremnt an d ne wset of requiremnt involved- so testng becomes complex and hectic- choas- special measures to be taken care of

Rational Unified Process

Scrum

Kanban

Spiral

Key Areas to be considered to use teh development models

1. SDLC should be selected in terms of project and product characteristics – functionality- Small set of requirements regularly or a frozen set of requirements- risk- have worked on similar applications before etc…
2. SDLC can be combined – Hybrid model – Open to include similar approaches as part of the process
3. IOT- There are devices, products, services- diff methodologies- programming languages- – so all the challenges to be considered before we select a model to start the SDLC.

Test Case – a set of input values – steps to follow for pre-conditions- and post conditions for a particular test condition.

Major objective of testing- to prevent the defects (focus mostly on tester activity and ignore if generally mentioned as it may reflect to all the team members)

Example of failure – UI feature not working as expected from the customer point of view. (Need to see what are debugging steps and what ui issues)

Which of the following is defect and not a root cause – UI issue noticeable by the customer.

Risk Analysis- focus on areas where defects are noticed earlier – defect clustering

Pesticide paradox- repeating same test cases again and again- improvise to new test cases.

test Design – identifying the data to support test cases

Test implementation – prioritizing hte test procedures and create test data

Test Execution – Analyzing discrepancies to determine their cause

Test completion – Entering CR for open defect reports

Traceability-> test basis and test artifacts-? new test cases has increased the coverage of the requirements.

Tester mindset- ability to see what might go wrong

When we talk abt psychology- a different mind set always to find mistakes- for dev its difficult to find mistakes in his own work, its same for any author or creator to find mistakes on his own product.

So we have a separate team with the mindset of finding issues or try to break the system see or bring failures and developer has mindset of creating the content

Generally – developer as a positive approach to the system and its difficult for them to accept the system has a defect, and the tester comes with negative approach to the application.

With few practices- realization of working together in long term , the tester may see all the things negatively and see the people in negative way as well, as if one starts pointing fingers on some one else- one may forget the common goal of the org towards the application

one must have the positive attitude towards people and negative approach to the application- there are few good practices in org in a mix team of dev and tester working together.

Overall +ve mindet and approach wit the colleagues in the team so any issue so the defect created will not create any rift or criticism, WE need to collaborate rehter than battles saying this must have been taken care!

Miscommunication must be avoided- all parties must confirm that the understanding of the issue and all are in same page!

Testers and Developers Mindset

Developers- constructive and complete the functions created on time.

Testers: destructive towards the application- find all possible defects so the end user does not face any challenge!

Advice to developer/tester/BA- reduce mistakes and make use of the static testing so the app is not created wrongly i first place- time, money is saved.

Add lot of value to quality of product.

In the right mindset dev can test their own code- and in general they do not come int heat mindset for ex: Dev may consider the app created as his baby and will not be int he mindset of finding the issue!

Key momnets- no personal rivalry – certain reports must be generic and no pointing fingers that defect is due to the dev work done in a wrong way kind off- instead it must be the issue was noticed ont eh application , need help in this from the developer to fix it!

Being positive with DESTRUCTIVE approach.