An overview of software testing

Hi, devs! What are you going to read here? Important points and necessaries for your software testing knowledge.

Let's get start with the 7 principles of software testing described on syllabus CTFL - Certified Tester Foundation Level, BSTQB/ISQTB. This principles was created through over the years.

1 - Testing shows the presence of defects

First of all, the goal of software testing is verify if errors exists but we cannot guarantee that there's no any error even the message says the ours test passed. When we think about TDD, clearly, first the code fail, after is necessary create what is necessary for passing test.

2 - Exhaustive testing is not possible

When we talking about something exhaustive in the computer science we need do pay attention, because that means more complexity. So, it is not different in software testing context, because it not possible a full coverage of whole code and test all possible inputs from users.

3 - Early testing

You know, if you do something early before the thing can become harder, certainly, will be better. Test first already is a rule in the software programming community. Do tests. If the software is already in production, no problem, start in some point for a better future and software life cycle.

4 - Defect Clustering

Pareto principle says that a small number of modules contains most of the defects. In this context, 80% of the problems are found in 20% of the modules.
What helps us here is inversion dependency pattern, because the external modules can access our layers just through interfaces that will be done with test first.

5 - Pesticide paradox

If you repeat the same thing will hope a different output? Absolutely not. So, if we always have the same test so we not going to find new bugs. Here would be great if we have some coverage test tools for helping us to find where we can do new tests.

6 - Testing is context-dependent

Yes! Testing a node web software is different of some embedded in raspberry. For example, the life cycle of a mobile software has a lot of rules and will impact its testing.

7 - Absence of errors fallacy

May you have absence of errors and could think: great! But if you don't fulfill all customer requirements so you didn't a good work. Focus on the business and do a usable software using software testing techniques.

Difference between Bug, Defect, Error, Fault & Failure

Thomas Muller “A person can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or a document. If the execution of the defect in code happens, the system will fail to do what it should do (or something it shouldn’t), which causes a failure”.

Let's answer some necessary questions for our knowledge of software testing

Now, we can see some important concepts and it will help us to implement test in the most tools.

What is unit test?
Unit test focus on a small parte of our software. If we have to build a sum function, so first we can create a unit test to test the sum. That's a fundamental concept in software testing.

What is atomic test?
An atomic test is one smallest that focuses on testing a single feature, seems like unit test.

What is automated tests?
Automated -- and not manual -- testing is a process that validates if software is functioning appropriately and fulfill all requirements before it is released into production. This method uses scripted sequences that are executed by testing tools and if necessary can run repeatedly at any time.

What is integration testing?
Integration happens when we need more parts and not just a unique small part to test. For example, if we need to test an API, we have a lot of things to observe like database, routes and entities.

What is black block testing?
Black Box Testing mainly focuses on input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing.

What is white block testing?
On the contrary of black block testing, the white is based on internal functioning of our software, we want to see code, branch, linter, code quality. It is a low-level testing.

What is system testing?
We cannot see code, but how the system work on production in different contexts, such as its memory, processing, response and others. One example, would be to do many requests to server and observe its behavior.

What is acceptance testing?
We get to fulfill all customer requirements? That's a acceptance testing.

What is an exploratory testing?
Exploratory Testing is a type of software testing that we don't have a TDD (test first) but it impulse the testing thinking, creativity and other things that stimulate a better testing process, be individual or a team.

What is Defect Based Testing?
A Defect Based Testing is a technique of test cases that are derived on the founded defects. Not use cases or requirements, here is based on defects to orient our case tests.

What is TDD?
TDD (Test Driven Development) is a software development focuses on test-first to do unit test case and so develop the code.

What is BDD?
BDD (Behavior Driven Development) is derivate from TDD and is configured as an agile software development to manage projects, involving people and teams for together working oriented for software testing with test-first. As its name suggests, it was designed to test based on systems behavior.

What are user stories in software testing?

(By Max Rehkopf)Summary: A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

How do you write a test user story?
All things that users will be unified in testable parts, so we can apply the techniques: unit test, integrations and others.

What is coverage test?
It's metric to show us if our code has all of its functionalities built from each case test. It there some part that has no test but is already in production? Coverage test can help us to observe it.

Conway Law and the Software Testing

Mel Conway says:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Important article: http://www.melconway.com/Home/Committees_Paper.html

If you have a culture of tests, great! The team certainly do much more and with quality.

Techniques of software testing

Test Double
Martin Fowler says "(..) Test Double is a generic term for any case where you replace a production object for testing purposes."

Below are kinds of Test Double and is a transcript from Martin Fowler:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
• Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.

credits: https://medium.com/rd-shipit/test-doubles-mocks-stubs-fakes-spies-e-dummies-a5cdafcd0daf

Unit test and the triple A pattern (Arrange, Act, Assert)

It describe that we should divide our test method into three parts: arrange, act and assert.

1 - Arrange
So the arrange section you only have code required to setup that specific test. For example, here we'd have objects and mocks.

2 - Act
This part must do the invocation of the method that will be tested.

3 - Assert
We need to verify: a simple check of expectations.

Below, one example using triple A pattern in Javascript with Jest:

const multiply = require('./multiply');

test('multiply 1 * 2 to equal 2', () => {
  expect(multiply(1, 2)).toBe(2);
});

When we write the reserved word test that means our Arrange, the function multiply is our Act and expect is the Assert

Above, we have one small example of software testing, and in practice it is a simple code, but with many concepts as we talking here.

We can use mocks/stubs, unit test or integration, black or white block, TDD, BDD, atomic tests, automated tests, verify the test coverage and at the final result do a better software.

That's all folks.

Important readings
Meszaros, Gerard. xUnit test patterns: Refactoring test code. Pearson Education, 2007.

Contacts
Email: [e-mail]
Instagram: https://www.instagram.com/luizcalaca
Linkedin: https://www.linkedin.com/in/luizcalaca/
Twitter: https://twitter.com/luizcalaca