I) Document Testing:
In waterfall model or V model or agile model, the first testing stage is document testing.
Here, PO is responsible to prepare all user stories (Product Backlog). The same PO can review those user stories for completeness and correctness.
PO can join with SH’s, SM and ST to select some user stories (Sprint Backlog). The same PO can review SBL for completeness and correctness.
When PBL and SBL are base lined (finalized), ST developers can prepare HLD and LLD’s. HLD(High Level Design) is an overall architecture of entire sprint, whereas LLD(Low Level Design) is an internal logic of specific module in sprint. Due to these reasons, one sprint design is having one HLD and multiple LLD’s.
Same ST developers can review those designs for completeness and correctness.
Case Study:
Walkthrough: Study a document from first to last.
Inspection: Search a document for specific topic/factors.
Peer review: Comparing two similar documents point to point.
Note: The above three document testing techniques are also called as static testing techniques/verification techniques.
II) Unit Testing:
Once HLD and LLD’s base lined, ST developers can start implementing. In this stage, ST developers can write programs and conduct unit testing.
a) Basic Paths Coverage:
Scrum team developers can use this technique to check whether the program is running without run time errors or not.
b) Control Structure Coverage:
This technique is also called as debugging.
Developers can use this technique to ensure correctness of inputs and outputs.
c) Program Testing Coverage:
When a program is correctly working, ST developer can conduct program technique coverage on that program to calculate execution speed.
If execution speed of the program is not acceptable then ST developer can modify that program structure without disturbing functionality.
d) Mutation Coverage:
After completion on previous three tests on program, ST developer can perform changes in those areas for test coverage. Here, mutation means change.
Note: In above four white box techniques, first three techniques can test the program. Fourth technique is used to program test coverage i.e. tested completely or not.
III) Integration Testing:
During coding, ST developers can interconnect programs to build a sprint. The interconnection of programs is also a kind of coding.
During the interconnection of programs, ST developers can follow any one of the below approaches.
a) Top down approach
From this approach, ST developers can interconnect main program and some of the sub program. In the place of remaining under constructive sub programs, ST developers can use temporary program, called as Stub.
b) Bottom up approach
From this approach, ST developers can interconnect sub programs without involvement of main program, because main program is under construction. In the place of remaining under constructive main program, ST developers can use temporary program, called as Driver.
c) Hybrid approach
This approach is a combination of top down approach and bottom up approach.
Note: Above three approaches are also called as incremental integration approaches. Here, driver is calling program whereas stub is called program.
d) System approach / Big Bang approach
From this approach, ST developers can wait until complete implementation is ready to conduct integration.
IV) Sprint Testing / Software Testing:
Once integration is finished, ST developers can release sprint to ST Testers. ST testers can conduct sprint testing with respect to user stories.
During software testing as sprint testing, ST testers can conduct functional and non-functional test.
To release quality software or sprint to customer site, ST testers can conduct functional and non-functional testing both mandatory. In general, quality software meets customer requirement and customer expectations. So, functional and non-functional test are mandatory to conduct.
• Functional Testing
During functional testing, ST testers can conduct below sub tests as sprint or software.
• GUI Testing
GUI stands for Graphical User Interface. This testing is also called as behavioral testing or control flow testing. During this testing, ST testers can operate sprint screen by observing behavior of each element in those screen.
• Input Domain Testing
During this testing, ST testers can check size and type of each field in the sprint screens. This testing is also called as Fuzz testing.
• Error Handling Testing
During this test, ST testers can operate sprint screen by giving an invalid data and observe error message or alert message is displaying or not.
• Output or Manipulation Testing
During this test, ST testers can operate sprint screen by giving valid data and observe correctness or output or outcome.
Note: The above four tests are called as Front End Testing phases.
• Database Testing
During this test, ST testers can operate sprint screen and observe the impact of those operations on database in terms of data validation and data integrity.
From the above diagram, data validation means, new data correctly inserted or not.
Data integrity means, after new insertion of data, existing data updated or not.
• Data Volume Testing
This testing is also called as memory testing or storage testing. During this testing, ST testers can insert model data into sprint database to calculate capacity of database.
Note: Above two tests are called as Back End testing phases.
• Recovery Testing
This testing is also called as Reliability testing. During this testing, ST testers can operate sprint or software in wrong environment and observe that sprint is recovered from abnormal state to normal state.
Ex. Insufficient memory, disconnecting network, restart system suddenly…etc
• Intersystem Testing
This testing is also called as End-to-End testing or interoperability testing.
During this testing, ST testers can validate corresponding sprint or software co-existence with other software to share the common resources.
Ex. database, hardware devices etc
• Non-Functional Testing
After completion of functional testing, ST testers can concentrate on non-functional testing.
This Non-functional testing is also called as expectations testing because ST testers can validate usability, compatibility, hardware configurations, performance, security etc like expectations on sprints or software.
Non-functional testing is also called as system testing because ST testers need entire software or sprint to conduct non-functional testing.
This non-functional testing is having below sub stages.
i) Usability Testing
This testing is also called as Accessibility testing.
During this testing, ST testers can validate user friendliness of sprint or software.
Here user friendliness means
• Ease of use
• Look and Feel
• Short navigations
ii) Compatibility Testing
This testing is also called as portability testing.
During this test, ST testers can run corresponding sprint or software in various customers or client expected platform. Platform means operating system, browser, and other system software’s.
iii) Hardware Configuration Testing
This testing is also called as Hardware Compatibility Testing.
During this testing, ST testers can operate sprint or software by using various hardware configurations.
Ex. Different types of processors, network, printers etc.
Note: If compatibility and hardware configuration testing are not possible in company then ST testers can use simulators or cloud concept to conduct those tests.
iv) Performance Testing
This testing was divided into four sub tests as follows
-Load Testing
-Stress Testing
-Spike Testing
-Endurance Testing
i) Load Testing- Run sprint or software in customer expected configured environment and by applying customer expected load ( number of concurrent users ) to identify speed in process, is called as Load Testing.
ii) Stress Testing- Run sprint or software in customer expected configured environment and by applying more than customer expected load ( number of concurrent users ) to identify peak load or load capacity, is called as Stress Testing.
iii) Spike Testing- Run sprint or software in customer expected configured environment and by applying huge amount of load to identify server crashing point, Spike Testing.
iv) Endurance Testing- Run sprint or software in customer expected configured environment and by applying customer expected load long time to identify memory leakage, is called as Endurance Testing. It is also called as Durability test or longevity testing or Soak testing.
v) Security Testing
This testing is also called as penetration testing. This security testing is divided into below sub tests.
i) Authorization Testing / Authentication Testing
It means whether our sprint or software is allowing valid users and preventing invalid users or not?
ii) Access Control Testing
It means whether our software or sprint is allowing valid users with permissions or privileges to access specific functionalities or not?
iii) Encryption/Decryption Testing
It means whether our sprint or software is strong in encryption/decryption process or not?
Note: In above three security tests, encryption/decryption technique is possible to conduct by ST testers when they have hacking skills.
vi) Multi languity Testing
This testing is also called as Foreign Language Testing. When a sprint or software is to develop using java or .net Unicode technology, this testing is mandatory to conduct.
There are two ways to conduct this testing
-Localization
-Globalization/Internationalization
vii) Parallel Testing
This testing is also called as comparison testing or competitive testing.
During this testing, ST testers can compare corresponding sprint or software with previous version of same software and with competitive software in market to identify weakness and strengths in it
viii) Compliance Testing
This testing is also called as standard testing
During this testing, management people can verify efficiency of ST testers with respect to company standards or policies.
Ex. i) 15 to 20 test scenarios with test cases preparation per day (8 hours)
ii) 10 to 15 test scenarios with test cases execution per day (8 hours)
iii) 3 to 5 defects detection per day (8 hours)
V) Acceptance Testing:
After completion of the sprint or software testing, management can try to get feedback of client on that sprint or software.
There are two ways to collect feedback such as alpha testing and beta testing.
Acceptance testing is also known as Yellow-Box Technique.
VI) Release Testing / Port Testing / Delivery Testing / Deployment Testing / On site Testing:
After completion of acceptance testing, management can select few developers and testers to go to on site or client site.
The selected developers and testers can export or upload sprint or software to client site network and observe below factors.
-Complete Installation.
-Overall Functionality.
-Input Device Support ex. Keyboard, Mouse, Joystick etc.
-Output Device Support ex. Monitor, Printer, Scanner etc.
-Secondary Storage Device Support ex. External HDD, CD-ROM, Pen-Drive etc.
-Co-existence with other software’s.
All above six factors is also called as Green-Box Techniques.
After completion of release testing, corresponding developers and testers can provide training to client site people (End users) on sprint or software.
VI) Testing during Maintenance
Management can maintain CCB(Change Control Board) fresher’s to handle change request from client site in released sprint or software.
Note I: CCB freshers are trained fresher’s, they are able to do changes in coding and test those changes during maintenance of released sprint or software.
Note II: Depends on failures of sprint in client site, management can calculate DRE (Defect Removal Efficiency)
Formula to calculate DRE is,
DRE = (A/(A+B))
Where, A = Number of bugs were found during testing.
B = Number of failures came at client site.
Note III: Reasonable DRE of ST testers is 0.8 to 0.9
Comments
Post a Comment