Full stack QAThe fine art of being a full stack agile tester

Organized by Computer Society of Sri Lanka

4th June 2015 @ UCSC AuditoriumPresented by;Nalin Goonawardana Head of QA. Leapset Engineering

Full stack Agile Tester“A generalizing QA specialists who is technically competent in all test levels and test types and strategies who is also adaptive/responsive, collaborative and culturally fits in as an agile team member” - The fine art of being a QA rep in an agile project.

What you can expect

An introduction to a set of skills that would shape up a full stack agile tester and a list of Agile Concepts that will empower a valued QA representatives in agile contexts.

We will talk about• Unlearning

• Whole teams

• QA influence

• Developer tester pairing.

• Building collaberation

• Swarming

• T-Shape skills and full stack

• Osmotic communication and co location

• Dev advocate

• Few testing strategies that are slowly coming to picture

• Test completing within the sprint

About Agile practiceProposed by a set of people sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.

Disciplines : Extreme Programming, SCRUM, Dynamic System Dev Method, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming …. etc.

The background

• Standard over the wall approach.

• Dev startups. Fail fast / Test the water.

• Agile teams in maintainance projects in

corperate contexts.

• True agile projects

• Consulting / Out sourcing …….

Why Agile QA?

Unlearning“He who knows to unlearn, learns best” - Unlearning the traditional mindset that is anchoring.

Few things to unlearn:

•Tests are confidential until a formal QA release is given

•The more bugs formally reported, the better

•We are the only ones here to test

•Our duty is only to perform testing

•We only do black box testing

•There is a testing phase

•Testing is a sequential process of planning designing execution etc. ..

•Completion of testing is optional for the scope of the sprint

•Testing is the only way to measure and improve quality

•Automation is an exclusive task that requires a separate team.

Agile teams are "whole teams"

• No sub groups.

• Each has a differentiating value

• The whole teams will be kept dedicated, protected and unchanged between.

• The operational boundaries are thin and almost invisible

• All are first class citizens

• Shared accountability.

Constructive QA influence• Constructive resistance

• Dev autonomy and self decipline• Agent in the system who can deep dive to verify and

validate requirements and engineering rigor

• User Proxy

• Agree to disagree

• Progress and donness

• Velocity Vs Quality

Eg.: The API documentation or UX

Pairing deal - Finding synergy

• Pair negotiation. Healthy debate.

• Pair strength. Cross skilled.

• Pair understanding. Less surprises.

• Seamless work flow: Less handoffs.

• Early detection.

• One goal two co existing strategies.

• Pair accountability. The notion of team

entails shared accountability.

• Pair review.

• Pair courage. Fearless refactoring.

Just enough Independent

• Demonstrate competency

• Static code analysis

• Use the technical

• Maintain your quality bar

• Prove the values of some processes by lessons learned

• Work the extra mile in time of need !

• Be a little bit of traditionalist

• Keep the team’s Continuous attention to technical excellence

• Remark learnings and mistakes in the retro meeting or reflective

improvement discussions.

How to build ultra collaborative relation

• Be genuine, open and transparent. No hidden agendas.

• Co-locate.

• Nothing personal but professional.

• Walk the extra mile in need.

• Do not only talk about releases and bugs with them

• Make smart suggestions. Ask smart questions.

• Pair

• Do not celebrate a bug cought in formal testing.

• How important a bug is to a Dev ?

Refactoring a bug.

Dev advocate role

• Requirements Champion

• Business sensible unit tests.

• Infrastructure support for self servicing CI and encourage

frequant checkins.

• Encourage and demand testability.

• Remind maintainability and scalability.

• Remind non functional aspects through

early tests.

• Scenarios that drives the implementation.

• Make sure the quality is built in!

Swarming

• “Collectively and dynamically Prioritizing and attending tasks or self organizing based on the availability of work irrespective of the initial agreements or allocations making sure that the sprint objectives are optimally achieved.”

• Bunch members or the whole team attend and finish one story at a time and move to the next afterwards.

• Unclear/Unstable areas will naturally be pushed to be addressed in the later part of the sprint.

T-Shaped skillsAbility to work outside Of core subject area

Functional area, disciplineor specialized skills

T-Shaped skills and Full stack

The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.

Train the team

• Test execution (Dev, PO)

• Test reviewing (Dev, PO)

• Debugging (PO, Deployment)

• Automation scripting (Dev )

• Using the CI and analyze FE reports (PO, Dev)

• Regression tester (Dev, PO)

• Concurrency/Stability test support (Dev)

Get trained

• Unit tester

• Code reviewer

• Requirement advocate

• BA

• Build engineer

• CI expert

• UX advocate

• Cheer leader or scrum master

• Release manager

• Developer of simulators Mock services stubs test data

generator

• Test tool /Framework developer.

Osmotic Communication

• State of affairs

• Background hearing of project related discussions. • When one person asks a question, others in the room can

either tune in or tune out, contributing to the discussion or continuing with their work.

• Errors are corrected and disseminated quickly.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Exploratory testing

• Simultaneous learning, test design and test execution.

• Session-based test

• Internal bug bounty

• Not ad-hoc testing

• Efficient

• A strategy for continuous testing.

• Know your product

• Know your Dev

Trends : Dogfooding

• This is a pre release testing/feed back strategy where the software is put into be used by the internal employees in achieving there real world task.

• Feel the pain

• Mostly usability.

Trends :Crowdsourced testing• practice of sending out prototype software and

products to broad groups of people for testing rather than having testing performed internally.

• Bug bounty.

Reflective improvements

• Critical evaluation of the current processes.

About processes

“Any methodology will be as good as you would want it to be ... Starter methodology then tailors it to reflective improvements”

“Any good process will go into the background.”

Engineering productivity

Quality Assurancing is becoming more about engineering productivity.

“With the software in production, fixing bugs is akin to repairing a car

while it is driving down the road, long after it has left the drawing

board, the assembly line, and the dealer lot. Its as expensive to do

as it can possibly be”

Key Agile Behaviours

• Early collaborative acceptance test design in the common format of scenarios. (Test cases and Scenarios. BDD)

• Test cases or scenarios are not confidential to QA. It is a common asset/contract

• Automation is the default testing strategy, the other option is semi automated testing

• Pull based Continuous testing. Early access testing and feedback. • Just enough documentation• Objective is to capture issues as early as possible. Not capturing and

reporting of bugs in formal testing only• Unit testing and FE test automation would be a joint operation• Practice exploratary test methods.• Scan and adopt/Improve. Reflective improvements.

The spider diagram

For hiring and for team assessment

Testing within the sprint?

• Who says it is easy?

• Who says it is impossible?

• Steel threads

• Thin slices

• Tracer bullets

• Swarming

• Talk in scenarios and let it UATD

• Automation and CI

• Continuous testing (Early access pull based testing)

• Get a fully tested release for the formal test round.

“No story is done until it’s tested.”

What will happen when we put all this together ?

Implementation

Dev testingQA releaseDev Design

QA test Design

QA test execution

Bug fix releases

QA regression testing

Resource levelling

Is fullstack Mandatory

• Is full stack only requires for startups?

• Is full stack only for Agile ?

• What about career prospects?• Bigger organizations which are not as dynamic as startups

will need specialists rather than generalist specialists.

• But big corporations will have their innovative product development and research projects which require fullstack model.

Your word is trusted and valued?

“We were most of the time given a free hand to point out issues with the code to the Dev Team”

“Most of the negative perception about testers comes from those people who are hired basically as button pushers and have next to no actual skills (although to be good at even those jobs you need to have a good analytical mind). When you get into those QA engineers who are expected to be able to code new tests and even write software which runs these tests then you are effectively not talking about testers anymore;”

“What I have seen is that software engineers respect people with strong technical skills, people who can write beautiful code and make your life easier, and people catching nasty bugs by just eyeballing your diff. It doesn't matter if they are working on product, infra, test infra, etc. Although I have only worked at one company (Facebook), I feel that should be a natural thing if you have a bunch of good guys working together.”

“I worked in automation test teams of google, microsoft before. Though the engineers of product development groups seem to say things like 'good job', 'great work' for the tools and suggestions one makes, that does not really imply that you are treated on par with any of their peers.”

“Actual Quality Assurance Professionals; not gamers, face bookers, excel sheet experts, Monkey testers, button pushers, not frustrated/failed programmers – but passionate QA Professionals. ”

Ref: http://www.quora.com/Do-software-engineers-that-work-on-automated-test-infrastructure-get-respect-at-top-engineering-companies-like-Google-and-Facebook

Take away Lessons

Full stack agile testing role will be a significant and vital role in the future agile teams who are focusing in delivering shippable products that will win the customer delight. It is important for a team to be self sufficient, self organized and to operate at the optimum velocity.

Being a QA generalist specialist will require to have a set of important skills compared to a traditionalists;

1. Core QA knowledge and skills2. Generalist skills3. Agile practices and mindset.

“We are uncovering better ways of developingsoftware by doing it and helping others do it.”

--- The Agile Alliance

Further questions to : nalin@leapset.com

Remark: This contains quoted content from various resources and compiled with the intent of common knowledge sharing.