Académique Documents
Professionnel Documents
Culture Documents
continuously?
When requirement keeps changing, continuously agile tester should take following
approach
Write generic test plans and test cases, which focuses on the intent of the
requirement rather than its exact details
To understand the scope of change, work closely with the product owners or
business analyst
Until the feature is stable, and the requirements are finalized, it is best to wait if
you are going to automate the feature
2) List out the pros and cons of exploratory testing (used in Agile) and scripted
testing?
Exploratory
Testing
Scripted
Testing
Pros
- It requires less preparationEasy to modify when
requirement changes
Works well when
documentation is scarce
- In case testing against legal
or regulatory requirements it
is very useful
Cons
- Presenting progress and
Coverage to project
management is difficult
- Test preparation is usually
time-consuming- Same steps
are tested over and again
When requirement changes it
is difficult to modify
Scrum
- Scrum teams usually have to work
in iterations called sprints which
usually last up to two weeks to one
month long
- Scrum teams do not allow change
into their sprints
- In scrum, the product owner
prioritizes the product backlog but
the team decides the sequence in
which they will develop the backlog
items
- Scrum does not prescribe any
engineering practices
6) Explain how you can measure the velocity of the sprint with varying team
capacity?
When planning a sprint usually, the velocity of the sprint is measured on the basis of
professional judgement based on historical data. However, the mathematical formula
used to measure the velocity of the sprint are,
Test driven development or TDD is also known as test-driven design. In this method,
developer first writes an automated test case which describes new function or
improvement and then creates small codes to pass that test, and later re-factors the new
code to meet the acceptable standards.
11) Prototypes and Wireframes are widely used as part of?
Prototypes and Wireframes are prototypes that are widely used as part of Empirical
Design
12) Explain what is Application Binary Interface?
To track the project progress burnup and burn down, charts are used
Burnup Chart: It shows the progress of stories done over time
Burndown Chart: It shows how much work was left to do overtime
14) Explain what is Scrum ban?
Scrum ban is a software development model based on Scrum and Kanban. It is specially
designed for project that requires frequent maintenance, having unexpected user stories
and programming errors. Using these approach, the teams workflow is guided in a way
that allows minimum completion time for each user story or programming error.
15) What is story points/efforts/ scales?
It is used to discuss the difficulty of the story without assigning actual hours. The most
common scale used is a Fibonacci sequence ( 1,2,3,5,8,13,.100) although some
teams use linear scale (1,2,3,4.), Powers of 2 (1,2,4,8) and cloth size (XS, S ,M,L,
XL)
16) Explain what is tracer bullet?
The tracer bullet is a spike with the current architecture, the current set of best practices,
current technology set which results in production quality code. It is not a throw away
code but might just be a narrow implementation of the functionality.
17) What is a test stub?
A test stub is a small code that replaces an undeveloped or fully developed component
within a system being tested. Test stub is designed in such a way that it mimics the
actual component by generating specifically known outputs and substitute the actual
component.
18) What are the differences between RUP (Rational Unified Process) and Scrum
methodologies?
RUP
- Formal Cycle is defined across four
phases, but some workflows can be
concurrent
- Formal project plan, associated with
multiple iterations is used.
- Scope is predefined ahead of the
project start and documented in the
scope document. During the project,
scope can be revised.
- Artifacts include Scope Document,
formal functional requirements package,
system architecture document,
development plan, test scripts, etc.
- Recommended for long term, large,
enterprise level projects with medium to
high complexity
SCRUM
- Each sprint is a complete cycle
- No end to end project plan. Each next
iteration plan is determined at the end
of the current iteration
- It uses a project backlog instead of
scope scrum
- Operational software is the only formal
artifacts
- Recommended for quick
enhancements and organization that
are not dependent on a deadline
Due to frequent agile code delivery usually every sprint of 2-3 weeks, stable
quality of build is a must and continuous integration ensures that
Continuous integration helps to check the impact of work on branches to the main
trunk if development work is going on branches using automatic building and
merging function
1.
It provides greater visibility to stakeholder from the start of the sprint, which in
turn provide early feedback and ensures project success.
2.
Release Planning
In this release plan is prepared, which include list of features that needs to be delivered,
release date of software into Production, number of iterations/sprints for that release etc.
Spring Planning
In this product Owner presents the set of features he would like and the team asks questions
to understand the requirements in sufficient detail to enable them to commit to delivering the
listed features in sprint.
Daily Scrum Meeting
Daily Scrum Meeting is for answering the following 3 questions:
1. What have you done since yesterdays meeting?
2. What are you going to get done today?
3. What obstacles do you need to be removed?
Sprint Review
It is demonstration of the new features the team has completed during the sprint; it is used to
gather early feedback.
Sprint Retrospection
It follows immediately after the sprint review. It is focused on the process, the way in which
the Scrum team is working together, including their technical skills and the software
development practices and tools they are using.
In this meeting team discuss on following points:
1. What went wrong?
2. What went well?
3. What can be improved?
3.
Each member of team is given deck of card which contains stories points in
Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13...
Scrum Master lists the user stories and provides brief overview of them. Team
discusses and clarifies any questions/risks.
Each team member privately assigns a card representing his estimate of the size
for the user story.
Later on all estimates are revealed and people having low estimates and high
estimates need to provide justification for the same and after discussion within
team story point is finalized for use story. Same is repeated for all user stories.
4.
What is Continuous Integration and why it is important for Agile? What are
the software/tools available for the same?
Product backlog is owned by the product owner, which contains list of all desired features.
Sprint backlog is created in Sprint Planning Meeting. It is subset of product backlog which is
owned by development Team, who commits it to deliver in a sprint.
6.
What is difference between Epic, User stories & Tasks? Who should create
User stories & Task?
User Stories defines business requirement from the client perspective and it is supposed
to be delivered in particular sprint.
Task: User Stories are further broken down into different task from technical perspective.
Epic is a group of related User Stories, or it is large use story which cannot be completed
in single Sprint.
User stories should be created by Product Owner as these are written from client
perspective. Tasks should be created by someone from Development Team who is aware
about them from technical perspective.
7.
In short term there may be loss of productivity but it increase productivity of resource due to gain
in business or technical knowledge.
8.
9.
10.
Burn Up and Burn Down charts are used to track project progress.
Burnup Chart shows progress of stories done over time. X Axis: Time, Y Axis: no. of user
stories completed.
Burndown Chart shows how much work was left to do over time. X Axis: Time, Y Axis: no.
of user stories remaining.
11.
Task board is used to track progress in agile. Generally it has following columns:
11. What is the effect of having a large visible project plan on a wall?
A. It removes the need to create any other reports for management
B. It continuously communicates progress within the team and to
other stakeholders
C. It allows the Project Manager to allocate tasks to specific team members
D. It is restrictive, as it does not allow the team to innovate and change
12. How should work be allocated to the team in an Agile project?
A. The Team Leader (Scrum Master) should allocate specific tasks to
individuals
B. Tasks should be randomly allocated to team members, using Planning
Poker
C. Team members should self-select tasks appropriate to their skills
D. The most complex tasks should be allocated by the Team Leader (Scrum
Master)
13. What should the developers do if the customer representative is
repeatedly too busy to be available?
A. Continue the work, record the assumptions and ask the customer later for
input.
B. Send the customer a written warning that the end product will be
completed on time, but may not meet their needs
C. Allow the Business Analyst to take on the role of Proxy Customer
Representative
D. Draw the problem to the attention of the Scrum Master (Team
Leader)
14. Which one of the following is a key feature of documentation that you
would expect to find in an Agile project?
A. System documentation created at the end of each increment, at the start
of the deployment
B. User Stories held in a spreadsheet or specialist database, where full details
of user conversations are recorded for future purposes, like handover to
maintenance or support
C. User Story cards containing only enough detail for planning and
development, which will need to be supplemented by further faceto-face conversations
D. No written documentation, as all good communication is face-to-face
15. When handling team dynamics, the Agile Leader should
A Empower the team members, within appropriate limits
B. Encourage an environment of competition and personal advantage
C. Give clear directives to the team about what they should do and how
D. Expect team members to be proactive and each work to their own
priorities and objectives Sample Questions with Answers for Web Revised Jan 2013 v0 4 5 22 January 2013
Author D J Tudor
21. Which one of the following statements about workshops is true for Agile
projects?
A. All project stakeholders should attend requirements workshops
B. Retrospectives are only run at the end of a project
C. It is best if the Project Manager facilitates the projects workshops
D. An independent facilitator will manage the structure of a
facilitated workshop but not input to the content
22. Which one of the following is an important feature of the daily stand-up /
wash up / Scrum meeting?
A. Everyone is expected to stand for the whole time, to keep the meeting
short
B. The meeting must be kept short and well structured
C. The meeting should ensure that it is clear to all which team members are
not performing
D. No-one is allowed to leave the stand-up meeting until all problems raised
have been solved
23. Who should attend the stand-up meetings?
A. Sponsor and Executive Management only
B. Project Manager and Technical Leads only
C. Project Leader and Customer Representatives only
D. The entire team
24. One of the development stages you would expect to see a team go
through is:
A. Storming
B. Warming
C. Cloning
D. Yawning
25. When estimating is done for a project, the developers should:
A. Be fully involved in the estimating process
B. Be in total control of the estimating process
C. Be consulted after the Team Leader (Scrum Master) has made the
estimates for the teams work
D. Not make estimates unless velocity is already known
26. During an iteration (sprint) (timebox) the developers should be:
A. Able to contact the customer to clarify aspects of the work
B. Completely uninterrupted by the customer
C. In twice-daily contact with the customer
D. Able to work without needing to disturb the customer Sample Questions with Answers
for Web Revised Jan 2013 v0 4 7 22 January 2013 Author D J Tudor
We created this set of questions to help corporate managers select Agileexperienced consultants and candidate employees for project work.
Assembling a team of qualified Agile people is one thing, but the fact that
This question is more for Agile project managers. Do you have corporate
PM tool standards? If so, this question becomes quite important. Agile has
a new breed of PM tools including Rally Software, Version One and
XPlanner. These tools bear no resemblance to the waterfall PM tools like
MS-Project or Clarity. If your candidate is more comfortable using one of
these Agile PM tools, try to identify if they will be able to fit their Agile
project plans (and issues, milestones, change requests, etc.) into your
companys structure.
11. Can you explain the purpose of a burndown chart?
This is more of a question for candidate project managers, although all
Agile people should know the answer. A burndown chart is a graph that
shows the progress of the team in terms of work "burned through." The
work is usually put in terms of a set of "story points" which represent
functionality. Once a piece of functionality is coded and tested and
reviewed by the user, it is considered to be "burned" and the graph will
reflect this. The graph should show a steady movement down until it is
clear that the team will have completed the story point backlog by the
release date. There is also a variation called a "burnup chart" that works
the same way but can handle scope changes more easily than the
burndown variety. Again, you want to see how the candidate will link their
burndown/burnup chart into your overall project management structure.
12. What does project velocity mean?
This is a PM question, but most Agile people should know the answer.
Project velocity is the rate at which a team is "burning" through story
points, so a possible velocity might be "30 story points per iteration." That
means that so far, the team has been able to identify, code and test 30
units of functionality (story points) in an average iteration and can expect
to do about that much in future iterations, giving a fairly good view
towards what can be accomplished by a release date.
Hopefully, these twelve questions can be a good start for your
qualification process in bringing in new Agile consultants or candidate
employees. Our hope is that you can build a highly-qualified team that will
fit in well with your corporate development process, culture and PM
standards.
References:
Our work is based on the research paper by Dr. Hong Li. The paper is
available here:
http://agileplusrigor.ning.com/forum/topic/show?id=2075814%3ATopic
%3A565
Here is some good reading on Agile in the enterprise:
Augustine, S. - Managing Agile Projects (Prentice Hall PTR, 2005), 264p
Highsmith, J. Agile Project Management (Addison-Wesley, 2004), 312p
Leffingwell, D. Scaling Software Agility (Addison-Wesley, 2007), 384p
Possible related articles and blogs of interest:
LitheSpeed Blog: lithespeed.blogspot.com
The Agile Executive: trailridgeconsulting.com/blog
Leading Answers: leadinganswers.typepad.com
Scaling Software Agility: scalingsoftwareagility.wordpress.com
http://atozmcqs.blogspot.in/2014/01/105-top-agile-testing-multiple-choice.html
************************************************************************
Kanban
Kanban is a lean approach to agile software development.
Actually, Kanban means many things. Literally, Kanban is a Japanese word that means visual
card. At Toyota, Kanban is the term used for the visual & physical signalling system that ties
together the whole Lean Production system. Most agile methods such as Scrum and XP are
already well aligned with lean principles. In 2004, however, David Anderson pioneered a more
direct implementation of Lean Thinking and Theory of Constraints to software development.
Under the guidance of experts such as Don Reinertsen, this evolved into what David called a
Kanban system for software development, and which most people now simply refer to as
Kanban. So while Kanban as applied to software development is new, Kanban as used in Lean
Production is over a half century old.
Weve done Scrum for a long time now and our process improvement has levelled off.
How can we take our process to the next level?
2.
Split the work into pieces, write each item on a card and put on the wall.
Limit WIP (work in progress) assign explicit limits to how many items may be in
progress at each workflow state.
3.
Measure the lead time (average time to complete one item, sometimes called cycle
time), optimize the process to make lead time as small and predictable as possible.
This is a direct implementation of a lean pull scheduling system. Heres an example of a simple
Kanban board, with WIP limits in red.
Heres a more complex one (see Kanban kick-start example for a closer look & description)
Provides a more gradual evolution path from waterfall to agile software development,
thereby helping companies that previously have been unable or unwilling to try agile methods.
Provides a way to do agile software development without necessarily having to use timeboxed fixed-commitment iterations such as Scrum sprints. Useful for situations where sprints
dont make much sense, such as operations and support teams with a high rate of uncertainty
and variabilty.
Case examples
Marketing
o
o
Enterprise Kanban (article by Mattias) - shows how Kanban can be used to improve the
full value stream
Multi team projects
Lean from the Trenches Managing Large Scale Projects with Kanban (book by Henrik)
shows advanced application of Kanban in a 60-person project
Operations
Kanban & Scrum, making the most of both (book by Henrik & Mattias)
Further reading
o
o
o
o
o
o
o
o
o
o
o
Scrum
Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process
and customize it to your environment. In fact, you have to experiment. Neither Scrum nor Kanban provide
all the answers they just give you a basic set of constraints to drive your own process improvement.
Scrum Summary
Scrum is an iterative, incremental framework for projects and product or
application development. It structures development in cycles of work called
Sprints. These iterations are no more than one month each, and take place one
after the other without pause. The Sprints are timeboxed they end on a
specific date whether the work has been completed or not, and are never
extended. At the beginning of each Sprint, a cross-functional team selects
items 5 (customer requirements) from a prioritized list. The team commits to
complete the items by the end of the Sprint. During the Sprint, the chosen items
do not change. Every day the team gathers briefly to inspect its progress, and
adjust the next steps needed to complete the work remaining. At the end of the
Sprint, the team reviews the Sprint with stakeholders, and demonstrates what it
has built. People obtain feedback that can be incorporated in the next Sprint.
Scrum emphasizes working product at the end of the Sprint that is really
done; in the case of software, this means code that is integrated, fully tested
and potentially shippable.
A major theme in Scrum is inspect and adapt. Since development inevitably
involves
learning, innovation, and surprises, Scrum emphasizes taking a short step of
development,
inspecting both the resulting product and the efficacy of current practices, and
then adapting
the product goals and process practices. Repeat forever.
Like any tools, Scrum and Kanban are neither perfect nor complete. They dont
tell you everything that you need to do, they just provide certain constraints &
guidelines
S.No
1.
2.
3.
Scrum
It constrains you to have
timeboxed iterations and cross-functional
teams
Scrum prescribes 3 roles:
Product Owner (sets product vision
&priorities)
Team (implements the product)
Scrum Master (removes impediments
and provides process leadership)
It limits WIP per iteration
Kanban
It constrains
you to use visible boards and limit the size of
your queues i.e. limit WIP(Work-in-progress)
Kanban doesnt prescribe any roles at all.
That doesnt mean you cant or shouldnt have a
Product Owner role in
Kanban! It just means you dont have to. In both
Scrum and Kanban you
are free to add whatever additional roles you
need.
It limits WIP per workflow state
Points to be noted:
1. Process = how you work.
Tool = anything used as a means of accomplishing a task or purpose.
Scrum and Kanban are process tools in that they help you work more effectively by, to a certain extent,
telling you what to do. Which tool is better depends upon your context. For a given situation, a particular
tool is better
2. No tool is complete and no tool is perfect. Like any tools, Scrum and
Kanban are neither perfect nor complete. They dont tell you everything that you need to
do, they just provide certain constraints & guidelines. For example, Scrum constrains you
to have
timeboxed iterations and cross-functional teams, and Kanban constrains you to use visible
boards and limit the size of your queues.
3. Interestingly enough, the value of a tool is that it limits your options. A process tool that
lets you do anything is not very useful. We might call that process Do Whatever or how
about Do The Right Thing
4. Using the right tools will help you succeed, but will not guarantee success. It's easy to confuse
project success/failure with tool success/failure.
A project may succeed because of a great tool.
A project may succeed despite a lousy tool.
A project may fail because of a lousy tool.
A project may fail despite a great tool..
5. Prescriptive means more rules to follow and adaptive means fewer rules to follow.
100% prescriptive means you dont get to use your brain, there is a rule for everything.
100% adaptive means Do Whatever, there are no rules or constraints at all.
6. Agile methods are sometimes called lightweight methods, specifically because they are
less prescriptive than traditional methods. Scrum and Kanban are both highly adaptive,
but relatively speaking, Scrum is more prescriptive than Kanban. Scrum gives you more
constraints, and thereby leaves fewer options open. For example Scrum prescribes the use
of timeboxed iterations, Kanban doesnt
7. XP (eXtreme Programming) is pretty prescriptive compared to Scrum. It includes most of
Scrum + a bunch of fairly specific engineering practices such as test-driven development
and pair programming
8. One of the main differences between Scrum and RUP is that in RUP you get too much, and you
are supposed to remove the stuff you dont need. In Scrum you get too little, and you are supposed
to add the stuff that is missing. Kanban leaves almost everything open. The only constraints are
Visualize Your Workflow and Limit Your WIP. Just inches from Do Whatever, but still
surprisingly powerful.
9. Dont limit yourself to one tool. Mix and match the tools as you need! I can hardly
imagine a successful Scrum team that doesnt include most elements of XP for example. Many
Kanban teams use daily standup meetings (a Scrum practice). Some Scrum teams write some of
their backlog items as Use Cases (a RUP practice) or limit their queue sizes (a Kanban practice).
Whatever works for you.
10. The general mindset in both Scrum and Kanban is less is more. So when in doubt, start
with less.