When you switch to the sales department, you quickly realize: Your consumption of coffee is going to increase. Because if the client asks you whether you would like some coffee—would you want to start off a personal meeting with a “No”?
Coffee is usually part of the small talk that creates a positive basis for the first encounter at the beginning of most sales meetings. As you talk about coffee—the type, the method of preparation, etc.—and walk towards the coffee table, you get to know each other and start building a relationship. This is a basis that you learn to appreciate.
Or it was, until Coronavirus! Not only did the cancellation of flights make reaching the clients more difficult, but the whole situation also left us at a loss at first: How were we supposed to identify new issues with existing or new clients? How were we supposed to convince the client to choose us, in light of smaller budgets and reprioritization, without being on site? How were we supposed to build the necessary trust without ever having sat down together?
For the service sector in particular, these obstacles seemed to be insurmountable at first—but fortunately, that changed quickly. Just like the other divisions of ZEISS Digital Innovation, here i sales and in the field of positioning, we examined the tools used by our development teams, who have been practicing distributed software development for years. And we used them for inspiration.
The comparison of all the sales colleagues held every two weeks has always been done on a distributed basis and supported by our CRM (SalesForce) anyway. In addition, our new customer sales department and the marketing team also switched to a daily mode. For example, we shortened our sales sprint from four months to four weeks, i.e. the marketing team synchronizes with new customer sales along the campaigns every morning at 9:30 a.m., and they discuss events, items on their to-do lists, and challenges. Every four weeks, we do a retrospective, a review and planning, concluding and reflecting upon the past four weeks and planning the following weeks. The new four-week cycle was necessary because at the end of March 2020, nobody was able to foresee which issues would need to be prioritized in June, but that would have been a necessary prerequisite to continue the four-month cycle we used before the pandemic.
In order to be able to do the new, distributed dailies from home too, we used Skype for Business and Microsoft Planner at first. Later, we switched to MS Teams, using the associated MS Whiteboard for content-related work as required.
Now we have a tool set that has also proven to be very beneficial in the interaction with our clients over the past weeks. MS Teams has become customary in virtually every organization, and everybody is much more willing to use conferencing tools, allowing us to take this path quickly and straightforwardly. An aspect that we find to be particularly favorable is the willingness to turn on the video stream in a meeting instead of only using audio. You could say that the video stream between the parties involved is a substitute for having coffee together: it gives both parties a better sense of each other and reduces issues of interpretation that often occur in phone conferences. With new clients or new contacts in particular, this is a true blessing for any future collaboration.
We also needed to adapt our rituals in the preliminary project stages. For example, we could no longer do a two-day project vision workshop with the client on site. Alternatively, we now do 4 x 0.5 days, each with 2 x 2 h sessions in MS Teams, immediately documented by means of a Microsoft Whiteboard, where they are visible for and editable by everyone. This way, we have been able to start several projects during the Corona crisis—even with new clients who have never worked with us before.
This is an entirely new scenario that is still somewhat surreal and strange for us here in sales, and that will likely permanently change the sales process. In the end, we are having coffee together again—everyone in their own workspace, connected by MS Teams, Skype and the like.
Software development projects live from the use of modern testing tools, which support the project members in their work. Selenium has been available since 2004 and may seem a bit dusty, but it is not out of fashion. With Selenium 4 it is catching up with the new challenges. With this blog series, I want to show what Selenium 4 brings and how important features like screenshots, videos, reports and approaches of AI can be implemented using simple means. I will try to evaluate the approaches according to their added value (The Good) and their challenges (The Bad) as well as give useful hints (… and the Useful).
Jason Huggins started working on Selenium back in 2004 as an internal project for testing websites. Over time, Selenium became the leading tool in many development projects or served as the basis for other testing tools. Currently, the framework feels a bit old-fashioned, but it stands out from its challengers with its broad support of languages (Ruby, Java, Python, C#, JavaScript) and browsers (Firefox, Internet Explorer, Safari, Opera, Chrome, Edge and others).
What is new in Selenium 4?
Version 4, which is announced for 2020, attempts to bring selenium into the modern age. This includes the following innovations:
WebDriver API becomes a W3C standard
This means there will be only one WebDriver for all browsers.
Selenium4 IDE TNG
„TheNextGeneration“ Selenium IDE is based on Node JS and is available for Firefox and Chrome. Parallel test runs can be started and there is extended test protocol information (test result, runtime etc.).
Improved WebDriver Grid
Setup, administration and docker support have been improved.
Furthermore
There is a better UI and the reporting / logging have been optimized.
Documentation
Version 4 should come with a detailed documentation and new tutorials.
With version 4, Selenium consists of the following parts: The Selenium WebDriver, the Selenium IDE and the Selenium Grid. The Selenium WebDriver is a collection of different programming language integrations to control browsers for test automation. The Selenium IDE is a Chrome or Firefox add-on to start test automation directly from the browser without programming knowledge and allows the recording and the play back of test cases in the browser. The Selenium Grid allows controlled and simultaneous test executions on different machines and supports the administration of different test environments from a central point. Thus, a test case can be tested against different browser or operating system combinations or a list of test cases can be executed scaled and distributed over several machines.
Selenium 4
The Good
The Bad
… and the Useful
WebDriver API >> W3C Standardized Selenium 4 IDE TNG Improved WebDriver Grid Documentation
New challenger like cypress etc. Selenium 4 was announced for 2019
Newer frameworks for test automation already have a function for creating screenshots. But with a few lines of code, you can also add the possibility to store screenshots in selenium tests.
private void screenShot(RemoteWebDriver driver, String folder, String filename) {
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyyMMdd_HHmmss");
String timestamp = dateFormat.format(new Date());
try {
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
// Now you can do whatever you need to do with it, for example copy somewhere
FileUtils.copyFile(scrFile, new File(folder + filename + "_" + timestamp + ".png"));
}
catch (IOException e) {
System.out.println(e.getMessage());
}
}
However, you should always pay attention to the purpose of screenshots when creating and storing the file. Screenshots can be used for debugging purposes and to point out problems. Therefore, it makes sense to create screenshots only when problems occur. According to this approach, the screenshot functionality can be extended by a flexible and global switch that can be set as needed.
On the other hand, screenshots can be used to document the test results and may even be mandatory in some projects, as legal or other requirements must be met in such cases. In this case, the storage of the screenshots must be traceable, and each generated file must be assigned to a test case and the corresponding test run. According to this approach, the file name must have a reference to the test case and a suitable timestamp. Furthermore, the storage directory for this one test run must also be created and named.
Screenshots
The Good
The Bad
… and the Useful
Allows the verification of the test run results
Can only show a snapshot
Can be used for “debugging”
In my next post we will create a video of the test implementation.
The current crisis, caused by COVID-19, is challenging the most companies worldwide for several weeks now. From one moment to the next nearly 95% of our colleagues moved in to their home office. Most of them are still working from home. How does that fact affect my work in the Sales and Marketing team?
While working in distributed teams and independent of the location is quite common (have a look at our last blog post: Software Development in Corona times – Business as usual?) it was a novelty for our central services (accounting, IT, HR, Marketing, …). As an internal service provider for the employees of ZEISS Digital Innovation the main focus of our work was to be a local contact for our „customers” and react directly to their requests. Simultaneous to our organizational affiliation to Team ZEISS and the high workload that came along with the related brand change, the shift to home office confronted us with new challenges.
Figure 1: My workplace in the home office
How did we manage this transition mainly trouble-free and while keeping up our high level of performance? By learning from agile methods!
For many years we are following the basic principles of agile procedures in our projects as well as in management and developed our own agile process based on Scrum. For our collaboration in the central services we implemented some of the values, artifacts, and methods as well. This is helping us in this difficult stage. In general, for our internal corporate communication and especially for the collaboration of my team, which now consits of five team members. At this occasion it is important to mention, that we are only orient ourselves towards these procedures and don’t apply them like they appear in textbooks.
With an iterative approach, including Planning, Review and Retrospective, we ensure that our campaigns remain innovative, that we focus on the right things even when there are many campaigns running in parallel, and steady questioning ourselves. Meetings for reflexion (similar to project retrospectives), where we deduce Lessons Learned, belong to our daily work as well as an open culture of communication, honest feedback and creative or brainstorming events. Creative work and an agile mindset require a certain readiness for flexibility, so wereorganized our collaboration methods and quickly acclimatised ourselves to the new situation.
Figure 2: Team retro with improvised whiteboard
But what does that mean in practice? Which „tools“ helped us to organize our work efficiently even in the home office and while working distributed?
Dailys
Because we didn`t meet in our office every day and did not notice directly and across the desk on which topics the other team members are working on, we quickly noticed a higher need for coordination. After a short time we established a daily meeting as a reaction. Every morning the team members sync their daily tasks and report about the tasks they dealt with the last day. We defined a timebox of 20 minutes for ourselves. It is important, that everybody gets the chance to speak and also shortly tells if there are maybe challenges that could affect their work (like too many meetings, childcare and home schooling, …). To make sure that we all stay in the defined timebox we nominated a Scrum Master who moderates the meeting. She has to ensure, that maybe upcoming discussions are clarified later in separate ad-hoc meetings and not block the daily.
Iterative Planning in short terms
In consequence of Corona and the accompanying ever-changing general conditions (like cancelled events, changing communication channels, …) we switched from a three-monthly planning cycle to a four-week period. So we can customize our tasks continuous to the quick changing priorities. To make sure that we nevertheless do not forget several long-term tasks, we have a backlog were we store all the activities which we want to work on in a long term, but are not urgent or important at the moment.
This backlog is closely linked to the next topic.
Visualization with suitable tools and a good infrastructure
Technical conditions are essential for working together. A Sharepoint or OneDrive for data sharing, video conferencing via Skype or MS Teams, a Wiki with a clear documentation of the campaigns and a joint task board are worth a mint and only a small set of the tools we are working with. To keep an eye on our tasks, we use MS Teams and the integrated Microsoft Planner. There we collect and record (similar to a Kanban Board) all our tasks and thus are able to evaluate in our Planning and Review meetings what we managed in the last sprint and what we want to do in the next iteration. As an internal service centre we have a lot and steady upcoming requests from different stakeholders, so we use the board to document all requirements the to ensure that (especially in the case of an unexpected absence or in Substitution situations) not been forgotten. In general transparency is one of our top priorities, but however we focus on the (a bit customized) agile manifesto: working software campaigns over comprehensive documentation (https://agilemanifesto.org/iso/de/manifesto.html).
Fair enough when tools and processes are working. But what about the interpersonal communication? We strive to have an atmosphere in our communication which is basing on open communication and values like trust, commitment, openness and mutual respect. And in the middle of this communication there are always humans and a working team, that must rely on each other. This team spirit also rises by the short talks in the meantime, by spending a lunch break together or making some jokes in the coffee kitchen. All this is really hard to put in practice when „social distancing“ and home office is on the daily schedule. To prevent that we drift apart as a team, we implemented a weekly virtual coffee break. We use this event to talk with a cup of coffee (or something else) about off topics and what concerns us at the moment. Just the things we would normally talk about in our breaks and in the corridor – not about thing what we have to deal with in our daily business. And of course, with video, to see each other from time to time.
Figure 3: Weekly virtual coffee break in the team
Also, beyond team level there are some established formats resulting from our agile management process, that help us – e.g. our ZEISS Stand-up(general company meeting). Normally in a six week regular circle, our management informs about all important topics, data and facts. Every employee who is interested in participation, has given the opportunity to follow the explanations in his working time via Skype or on-site and ask questions afterwards. As a important cornerstone of our company information and communication this is ensuring transparency und takes since the 20.03.2020 place every week, to inform about all the actual corporate development in the crisis and the measures we adopted because of that. Next to the economic situation there were also some special topics to talk about, like the hygiene concept or the „Corona parental benefit“ when employees with children have minus hours. Another small puzzle piece, that gives us security and trust and make the corporate collaboration easier in this crisis.
We would like to present our agile visualization tool, the QA battle plan, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.
Like a wrong architectural approach or using the wrong programming language, the wrong testing and quality assurance strategy can result in adverse effects during the course of a project. In the best case, it only causes delays or additional expenses. In the worst case, the tests done prove to be insufficient, and severe deviations occur repeatedly when the application is used.
Introduction
Agile development teams notice issues and document their effects in the Retrospectives, but they are often unable to identify the root cause, and therefore cannot solve the problem because they lack QA expertise. In such cases, the teams need the support of an agile QA coach. This coach is characterized on the one hand by his knowledge of the agile working method, and on the other hand by his experience in agile quality assurance.
The first step in the agile QA coach’s work is recording the status quo of the testing methods of the agile development team. For this purpose, he will use the QA battle plan, e.g. within the framework of a workshop. The QA battle plan provides a visual aid to the development teams which they can use to assess the planning aspects of quality assurance. Throughout the project, the QA battle plan can also be used as a reference for the current procedure and as a basis for potential improvements.
Anti-patterns
In addition, the QA battle plan makes it possible to study the case history of the current testing method. By means of this visualization, the agile QA coach can reveal certain anti-pattern symptoms in the quality assurance and testing process, and discuss them directly with the team. In software development, an anti-pattern is an approach that is detrimental or harmful to a project’s or an organization’s success.
I will describe several anti-patterns below. In addition to the defining characteristics, I will present their respective effects. As a contrast to the anti-pattern, the pattern—good and proven problem-solving approaches—will also be presented.
The “It’ll be just fine” Anti-pattern
This anti-pattern is characterized by the complete lack of testing or other quality assurance measures whatsoever. This can cause severe consequences for the project and the product. The team cannot make any statement regarding the quality of their deliverables, and consequently, they do not, strictly speaking, have a product that is ready for delivery. Errors occur upon use by the end user, repeatedly distracting the team from the development process because they have to analyze and rectify these so-called incidents, which is time-consuming and costly.
No testing
Effect
Solution
• There are no tests
• No quality statement
• “Leave quickly”
• Testing is done in the user’s environment
• Introduce QA
The solution is simple: Test! The sooner deviations are discovered, the easier it is to remove them. In addition, quality assurance measures such as code reviews and static code analysis are constructive measures for consistent improvement.
The Dysfunctional Test Anti-pattern
ISO 25010 specifies eight quality characteristics for software: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. When new software is implemented, the focus is most often on functional suitability, but other characteristics such as security and usability play an important role today as well. The higher the priority of the other quality characteristics, the more likely a non-functional test should be scheduled for them.
Therefore, the first question to be asked at the start of a software project is: Which quality characteristics does the development, and therefore the quality assurance, focus on? To facilitate the introduction of this topic to the teams, we use the QA octant. The QA octant contains the quality characteristics for software systems according to ISO 25010. These characteristics also point to the necessary types of tests that result from the set weighting of the different functional and non-functional characteristics.
Functional tests only
Effect
Solution
• There are only functional tests
• No quality statement about non-functional characteristics
• Discuss important quality characteristics with the client
• It works as required, but…
• Non-functional test types
• Start with the QA octant
The Attack of the Development Warriors Anti-pattern
Many agile development teams—especially teams that consist only of developers—only rely on development-related tests for their QA measures. Usually, they only use unit and component tests for this purpose. Such tests can easily be written with the same development tool and promptly be integrated in the development process. The possibility to obtain information about the coverage of the tests with respect to the code by means of code coverage tools is particularly convenient in this context. Certainty is quickly achieved if the code coverage tool reports 100% test coverage. But the devil is in the detail, or in this case, in the complexity. This method would be sufficient for simple applications, but with more complex applications, problems arise.
With highly complex applications, errors may occur despite a convenient unit test coverage, and such errors can only be discovered with extensive system and end-to-end tests. And for such extensive tests, the team needs advanced QA know-how. Testers or trained developers have to address the complexity of the application at higher levels of testing in order to be able to make an appropriate quality statement.
The attack of the development warriors
Effect
Solution
• Development-related tests only
• No end-to-end test
• Include a tester in the team
• No tester on the team
• Bugs occur with complex features
• Test at higher levels of testing
• 100% code coverage
• Quick
The “Spanish Option” Anti-pattern
The time in which a function has been coded and is integrated into the target system is becoming ever shorter. Consequently, the time for comprehensive testing is becoming shorter as well. For agile projects with fixed iterations, i.e. sprints, another problem arises: The number of functions to be tested increases with every sprint.
Plain standard manual tests cannot handle this. Therefore, testers and developers should work together to develop a test automation strategy.
Manual Work
Effect
Solution
• There are only manual tests
• Delayed feedback in case of errors
• Everybody shoulders part of the QA work
• Testers are overburdened
• Test at all levels of testing
• Introduce automation
The Automated Regression Gap Anti-pattern
A project without any manual tests would be the other extreme. Even though this means a high degree of integration in the CI/CD processes and quick feedback in case of errors, it also causes avoidable problems. A high degree of test automation requires great effort—both in developing the tests and in maintenance. The more complex the specific applications, and the more sophisticated the technologies used, the higher the probability of test runs being stopped due to problems occurring during the test run, or extensive reviews of test deviations being required. Furthermore, most automated tests only test the regression. Consequently, automated tests would never find new errors, but only test the functioning of the old features.
Therefore, automation should always be used with common sense, and parallel manual and, if necessary, explorative tests should be used to discover new deviations.
100% test automation
Effect
Solution
• There are only automated tests
• Very high effort
• Automate with common sense
• Everybody is overexerted
• Manual testing makes sense
• Build stops due to problems
The Test Singularity Anti-pattern
Tests of different types and at different levels each have a different focus. Consequently, they each have different requirements regarding the test environment, such as stability, test data, resources, etc. Development-related test environments are frequently updated to new versions to test the development progress. Higher levels of testing or other types of tests require a steadier version status over a longer period of time.
To avoid possibly compromising the tests due to changes in the software status or a modified version, a separate test environment should be provided for each type of test.
One Test Environment
Effect
Solution
• There is only one test environment
• No test focus possible
• Several test environments
• Compromised tests
• By level of testing or test focus
• No production-related tests
• “One test environment per type of test”
The “Manual” Building Anti-pattern
State-of-the-art development depends on fast delivery, and modern quality assurance depends on the integration of the automated tests into the build process and the automated distribution of the current software status to the various (test) environments. These functions cannot be provided without a build or CI/CD tool.
If there are still tasks to be done relating to the provision of a CI/CD process in a project, they can be marked as “to do” on the board.
No Build Tool
Effect
Solution
• There is no build tool
• No CI/CD
• Introduce CI/CD
• Slow delivery
• Highlight gaps on the board
• Delayed test results
• Dependent on resources
The Early Adopter Anti-pattern
New technologies usually involve new tools, and new versions involve new features. But introducing new tools and updating to new versions also entail a certain risk. It is advisable to proceed with care, and not to change the parts/tools of the projects all at once.
While observing social distancing, video conferencing with friends has replaced going down to the pub. During one the subject of how corona influences our work life, popped up very fast.
The consensus was, that the ability to work was greatly impacted and that for some it even had completely disappeared. Their employers were simply not able to supply the necessary infrastructure. And even after the infrastructure eventually was set up the reality set in: It is complicated! Who may talk? Camera on or off? Please mute your microphone the kid is screaming in the background! You want to talk? Please un-mute you microphone! The connection is bad I only get every second word… The list is endless.
People simply are not used to working like this. Not least, because communication is more than exchanging words. During phone and video conferences the interpretation of body posture, facial expressions and gestures is far harder. That is a new situation, which requires great discipline and change in behaviour by all participants!
The discussions carry on and they alternate between reviews of video tools and how working in this situation is impossible. Meanwhile I am frantically searching for something to add to the discussion. But no matter how much I search, I only find one answer to the question “What has changed in your work situation since COVID-19?”, “Nothing really“.
Admittingly that is a slight exaggeration! The commute, the collective lunch break with the colleagues, the chat at the coffee machine – all this currently does not take place, and these are drastic changes and great losses. For people like me where home office is also a day-care and both parents work full time, distributed work can become quite a challenge.
But even in this situation the starting point is the same for everyone. So, you only have the choice to accept it and make the best of it. This shows how important it is to have gathered experience with working in distributed settings.
ZEISS Digital Innovation (formerly Saxonia Systems AG) has been following the basic principals of working in distributed teams for years. Not least to ensure a healthy work-life balance for the employees, it is important for companies to ensure that services can be provided from basically everywhere. This keeps travel expenses low and ensures that the necessary infrastructure does not have to be provided by the customer.
Figure 1: Distributed project work from a home office
During the five years that I have been working for ZEISS Digital Innovation I have only encountered one project, that united the complete development team at one site. My current project, that was started in September 2019, is extremely distributed, the six project members of ZEISS Digital Innovation are split between five sites and the project stakeholders are at two sites. Therefore, the distribution existed pre-COVID-19 and was identified as a project risk to be addressed.
In my view this was achieved with a simple sounding solution: direct communication.
The developers often used pair programming to not only ensure knowledge transfer, but also to get to know the programming style of the other developers. Apart from this, code reviews belong to our standard procedure. These are not only a quality assurance measure, but also distribute knowledge throughout the team. Beside the daily meeting for all project members, we also have established a “DEV-Daily”, in which the developers can focus on mainly technical issues.
Business requirements are mapped to technical solutions during regular refinement meetings. Ideas are collected, checked, adapted, discarded and created in no-holds-barred discussions. This leads to an area of creativity and free development, that all team members can contribute to, which in turn feel valued and included. Even during the distribution of the team, a real team spirit has developed!
The establishment of this open communication culture has led to a more intensive and frequent communication within the team. Be it one-on-one or in a larger group. One must always carter for the preferences of the individual team members. Some are early birds, at 8 o’clock they are fully in their flow, bursting with ideas to present to their colleagues, some barely can open their eyes at that time in the morning. Some need planned meetings to have time for preparation, others easily hop between subjects and you can call them anytime.
To be honest, it is not enough to simply communicate more, to work efficiently in a distributed environment. Rather an elaborate concept is necessary, that takes all the aspects and challenges of distributed work into account. This is especially important for teams with little experience with distributed work.
Several years ago, ZEISS Digital Innovation already received attention with their ETEO-concept. ETEO (“Ein Team Ein Office” – One Team One Office) is a framework for distributed work in teams. It gives project teams a guide as to how distributed work can be achieved. A permanent video link between the sites and a digital work board for task assignment enables the teams to work spread out between different sites. Just like being at one site together. The video link is no requirement it is just a building block from ZEISS Digital Innovation’s toolkit for distributed work. There are specifically trained employees (ETEO-Coaches), that train and coach the team members, in techniques for distributed work, during ramp up and the project duration. It often leads to a “aha moment” with our customers that distributed work without performance impact can work.
Figure 2: ETEO (“Ein Team Ein Office” – One Team One Office) – Our Collaboration Model
In general, as with everything the rule applies, the tool is nothing, if you do not know how to use it. With this I mean that distributed work can only work with the discipline and right mindset of the involved. One thing is left to be stated, you have to commit yourself without reservations and just try the tools and techniques. And of course: Practice makes perfect. The longer a team works in a distributed environment, the stronger the best practices for distributed work are highlighted in the individual team setting. One must not forget that there is no such thing as the ultimate concept for distributed work. Interactions within projects are not between roles and responsibilities but between people and they are all different.
Each project is different and therefore also the requirements for distributed work. But the basic principles are basically the same. This can be compared with building a house. No matter how it looks, number of floors or type of roof it has, it always has a foundation it rests on.
The foundations of distributed work at ZEISS Digital Innovation are sound.
