QualiTest considers the traditional role of Manual QA in the ever developing world of Software Testing. How will the changing role of developers affect manual QA? Let's think about that for a moment.
QualiTest is the world’s second largest pure play software testing and QA company. Testing and QA is all that we do! visit us at: www.QualiTestGroup.com
2. Traditional
Manual
QA
| Common practice for QA & development teams to be separate
| Heavy focus on manual testing
| QA’s were seen as “the ambulance at the bottom of the cliff”
| Highlighting all the problems at the last minute
| In this Waterfall environment, projects could take months or even
years to go Live
| Minor changes would lead to change management requests and
“feature” vs. defect arguments
2
3. Current situation
| Lengthy projects are considered dinosaurs of the industry
| Teams are no longer being separated by discipline and the focus on automation
| Companies live and die on their speed-to-market
| It would be unthinkable to wait days or even weeks to release due to a slow Software
Delivery Lifecycle
| Reducing cycle times and deploying into production frequently is called Continuous
Delivery (CD)
3
4. So how does a company decrease
their cycle time?
| Creating autonomous teams that are empowered to make decisions
| Teams no longer have specialists
| Everyone is a “jack of all trades”
| Developers build code, test and deploy to production
| This is also known as DevOps
| Coupled with Continuous Integration (CI), drastically reduces cycle time compared to
more traditional methods of delivery
4
5. Continuous Integration
| CI is the practice where developers commit their code into a shared repository and
automated tests are run to see if that change has broken anything
| Only if all tests pass then the code is merged
| There is also a large automation set of regression tests that are run before any code is
deployed into Production
| CI tests should take minutes at most and the complete regression shouldn’t take more
than an hour
5
6. Minimum Viable Testing
| Testing just enough to decrease cycle time
| With the key word being “viable’’
| Key functionality needs to be covered - things that the business cannot take the risk of
not working correctly
| But no exhaustive testing of every feature
| Traditionally these tests were run manually, which did not give the speed or
repeatability
| This results in the requirement of test automation
6
7. Who automates these tests?
| Typically, the CI tests (mainly unit and integration level) are automated by the
developers
| The regression tests (mainly end-to-end and UI driven) are automated by the QA team
| However, there has been an increasing trend towards developers automating these too
| Striving to become more cross-functional, reduce bottlenecks and cycle time
7
8. The future
of QA’s in
Technology
| There is a future for QA’s, even if the developers are automating all
of the CI and regression tests
| Just not in the traditional sense of doing manual, end-of-the-line
testing
| There are many ways that a QA can stay relevant in this shifting
market
| QA’s should be working closely with the developers
| In the same notion of pair-programming, they could start doing
“pair-testing”
| In order to write automated tests with the developers.
8
9. QA Goals
| Ensuring that quality is built in from the beginning
| Encouraging practices such as Test Driven Development
| A tester’s mind-set is very different to a developer’s, which often allows a QA to
identify problem areas more easily
| QA’s should be training developers to think outside the box
| And ensuring that they’re thinking of different scenarios while they’re developing
| In theory, this should mean that fewer bugs are developed
| Making the whole SDLC faster and more efficient
9
10. QA Focus Shift
| With QA’s having a reduced workload due to developers taking on additional
responsibility, QA’s can start shifting focus on areas of testing other than system
functionality
| QA’s should be shifting focus onto non-functional testing
| Areas such as performance and security should be explored
| As well as real usability testing and facilitate crowd or beta testing
| To prove that you are building the right thing, and not just building the wrong thing
correctly
10
11. The need for QA
| There is and probably always will be the need for exploratory testing in-house, which
requires a QA’s mind
| This again should be kept to “minimum viable testing”
| QA’s should also look into the analytics behind what’s being developed; e.g. what
browsers or device customers are using and then ensure that testing and development
targets this
| This is an area often forgotten during development that can result in poor usability if
not given adequate attention
| There are countless ways of improving the quality of a system, these example are just a
few, and this is where a QA can truly bring value to the SDLC
| Improving quality, increasing efficiency and reducing cycle time
11
12. The survival of QA
| The notion of a QA in the traditional sense is going away
| However, by changing and adapting their way of working to stay relevant they can
ensure they are providing value
| Training developers to think like a QA
| Improving testing practices
| Pushing ahead with non-functional testing
| And striving to improve quality and efficiency wherever possible
| This will help to ensure that the role of a QA continues to be relevant
12
13. Other opportunities for QA’s
| Taking on dual roles such as:
- Scrum Master
- Business Analyst
| Knowledge gained in working as QA can lend itself particularly well in these areas
| Knowledge gained in working as QA can lend itself particularly well in these areas
| And on the other bring added value to the organization
13
14. Will QA stay a factor in the future?
| The role of a traditional manual tester will likely go the way of the typewriter
| But not a single business out there can honestly say that their software is perfect
| And as long as that continues to be the case, there will always be the need for QA
14