|
Script to display the count of WebTable/Link/Image in the browser
Set b = Description.Create
b(“micclass”).value = “WebTable” ‘insert “Link” or “Image” in place of “WebTable”
Set ls = Browser(“Database/SQL Server Interview”). Page(“Database/SQL Server Interview”).ChildObjects(b)
Msgbox ls.count
Set b = Nothing
Set ls = Nothing
================================================
Script to display the count of Links
Set a = Description.Create
a(“micclass”).value = “Link”
Set ls = Browser(“name:=Data.*”). Page(“title:=Data.*”).ChildObjects(a)
Msgbox ls.count
Set a = Nothing
Set ls = Nothing
=============================================================================
To click a hyper link
Set a = Description.Create
a(“micclass”).value = “Link”
a(“text”).value = “Interview Tips”
Browser(“name:=Data.*”). Page(“title:=Data.*”).link(a).click
Set a = Nothing
===============================================================================
To pass custom step to test results
Set a = Description.Create
a(“micclass”).value = “Link”
a(“text”).value = “Interview Tips”
Set ls = Browser(“name:=Data.*”). Page(“title:=Data.*”)
ls.link(a).click
Reporter.ReportEvent micPass, “Custom Step”, “The user-defined step Passed.”
Set a = Nothing
Set ls = Nothing
================================================================================
Clicking the link(“Interview tips”) with Descriptive programming
Set aTitle = Description.Create
aTitle(“micclass”).value = “Browser”
Set aPage = Description.Create
aPage(“micclass”).value = “Page”
Set aLink = Description.Create
aLink(“micclass”).value = “Link”
aLink(“text”).value = “Interview Tips”
Browser(aTitle).page(aPage).Link(aLink).Click
=====================================================================================
To display the browser names
Set aBrowser = Description.Create
aBrowser(“micclass”).value = “Browser”
Set aTemp = Desktop.ChildObjects(aBrowser)
msgbox aTemp.count
For i = 0 to aTemp.count-1
c = aTemp(i).getroproperty(“name”)
msgbox c
Next
=====================================================================================
When in case of multiple browsers opened, use the 3rd line statement to identify the exact browser to perform the operation
Set aTitle = Description.Create
aTitle(“micclass”).value = “Browser”
aTitle(“name”).value = “Database/SQL Server Interview Questions”
Set aPage = Description.Create
aPage(“micclass”).value = “Page”
Set aLink = Description.Create
aLink(“micclass”).value = “Link”
aLink(“text”).value = “Interview Tips”
Browser(aTitle).page(aPage).Link(aLink).Click
=====================================================================================
Tweet This Post
19 Mar, 2009
agile development agile software testing agile testing
- In an agile team Quality is “everyone’s responsibilityâ€.
- QA team continuously measures the Quality and provides the feedback.
- Role of QA changes within the life cycle of the Iteration.
- Test Automation is heavily used for regression testing while QA Engineers focus on Increase the Test coverage for “Any time Regressionâ€.
- Automation helps QA’s to focus on exploratory testing, as one can focus on other important stuffs.
- Quality is not added later, it evolves gradually.
|
|
Traditional
|
Agile
|
|
Change
|
Manage & control it
(Hard to accommodate)
|
Change is inevitable
|
|
Planning
|
Comprehensive up
front design
|
Plan as you go
|
|
Collaboration
|
Work alone
|
Work with Devs and BAs
|
|
Hand Offs
|
Formal entrance and
exit criteria
|
It’s not a relay race:
collaborate
|
|
Test Automation
|
System-level, built by tool specialists,
created after the code is “doneâ€
|
All levels, built by
everyone, an integral
part of the project
|
I found this article by Jack Milunsky,
QA is always near and dear to our hearts. We all talk a lot about the fact that Quality is “King” but we certainly don’t show it. In fact, we cut quality without even so much as a thought – “It’s in our bones” (Ken Schwaber). For most of my software career, QA has always been an afterthought. Developers pushed to the limits, dates slipping, so what’s the natural thing to do, cut quality, it’s the easiest and quickest thing do. The problem with cutting quality and what we don’t realize is that technical debt starts to rise exponentially. Eventually, and it’s not even that long, 3 – 5 years for most companies, your codebase will drive you and your company into a corner.
So how can you tell that your company is in this situation? Here are some tell tale signs:
* New features start to take longer and longer to develop
* Fewer people on the team know and understand the codebase
* Making even the slightest changes breaks the code
* Longer QA cycles at the end of a release
* Rising Maintenance and support costs
* More competitors enter the space
* Shrinking customer base
How to get out of the mess ….
So if you find yourself in this same position what do you do. Well in some cases there’s not much you can do and you’ll be forced to start again from scratch. However, if you’re lucky to catch this early enough, these are the things to start doing right away.
Plan on refactoring your codebase as soon as possible to start to pay back some of the technical debt – although in some cases this might be too late. You can do this in stages, by layer, by feature and functionality, or start with the highest risk code first.
Start implementing test harnesses if you don’t already have them, especially around fragile code segments
Develop an automated and continuous integration environment where code is compiled automatically on check-in
Do a quality release (bug fixes, refactoring only) with no new features added
Ensure you have a senior architect who knows what he is doing
Start doing peer code and design reviews
If your team is too junior shaking things up a bit may be a good approach
How to avoid these pitfalls from the getgo …
* Plan on continuously re factoring the code base. For every 2 week (10 days to be specific) sprint we spend at least 2 days re factoring code from previous Sprints … the result is a solid emergent architecture that grows as the features warrant and nothing more.
* Plan on fixing bugs first – at least high priority one and ones that matter. We spend a further at least 2 days every Sprint resolving bugs. Yes, do the math that leaves only 6 days out of every sprint to do new development work. Only a decade ago, this may not have been possible to work this way. But with changes in technology, we use Ruby on Rails, it is possible to do rapid software development and get a lot done in the 6 days, and even more so with a nice clean emergent architecture
* Don’t just do pair programming. But also pair developers with QA. QA folks think differently to developers and can add a ton of value front end loaded. This pays big divedents in the long run.
* Retrain your QA teams to learn how to write unit tests/test harnesses and to use tools to monitor unit test code coverage. This not only makes them better at QA but increases their skill level and offers them new career opportunities in the long run
* Strive for 100% unit test code coverage. Don’t do it just for the sake of it but you’ll be surprised how this will save your butt time and time again. Writing unit tests is not easy to do even when the environment supports it. The investment is well worth it. We have 100% unit test coverage using RSpec and as a result we are able to deploy new builds to production every 3 days and do this with confidence.
* Automate as much of the functional testing as possible.
* Ensure that code is integrated and automated tests are run continuously (In our environment, that means multiple times a day) and any issues that surface must be addressed immediately.
* Ensure that you define your test criteria up front, even at the user story level.
* Involve QA continuously rather than throwing the code over the wall to them when you’re “code complete” – what were we thinking when we came up with this terminology – in my day code complete meant another 3 months of fixing bugs. Whereas now, code complete means ready to launch.
* Continuous and on-going peer code and desing reviews
* Pair programming as often and as required
Tweet This Post
|