Category: Quality Assurance

Reviewing to start on Work product drafts

Early testing is better for the project in dev and in cost savings.

Each dev level has one testing level

Component integration testing- structural, white box,

Impact analysis is used when deciding if a fix is worthwhile.

Functional testing can be performed at any level (4 levels- unit, integration, system integration and acceptance)

ISTQB foundation does not talk about the non-functional as it's not in scope.

Confirmation testing (retest after the fix has been made) to make sure the issue is not reproduced!

Regression testing is no other parts are impacted by the fix provided in line with the previous statement above (confirmation testing)

impact analysis - fixing the maintenance system is worthwhile.

On Basic words, AB test can be described as a process to allow the team to compare 2 different versions of a feature to learn which is more user friendly and effective and widely used. It helps to derive the business revenue or loss. For Example: Version A or version B? which could be selected based on specific business measures.

Istqb has a new certification for the mobile application testing, it has the necessary info on the general testing requirements and mindset to validate the mobile app Usage of our day to day needs in Mobile devices have thrived in recent years, resulting in better and more efficient mobile as in all aspects of business and industry domains. Validation of the native apps in the Android or iOS devices have increased rapidly. Considerations:

1. Usability/Accessibility/readability
2. Performance/Crash
3. Smoke/Regression/User Acceptance

 

Notes:

1. Create a test plan
   1. View results
      1. Results tree
      2. Results in table
   2. Assertion
   3. Timer
   4. Listener
   5. Thread Group
      1. Ramp up
      2. Ramp down
   6. Heap dump
   7. Enable Debug
   8. HTML Report Viewer
      1. Log Level
         1. Trace
   9. Start->Remote->Stop+All
   10. Test/Sampler-> FTP,HTTP, JDBC, API

Robot framework.org - python based framework - keyword driven approach!
Ex:
open browser url chrome
input text id text info
Close Browser

install on windows OS

1.As a pre-requisite python must be installed in the system you are going to create the automation scripts, once its installed
need to check if pip is available

2. pip install robotframework

3. pip install --upgrade robotframework

4. pip install robotframework==5.0.1

to check if the robot framework is correctly installed, please follow the below commands!
pip freeze

pip list

pip show robotframework

pip check robotframework

If you want to uninstall Robot framework

To check on the version of the Robot framework

robot --version

Set environment variables in the PATH, so python is accessible from across locations in the system from where the code/file is being saved.

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