This document discusses quality assurance practices that can be applied in the early stages of product development. It addresses problems that arise from high bug costs and unclear roles of developers and testers. Potential solutions proposed include applying testing practices at the concept, requirements, and design stages. Specific techniques discussed are testing concepts using persona data, A/B testing, requirements analysis, test-driven development, behavior-driven development, and pairing testers and developers. Benefits include reducing bugs and manual tests while increasing knowledge across roles. Challenges include ensuring tests are appropriately scoped and requiring changes to team mindsets.

1. Quality assurance in the
early stages of the product
Maksym Vovk (Test Specialist, Clio Online)

2. o Problem 1. Cost of the bugs
o Problem 2. Role of the developer and
tester on the project
o Ways of possible solution
Presentation agenda

3. Problems to solve
Type to enter a caption.
.Bug cost

4. Arian 5

5. Radiation Therapy

6. Problems to solve.
Role of the tester and
developer on the project.

7. meanwhile…

8. and one more case…

9. Cost of the Bug

10. It’s a long way to go…

11. So how we can improve it?

12. Applying QA practices for Concept
stage
o Testing of the concept (using Persona data at Clio)
o A/B testing

13. Applying QA practices for
Requirements stage
Levels of requirements
1. Business requirements (Vision and Scope document)
Example: “We need a tool for selecting commercial data from different sources and
converting it to easy-to-read forms, i.e. charts, pivots etc.”
2. User requirements (User Stories, Scenarios, Use Cases)
Example: “When the user logs into the system the welcome page should be opened.”
3. Functional and nonfunctional requirements (Specification)
Example: “The device should check all valid sources during installation. All invalid
sources must be visible but disabled for a regular user.”

14. What is requirements analysis?
Eliciting requirements: the task of identifying the various types of
requirements from various sources including project documentation,
business process documentation and stakeholder interviews. This is
sometimes also called requirements gathering.
Analyzing requirements: determining whether the stated requirements
are clear, complete, consistent and unambiguous, and resolving any
apparent conflicts.
Recording requirements: Requirements may be documented in
various forms, usually including a summary list and may include
natural-language documents, use cases, user stories, or process
specifications.

15. Characteristics
Inconsistent
Not
verifiable
oComplete
oConsistent
oCorrect
oUnambiguous
oVerifiable
Incomplete
Ambiguous
Incorrect

16. Applying QA practices for Design
stage
o TDD/ATDD
o BDD
Possible solutions:

17. TDD methodology

18. TDD flow

19. TDD methodology

20. TDD test example
class CalculatorTest
{
public void Sum_2Plus5_7Returned()
{
//…
}
}

21. BDD methodology
BDD is modified from TDD methodology by using semi-formal (ubiquitous) language
understandable for all including Dev, QA, BA, PO etc. The main idea is to use
sentences that describes behavior of the system.
class CalculatorTest
{
public void Sum_2Plus5_7Returned()
{
//…
}
}
Calculator Test
- should add positive numbers;
- should add negative numbers;
- …

22. BDD methodology on practice

23. TDD : how to implement
Practice 1 – Team planning
o Different points of view on same
task
o Clear acceptance criteria for
everyone
o Team estimation including all
aspects
Practice 2 – Test case review
o Same understanding of functionality
to be implemented
o Developer receives edge cases,
reducing possibility of defects
o Developer may suggest better
automation options
o Developer receives test scenarios
Practice 3 – Pair design sessions
o Testability may be built in to simplify testing
o Implementation order may be decided for early testing

24. Pros&Cons of TDD/BDD
o Unit-test written by TDD helps
during system regression
o Tests like documentation
o Reducing number of manual
tests
o QAs obtains deeper knowledge
of product
o Pair sessions (Dev+QA) extends
knowledge and mindset of each
member
o Unclear how small should be
test
o Method requires clear
specification
o If test broken – test is fixed
instead of application
o Method requires change of
the mindset

25. Summary
o Early testing is important for software
development
o Its cheaper to prevent bugs not fix
o All testing and development method should
be chosen by context ( depends on the
project)
o QA and Developer may be effective in pair

26. What will you choose?

27. Thank you!