I would like to introduce you to some of the advanced LoadRunner Google Web Toolkit features. Let’s take a look at troubleshooting items that occur during Code Generation and/or Replay phases. We will identify existing problems and suggest ways to fix them, enabling to regenerate good scripts.
We are pleased to announce the release of Appium 1.5.2 through npm and on Sauce Labs! This is a bug fix release that deals with many issues with 1.5.1, including a major bug where large Android applications would cause Appium to run out of memory and die.
- deprecated --command-timeout. Use newCommandTimeout desired capability instead
- ensure implicit wait can be set through timeout method
- add better logging for EPIPE errors
- make sure ipa files are handled correctly for installing on real devices
- ensure that existing SafariLauncher on device is used instead of rebuilding and reinstalling
- fix issues with getting webview contexts on real devices
- add full timeout support through timeout method
- make sure Xpath searches respect implicit wait timeout
- make sure bare Instruments process arguments are accepted
- fix failure when apk file is too large
- re-implement setting geolocation so it does not use Telnet
- add support for Chromium browser
- fix issues with flick
- fix bug where touch action release would throw an error
- fix bug in later Android SDK version where noticing a newly started avd would fail
- implement autoWebviewTimeout
Listening to experts in our field is one of many ways we can learn and help improve the applications we build as members of the .NET community. We think you should make it a point to hear these two .NET speakers if you get the chance.Caleb Jenkins
Caleb Jenkins is an International Speaker, Author and Senior Manager at Avaya – leading development teams in North America, Ireland and India. He has led teams of people for the last 15 years, and recently managed the UX product design team at Sabre GetThere, co-chaired Sabre’s Employee Innovation Council #BringIt, and was a Principal Agile Coach for Sabre Airline Solutions working with international development teams around the globe.
Longtime community leader, 6 time recipient of the Microsoft MVP award, and former Microsoft Developer Evangelist – working with some of the largest organizations in the region, Caleb is a Microsoft Certified Solution Developer, Certified Trainer and .NET architect. Caleb has helped to design and implement enterprise .NET Solutions for some of the largest companies in the world.
Niraj Bhatt works as an Enterprise Architect for a Fortune 500 company with an innate passion for building and studying software systems. He is a top rated speaker at various technical forums including Tech Ed, MCT Summit, Great Indian Developer Summit, Tech Days, Virtual Tech Days, etc.
He enjoys working on IT innovations that impact enterprise’s bottom line, integration and architecture of systems, performance tuning, & review of enterprise applications with a specialized focused on enhancing team’s productivity.
When he’s away from his laptop, you will find Niraj enjoying automobiles, pottery, rafting, photography, cooking & financial statements though not necessarily in that order. See what he’s up to now on his blog and on Twitter @nirajrules.
Agile brings about a change in mindset and mechanics, which affects both employees and customers. Whereas change can create new opportunities, it will also be met with resistance. Agile change really isn’t any different than any other culture change, ergo the resistance will have similar patterns. There are many reasons for resistance. Here are some of the patterns:
Here we go again! It is comforting when things remain the same. Employees have seen change efforts come and go without any true commitment and may attempt to wait the new ones out.
- What can you do? The commitment to change must be clearly stated. The change initiate must be treated as a program, with clear motivations and rewards for change.
Fear of the unknown. Change is often defined by a journey into the unknown and it natural to resist what we don’t understand. For most, it is unclear what the change will entail.
- What can you do? Leaders should provide a vision of what the new world will look like
Lack of communication.Employees need to know what is occurring to them. As information trickles down from the top, the message can be lost.
- What can you do? Plan for continuous communications at all levels is important. Include various communication channels and messages from as many champions as possible.
Change in roles.Some employees like to retain the status quo and do not want to see their roles changed. When roles are vague, some don't know where they fit in the new culture, making them feel excluded. When they have no say in their new roles, they can feel alienated.
- What can you do? Discuss the role changes with employees. Give them time to adapt to the roles or give them time to try new roles.
Competing initiatives.Introducing an agile initiative when there are already multiple initiatives occurring can lead to employees feeling overwhelmed, causing them to resist. Hardly an auspicious start!
- What can you do? It is important for management to prioritize initiatives and focus on the higher priority ones.
Change for people, not leaders. When asked “Who wants change?”, everyone raises their hands. But when asked, “Who wants to change?”, no one’s hand goes up. This can be particularly true with leaders. Leaders want change to occur within their teams but are not particularly interested in changing themselves and this may be been prevalent in past change initiatives.
- What can you do? Acknowledge the change that the leaders must make and convey the leaders’ commitment to change.
New management's need to change something. New leaders often feel they must show they are action-oriented. They may reason that the change that worked in their previous company should work here. Some know their term is short, so they are not interested in long-term change. Some are unaware of what it takes to affect culture. Employees who are used to this scenario may resist.
- What can you do? Avoid what may appear to be random changes. Ensure the Agile change is aligned with better business outcomes and not just to do Agile.
It will not always be possible to identify and manage all types of resistance. However, it must be treated as a real and tangible activity. It is better to start addressing resistance to change in a pro-active manner. The more you review and enact the "What can you do?" tips, the more likely you will increase your changes of a successful Agile change (or any culture change).
When I first started at Sauce, one group within the Engineering organization was called *Dev, referred to in conversation as “StarDev.” *Dev was so named because they were the wildcard development group – some of their work touched on this part of the infrastructure, or this part of the product, or this part of the Web interface, and so on. As a result of this interdisciplinary approach, much of the product and operational development fell under their purview, but it was difficult to tell exactly what it was they were responsible for. What was even more difficult was that when it came time to undertake actual projects, there was no clear delineation of what role *Dev needed to play in their development.
When you see the emergence of a group like *Dev, it’s a clear sign that your engineering organization has reached an evolutionary stage common to startups. That’s the stage where you go from a handful of people sitting in a room together hacking out code, to trying to formalize responsibility for parts of the product while also engaging other stakeholders within the company, like Product Management. The tendency in these moments is to think in terms of silos – this group is responsible for operations, this one for the front-end interface, this one for backend infrastructure, this one for testing, and so on. The problem with this approach is that it almost always results in organizational mutations like *Dev. because the nature of today’s software and technologies doesn’t recognize such neat distributions of responsibility. This is especially true of PaaS, IaaS, and other cloud-based offerings, that are themselves hybrid service/product offerings. I saw this phenomena occur when I took the reins at Lynda.com. Although the team had grown to more than 30 engineers, they could only work on one project at a time. The whole team “swarmed” on a given feature, since nobody owned any one piece of the service. The first change that I made was to organize the team into smaller scrum teams that each owned a feature from end to end. This simple reorganization unblocked the log jam that had been created by the swarm mentality, and allowed teams to work on multiple projects at once.
When I first became aware of the existence of *Dev at Sauce Labs, I knew that the company was ready to take the next step in its evolution. In its interdisciplinary nature you could see that there was a clear recognition of how to approach the development of our offerings, but the organizational concept was too rooted in traditional, hierarchical managerial structures. What we needed was to get back to those small handfuls of people who could focus on specific projects, but have some method for guiding ourselves to specific goals, and make sure we we were on track.
This is the point at which introducing an Agile Scrum approach to development is the critical catalyst for the transformation from Engineering to DevOps. DevOps, like *Dev, is essentially interdisciplinary, but needs the project-oriented approach to getting things done that Scrum provides to keep it from losing its organizational coherence. By thinking of our work in terms of Epics that describe ongoing areas of activity, which in turn are made up of smaller Stories that are, in effect, composed by the teams that work on them, we have a conceptual framework for our activity that embraces the interdisciplinary demands of DevOps. By then tackling these stories in two-week sprints, we are able to define the specific tasks that are required to accomplish our goals, and measure our progress against them. While this may not immediately achieve “continuous development” or even “continuous integration”, it’s only by breaking down the tendency toward silos and monolithic organizational structures that we can then start to think about the changes in tools, systems, and processes that would be necessary to achieve those states.
We introduced Scrum at Sauce in the first quarter of 2016, and since then a few things have happened.
Code quality improved dramatically. We reorganized into small scrum teams, each responsible for one area of the service. In the past, engineers were responsible for multiple areas of the code, and were always working on multiple projects, thus often losing focus and lacking ownership of code. Scrum teams were given ownership of a single part of the codebase, and were able to focus on one thing at a time. It was also made clear that teams were absolutely responsible for the quality of their code. All of this combined to create a sense of “pride of ownership”. And as we all know, people always treat their own cars MUCH better than rental cars. The result here was the same – exponentially better quality.
We discovered a lot of problems! At first, this was startling to the team. But I assured them that this was normal, and exactly what we wanted. These problems were not new, they had always been there, but had been swept under the rug, masked. Since everyone was so frenetic and unfocused prior to scrum, we hadn’t noticed all these issues. The clarity that scrum gave us about these issues forced us to face them, rather that ignore them. The key things that we found were around technical debt. We put all of these into our team backlogs and started to figure out how to tackle them. We didn’t like what we saw, but at least we knew what the reality was.
We realized how thinly spread we were. Before scrum, all the developers were incredibly busy, but we were not getting things done at the pace that we expected. When we broke out into scrum teams, each with a distinct responsibility, we saw what the problem was. We were trying to do way too much given our capacity. Putting all desired new functionality, enhancements, bug fixes, infrastructure work, security improvements, and technical debt into backlogs showed us that demand was significantly higher than supply. This forced us to prioritize the work, and to pare down work to the most important features. That forced us to listen even closer to our customers so that we knew what was most important to them. And finally, it helped us decide what level of capacity we wanted so we could make better hiring decisions.
The move to scrum created a much more satisfied team, all around. The DevOps team was happy because they now had clearer focus on on their responsibilities. I made it clear that we had to set a sustainable pace, because this is not a sprint (no scrum pun intended!), nor is it even a marathon, this is something that we should be able to do indefinitely. Burned out engineers only make things worse. And, finally the product and sales teams were happier because they saw that things were getting done, albeit in smaller increments. Overall, everyone felt that we were getting unstuck, and bringing clarity to our work that removed the “wildcard” factor that had previously dominated.
We have a long way to go on this journey to DevOps, but I think we’re off to a great start.
FixStream Meridian with DC RUM I’m excited to co-author this blog with Bishnu Nayak from our new partner FixStream. I’ll write the Dynatrace perspective to set the stage, then let Bishnu add more details on how FixStream’s Meridian offering extends the definition and implementation of comprehensive performance visibility. At Dynatrace, we – along with our […]
The post Closing Gap between EUE, Application & Infrastructure Performance appeared first on about:performance.
I pair on all my conference sessions. It’s more fun, participants get a better learning opportunity, and if my pairs are less experienced at presenting, they get to practice their skills. Big bonus: I learn a lot too!
I’ve paired with quite a few awesome people. Janet Gregory and I have, of course, been pairing for many years. In addition, I’ve paired during the past few years with Emma Armstrong, Abby Bangser, and Amitai Schlair, among others. I’ve picked up many good skills, habits, ideas and insights from all of them!
The Ministry of Testing published my article on what I learned pairing with Abby at a TestBash workshop about how distributed teams can build quality into their product. If you’d like to hone your own presenting and facilitating skills, consider pairing with someone to propose and present a conference session. It’s a great way to learn! And if you want to pair with me in 2017, let me know!
Surround SCM 2016 is now available and it includes some great new features you don’t want to miss out on. Here’s a quick look at what’s new.Capture electronic signatures and run audit trail reports for compliance purposes
To meet Title 21 CFR Part 11 compliance requirements, you can enable electronic signatures for workflow states to track when files move to the state and who signed off on the files in that state. Signature records are stored in the mainline database, and you can run audit trail reports to validate and review the records during an audit or for other compliance purposes.
Perform the following tasks to capture electronic signatures and create audit trail reports.
1. Configure workflow states that require an electronic signature. You can add new states or edit existing ones to change the signature requirements. More info
2. Configure compliance server options to specify the electronic signature settings, such as the signature components and the certification message to include with signatures. More info
3. Users responsible for signing off on files set states on files and enter their electronic signature. More info
4. Create and run audit trail reports to review electronic signature information, such as when files entered specific states and the users who entered signatures. More info
Administrative users can configure workflow states to automatically reset to the default state if the file version changes. This helps ensure files are not left in an incorrect state when they are updated. For example, you can configure the Reviewed state to reset to the default state to automatically restart a review workflow when additional changes are checked in. More infoRun reports from the Source Tree window
There are two new ways to run reports on files from the Source Tree window.
You can quickly create and run one-time use reports from the Tools > Quick Reports menu. You no longer need to open the Reports dialog box first to create reports you don’t need to save. More info
You can also create custom shortcut menu items to run saved reports when you right-click repositories. Before you can run reports this way, you need to create a plug-in for the menu item and add it to the repository shortcut menu. More info
Enable syntax highlighting to show specific text in different styles and colors in the built-in file viewer and editor. This makes file contents easier to read when you view and edit files, perform code reviews, and search for text in files. More info
We hosted this month's Lean Coffee at Linguamatics. Here's some brief, aggregated comments on topics covered by the group I was in.
It is fair to refer to testers as "QA"?
- One test manager talked about how he has renamed his test team as the QA team
- He has found that it has changed how his team are regarded by their peers (in a positive way).
- Interestingly, he doesn't call it "Quality Assurance" just "QA"
- His team have bought into it.
- Role titles are a lot about perception: one colleague told him that "QA" feels more like "BA".
- Another suggestion that "QA" could be "Quality Assisting"
- We covered the angle that (traditional) QA is more about process and compliance than what most of us generally call testing.
- We didn't discuss the fairness aspect of the original question.
What books have you read recently that contributed something to your testing?
- The Linguamatics test team has a reading group for Perfect Software going on at the moment.
- Although I've read the book several times, I always find a new perspective on some aspect of something when I dip into it. This time around it's been meta testing.
- The book reinforces the message that a lot of testing (and work around the actual testing) is psychology.
- But also that there is no simple recipe to apply in any situation.
- We discussed police procedural novels and how the investigation, hypotheses, data gathering in them might be related to our day job
When should we not look at customer bugs?
- When your product is a platform for your customers to run on, you may find bugs in customer products when testing yours.
- How far should you go when you find a bug in customer code?
- Should you carry on investigating even after you've reported it to them?
- In the end we boiled this question down to: as a problem-solver, how do you leave an unresolved issue alone?
- Suggestions: time-box, remember that your interests are not necessarily the company priorities, automate (when you think you need lots of attempts to find a rare case), take the stakeholder's guidance, brainstorm with others, ...
- If the customer is still screaming, you should still be working. (An interesting metric.)