Testing Techniques in The Software Development Life Cycle

1. Testing for software engineers
1
BY: MOHAMMED ASHOUR

2. What does “Test” mean in our context?
2

3. SDLC
1- Requirements
2- Analysis
5- Testing
6- Deployment
3- Design
4- Implementation
3

4. What should we test?
Units, Groups, Guards, Performance, Old units working with the new ones
And some other stuff..
4

5. Unit testing
5

6. Here we try to look at the project as some LEGO
pieces stacked to each others forming the final
product, the Unit test goal here is to make sure
that every piece is in a perfect condition on it’s
own
6

7. 7
I/P
I/P
I/P
O/P
O/P
O/P

8. Unit Testing toolbox
- Asserting tools/libraries
- Stubbing and spying tools/libraries
8

9. function sum(x, y) {
if( x == null || y == null) throw new Error("x and y should be
provided!!") //checking if all provided
if(isNaN(x) || isNaN(y))
{
throw new Error("x and y should be Numbers!!") //checking
values
} else{
return Number(x) + Number(y)
}
}
9
Example

10. Example
let sum = function sum(x, y) {
if( x == null || y == null) throw new
Error("x and y should be provided!!")
if(isNaN(x) || isNaN(y))
{
throw new Error("x and y should be
Numbers!!")
} else{
return Number(x) + Number(y)
}
}
10
describe('add function', function() {
it('should return 3 when the add 1 and 2', (done)=>{
expect(calc.sum(1,2)).to.eql(3)
done()
});
it("should throw error!!", (done)=>{
expect(()=>{calc.sum("a", "2")}).to.throw("x and y
should be Numbers!!")
done()
})
it("should throw that we should provide all the
parameters", (done)=>{
expect(()=>{calc.sum(1)}).to.throw("x and y should
be provided!!")
done()
})
});

11. calc
add function
✓ should return 3 when the add 1 and 2
✓ should throw error!!
✓ should throw that we should provide all the parameters
3 passing (18ms)
11
Test result

12. Integration testing
12

13. See it from the outside [Groups]
After testing each unit on it’s own. We
need to test their interaction with each
other, the flow that represent a higher level
function than one unit represents
13

14. 14
I/P O/P

15. Assume that our web api
that have this route /add
listening to our Post
requests
15
let request = require("request")
let chai = require("chai")
let expect = chai.expect
describe("testing the add functionality",()=>{
it("should return response of status 200 and type json
with body 5",(done)=>{
let body = {"x":2,"y":3}
request.post("http://localhost:3000/add",{json:body},(err,
res, body)=>{
expect(res.statusCode).to.eql(200)
expect(body).to.eql({"result":5})
expect(res.headers['content-type']).to.eql("appli
cation/json; charset=utf-8")
done()
})
}) })

16. Security testing
16

17. Testing the security of the app is not mainly the
developer task, there should be a security team that
can perform different kinds of tests that help to
discover these security holes and fix them,
however, a good developer should have some
knowledge about the secure coding habits, and at
least have an idea about the common security
issues and how to avoid them
17

18. OWASP Top 10 list
Open Web Application Security Project :
A worldwide not-for-profit charitable organization focused on improving the
security of software
They publish a lot of materials mainly about software security and security
practices, they also make top 10 list of common vulnerabilities found in the current
online web apps every year
2017 Top 10 list :
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
18

19. 19

20. Checking your dependencies
Checking the packages/versions you use for known bugs or vulnerabilities , you
can use tools like snyk
https://snyk.io/
20

21. Performance testing
21

22. Before making your app live, you need to test its performance in terms of
● Speed (How much it take to respond/operate)
● Load handling (How many requests/operations it can take without going
down)
● The weak points in your system (I/O operations bottleneck ..etc)
● Your system reaction when -Suddenly- a spike hits it
You need to figure out the breaking points of your system and how much load it
can tolerate
22

23. Metric example
{
“Response time”
“Error rate”
“Peak response time”
“Memory/cpu utilization”
}
23

24. Are my tests needs to be tested with other tests?
24
Are my tests good enough?

25. Test quality gates
25
● Code review
● Test coverage
● Writing your tests before you write your code and make sure they all
fail at the first time -> TDD

26. Code review
26

27. Test Coverage
Report Example:
Calc
add function
✓ should return 3 when the add 1 and 2
✓ should throw error!!
✓ should throw that we should provide all the parameters
3 passing (14ms)
----------|----------|----------|----------|----------|-------------------|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files | 100 | 100 | 100 | 100 | |
calc.js | 100 | 100 | 100 | 100 | |
----------|----------|----------|----------|----------|-------------------|
27
Istanbuljs

28. Test coverage report
28

29. After removing a test case
29

30. Test driven development [TDD]
30

31. That was an introduction for the basics, see you soon
in much deeper discussion in each topic
31